1. 先拆掉DOM 很高深的濾鏡它不過是一棵能改的樹剛學(xué)前端那會兒我對 HTML DOM 方法一直有種說不出的別扭文檔翻了一遍每個方法名字都認(rèn)識一寫頁面就全忘光。getElementById、createElement、appendChild 這些單獨拎出來都好理解可真要在頁面上加個彈窗、做個動態(tài)列表常常不知道從哪個方法下手。后來寫多了才慢慢意識到問題不在記性而是我一直沒把 DOM 方法的體系串成一張網(wǎng)。先說一個最基礎(chǔ)、但很多人沒真正想透的問題DOM 到底是什么它不是你在編輯器里寫的那堆 HTML 標(biāo)簽而是瀏覽器把你的 HTML 解析完之后在內(nèi)存里生成的一棵對象樹。HTML 文本只是原料DOM 樹才是瀏覽器實際用來理解、渲染和交互的真身。你的 CSS 選擇器能生效、JavaScript 能操作頁面本質(zhì)都是在跟這棵樹打交道。方法在這里扮演什么角色如果 DOM 是一棵長在瀏覽器里的樹那 HTML DOM 方法就是你手里的剪刀、鏟子和嫁接刀。想剪掉某個節(jié)點用 removeChild想嫁接一個新的子樹用 appendChild想找到某根枝條用 querySelector。瀏覽器對這棵樹的每一次改動幾乎都必須通過方法完成直接賦值改屬性只是其中一小類例外。我在帶新人時最喜歡打一個比方HTML 是房子的設(shè)計圖紙DOM 是蓋好的毛坯房而 DOM 方法就是你的裝修工具。圖紙你可以反復(fù)改但想動毛坯房的墻體、電路和家具沒有工具就只能干瞪眼。理解了這層關(guān)系你就明白為什么所有前端框架React、Vue不管包了多少層底層最后還是要回到這些原生方法上——因為桌面只有一個工具始終出自同一套體系。1.1 為什么你總記不住 DOM 方法我觀察過很多初學(xué)者記不住 DOM 方法的根本原因不是笨而是把方法當(dāng)成了獨立的單詞去背。實際上這些方法背后只有幾條主線找查找、建創(chuàng)建、插插入、改修改、刪刪除、聽事件監(jiān)聽。你看任何頁面操作都逃不出這六個動作你不需要背幾十個孤立的名字你只需要記住這六個動詞然后把每個動作下的 2~3 個常用方法記牢就已經(jīng)覆蓋了日常開發(fā) 90% 以上的場景。另一個記不住的原因是沒有意識到方法之間經(jīng)常配合使用。比如新增一個列表項標(biāo)準(zhǔn)鏈路是 createElement 創(chuàng)建 - 設(shè)置內(nèi)容 - appendChild 插入三步缺一不可。很多人只背了 createElement不知道后面還要插到樹里結(jié)果節(jié)點建了但頁面上看不到。這就好比你加工了一個零件但沒裝到機器上機器當(dāng)然不會轉(zhuǎn)。所以我在后文會把方法按操作鏈來講而不是按字母表排列。1.2 DOM 方法全景圖在深入每個方法之前先用一張表把整個體系鋪開。這張表是我自己給團隊培訓(xùn)時用的覆蓋了日常開發(fā)最常見的入口動作類型核心方法典型場景查找元素getElementById / getElementsByClassName / querySelector / querySelectorAll / closest拿到要操作的目標(biāo)節(jié)點創(chuàng)建節(jié)點createElement / createTextNode / cloneNode / createDocumentFragment生成新的元素、文本或批量容器插入節(jié)點appendChild / insertBefore / insertAdjacentHTML / prepend / after把節(jié)點放進指定位置修改內(nèi)容textContent / innerHTML / setAttribute / style / classList改文字、改結(jié)構(gòu)、改樣式、改屬性刪除節(jié)點removeChild / remove從樹中移除節(jié)點事件相關(guān)addEventListener / removeEventListener / dispatchEvent綁定、解綁、觸發(fā)事件遍歷關(guān)系parentNode / children / firstElementChild / nextElementSibling在節(jié)點之間移動看這張表你會發(fā)現(xiàn)方法就那么幾十個真正高頻的就上面這些。后文我會逐個展開講清楚為什么這么做和坑在哪里而不是簡單羅列 API 文檔。2. 找元素的方法getElementById、querySelector 到底該用誰查找元素是所有 DOM 操作的第一步就像你拿鑰匙開門——鑰匙找錯了后面全是白費。很多新人問的第一個問題就是這么多查找方法我到底該用哪個老實說這個問題的答案隨著前端發(fā)展一直在變。2.1 老派三兄弟getElementById、getElementsByClassName、getElementsByTagName這三個方法非常典型它們從前端早期一直活到今天但現(xiàn)在很多新手對它們的脾氣已經(jīng)不熟了。getElementById 最簡單參數(shù)是 ID 字符串返回匹配的元素對象如果找不到返回 null。它的特點是一個 ID 只能對應(yīng)一個元素所以語義上天生就是獨立節(jié)點。過去我們用document.getElementById(app)拿到根節(jié)點再往里面塞東西現(xiàn)在雖然也可以用但寫法上逐漸被 querySelector 替代。不過有一個細節(jié)值得記住getElementById 只能掛在 document 上調(diào)用不能通過某個父元素去調(diào)比如parent.getElementById(...)會報錯這是它的限制。getElementsByClassName 和 getElementsByTagName 就有點脾氣了它們返回的不是單個元素而是一個 HTMLCollection——一個活的集合。這個集合不是靜態(tài)快照而是跟 DOM 樹實時聯(lián)動。什么意思你先把集合存進變量再往頁面里新增一個匹配元素回頭再看這個集合變量長度竟然變了。這在某些場景下是好事但在循環(huán)里就是災(zāi)難——邊遍歷邊增刪會導(dǎo)致索引錯亂我在第 8 章會詳細講這個坑。2.2 萬能查詢的 querySelector 與 querySelectorAllquerySelector 和 querySelectorAll 是后來瀏覽器原生支持的選擇器查詢方法它們接受任何 CSS 選擇器字符串比如#app .item、ul li:first-child、[data-typebutton]。這是它們最大的優(yōu)勢你在 CSS 里怎么寫選擇器在 JS 里就能怎么寫心智模型完全統(tǒng)一。兩個方法的區(qū)別在于返回值querySelector 返回第一個匹配的元素找不到返回 nullquerySelectorAll 返回所有匹配元素的 NodeList靜態(tài)集合。注意這里我特意寫了靜態(tài)querySelectorAll 返回的 NodeList 是快照后續(xù) DOM 變化不會影響它。這一點跟 getElementsByClassName 的 HTMLCollection 正好相反用的時候要分清楚——如果你需要實時反映頁面狀態(tài)用 Collection如果你只是想拿當(dāng)前這一批用靜態(tài)的 NodeList 更可控不容易在循環(huán)里出bug。有個實際經(jīng)驗在組件開發(fā)里我?guī)缀踔挥?querySelector / querySelectorAll 和 getElementById很少用 getElementsByClassName。原因一個是 CSS 選擇器表達能力強另一個就是靜態(tài)集合在復(fù)雜邏輯里更好預(yù)測不會出現(xiàn)明明刪了怎么還有的靈異現(xiàn)象。2.3 查找方法的實時性差異這里值得用一張表把實時性差異釘死因為我發(fā)現(xiàn)這是面試常問、實戰(zhàn)常錯的地方方法返回類型是否實時找不到時getElementByIdElement-nullgetElementsByClassNameHTMLCollection是空集合getElementsByTagNameHTMLCollection是空集合querySelectorElement-nullquerySelectorAllNodeList否空集合實時集合聽起來很智能實際上在項目里容易埋雷。我記得有一次做無限滾動列表循環(huán)里用 getElementsByClassName 實時集合判斷是否還有更多節(jié)點因為每次 append 后集合長度自動變導(dǎo)致判斷條件永遠不為假最后內(nèi)存直接爆掉。換成 querySelectorAll 靜態(tài)快照后問題立刻消失。不是說實時集合沒用但你至少要知道它在你代碼里會自己長大。3. 造元素與插元素讓新節(jié)點在正確位置落地找到目標(biāo)元素之后下一步通常是生成新的節(jié)點并把它放進頁面。這個環(huán)節(jié)的每一步我都會拆開講因為它是 DOM 操作里最容易做成能用但很糙的部分。3.1 createElement createTextNode 的黃金搭檔createElement 的作用是創(chuàng)建元素節(jié)點但它創(chuàng)建出來的只是一個孤兒節(jié)點——存在于內(nèi)存里但不在 DOM 樹上頁面不會顯示。想讓它顯示必須找到父節(jié)點用 appendChild 或 insertBefore 插入。createTextNode 則用于創(chuàng)建文本節(jié)點。很多人寫動態(tài)內(nèi)容時圖省事直接給元素的 innerHTML 賦字符串這在處理純文本時其實藏著 XSS 風(fēng)險。更好的做法是用 createTextNode 創(chuàng)建文本節(jié)點瀏覽器會把它內(nèi)容里的、等字符正當(dāng)?shù)禺?dāng)成文本處理不會解釋成 HTML 標(biāo)簽。這句話我建議所有做前端的人都認(rèn)真讀一遍textContent/createTextNode處理的是文本innerHTML處理的是HTML兩者處理的數(shù)據(jù)類型根本不同。用戶輸入的數(shù)據(jù)永遠當(dāng)作文本處理永遠不要直接拼進 innerHTML這是我做前端以來守住的最重要的一條安全底線。3.2 appendChild、insertBefore 與節(jié)點位置控制appendChild 把一個節(jié)點追加到父元素的最后一個子節(jié)點位置這是最常見的操作。但有時候你想插到指定位置比如列表第二項后面這時候 appendChild 就不夠了要動用 insertBefore。insertBefore 接收兩個參數(shù)語法是parent.insertBefore(newNode, referenceNode)意思是把 newNode 插到 referenceNode 的前面。如果第二個參數(shù)傳 null它等價于 appendChild把節(jié)點追加到末尾。這里有個小記憶技巧insertBefore 是插到某節(jié)點前面所以第二個參數(shù)是參照物是后面那個節(jié)點不是插到第幾個位置。很多人第一次用會把參數(shù)順序搞反我建議默認(rèn)先寫好參照節(jié)點再決定前面還是后面。還有一個必須知道的行為如果你把一個已經(jīng)存在于 DOM 中的節(jié)點傳給 appendChild 或 insertBefore瀏覽器不會復(fù)制它而是把它從原位置移動過來。這個特性有時候會嚇到人——明明只是想把某元素挪個位置結(jié)果它從原來的地方消失了。其實這不是 bug而是 DOM 的移動語義。如果真想復(fù)制得先用 cloneNode(true) 克隆一份再插。3.3 DocumentFragment批量插入的性能關(guān)鍵DocumentFragment 是一個專門用來當(dāng)臨時容器的節(jié)點。它有個特性你在它上面 append 子節(jié)點頁面不會立即更新等它整體被插入 DOM 后它自己不會出現(xiàn)在樹里只有它包含的子節(jié)點會落地。換句話說它是一個中轉(zhuǎn)站。為什么需要中轉(zhuǎn)站因為每往 DOM 樹里插一次節(jié)點瀏覽器都可能觸發(fā)回流或重繪頻繁操作會卡頓。通過 DocumentFragment 先把所有要插入的節(jié)點組裝好再一次插進真實 DOM就把 N 次頁面更新壓縮成了 1 次。我在渲染長列表時幾乎必用這個模式比如一百條數(shù)據(jù)的列表直接循環(huán) appendChild 100 次和用 fragment 組裝后插一次肉眼都能感覺到流暢度差異。3.4 insertAdjacentHTML另一種思路除了 appendChild 系列還有一個方法被嚴(yán)重低估insertAdjacentHTML。它接受兩個參數(shù)第一個是插入位置beforebegin、afterbegin、beforeend、afterend第二個是 HTML 字符串。比如el.insertAdjacentHTML(beforeend, li新項/li)等價于在 el 內(nèi)部的末尾追加一段 HTML。它的優(yōu)點是寫法直觀適合插入一段由字符串拼好的結(jié)構(gòu)返回值還不是節(jié)點而是 undefined所以別指望它返回插入的元素。要注意它的定位是基于某一個元素的外部或內(nèi)部beforebegin 是元素外面之前afterend 是元素外面之后afterbegin 是元素內(nèi)部第一個子節(jié)點之前beforeend 是元素內(nèi)部最后一個子節(jié)點之后。這四個方位在寫復(fù)雜布局時相當(dāng)好用尤其是做內(nèi)容流插入的場景。但安全提醒依然適用不要把用戶輸入直接塞進 HTML 字符串。4. 改內(nèi)容與改屬性innerHTML、textContent、classList 的邊界感節(jié)點插進去之后接下來要做的通常就是改——改文字、改結(jié)構(gòu)、改樣式、改屬性。這些操作看著簡單方法之間的邊界如果拿不準(zhǔn)很容易出現(xiàn)文本丟了樣式樣式溢出到無關(guān)元素等離奇問題。4.1 innerHTML 與 textContent 的安全分界innerHTML 屬性會讀取或設(shè)置元素內(nèi)部的 HTML 結(jié)構(gòu)你給它賦一段包含標(biāo)簽的字符串它會解析成真實節(jié)點textContent / innerText 則只處理純文本內(nèi)容任何 HTML 標(biāo)簽都會被當(dāng)成普通字符顯示。這兩個屬性最大的區(qū)別就是數(shù)據(jù)類型一個是結(jié)構(gòu)一個是文本。很多動態(tài)渲染需求用 innerHTML 確實快、直觀但安全上必須保持警惕。比如評論功能如果把用戶輸入的img srcx onerroralert(1)直接拼進 innerHTML瀏覽器一旦解析它就是一次可被利用的機會。防御方式不復(fù)雜——要么用 textContent 賦值要么先做轉(zhuǎn)義把換成lt;。我個人的習(xí)慣是項目里凡是跟用戶輸入相關(guān)的一律用 textContent / createTextNode只有業(yè)務(wù)確信內(nèi)容是可信的靜態(tài)模板時才允許 innerHTML。另一個容易被忽略的點是性能差異。賦值給 innerHTML瀏覽器需要重新解析整個子樹的 HTML 字符串而 textContent 只是替換文本節(jié)點開銷小得多。如果你只是改一個按鈕的文字完全沒必要用 innerHTML。這種地方省一點頁面在高頻更新時差距就出來了。4.2 屬性操作的三種姿勢屬性操作有幾種親屬關(guān)系不太一樣的方式用的時候要分清直接通過點語法訪問比如el.id xx、el.href ...。優(yōu)點是簡潔但不是所有屬性都能用點語法直接映射比如自定義屬性>button idbackTop classback-top hidden返回頂部/button.back-top { position: fixed; right: 30px; bottom: 60px; padding: 10px 16px; border: none; border-radius: 6px; background: #1677ff; color: #fff; cursor: pointer; transition: opacity 0.3s; } .back-top.hidden { opacity: 0; pointer-events: none; }const backTopBtn document.getElementById(backTop); // 1. 監(jiān)聽滾動控制按鈕顯隱 window.addEventListener(scroll, () { if (window.scrollY 300) { backTopBtn.classList.remove(hidden); } else { backTopBtn.classList.add(hidden); } }); // 2. 點擊返回頂部 backTopBtn.addEventListener(click, () { window.scrollTo({ top: 0, behavior: smooth }); });這套代碼用到了這一章的核心方法getElementById 查找按鈕classList.add / remove 控制顯隱addEventListener 監(jiān)聽滾動和點擊window.scrollTo 完成滾動。整套邏輯沒有任何多余的庫純粹的原生 DOM 方法就能跑通。7.3 性能與體驗優(yōu)化基礎(chǔ)版能工作但生產(chǎn)環(huán)境我會再加兩個優(yōu)化。第一個優(yōu)化是滾動事件的節(jié)流。scroll 事件觸發(fā)頻率極高每次滾動幾十像素就能觸發(fā)十幾次如果回調(diào)里有復(fù)雜操作頁面就卡。簡單節(jié)流用 requestAnimationFrame 就能做它會把多次回調(diào)合并到每一幀只執(zhí)行一次let ticking false; window.addEventListener(scroll, () { if (ticking) return; ticking true; requestAnimationFrame(() { if (window.scrollY 300) { backTopBtn.classList.remove(hidden); } else { backTopBtn.classList.add(hidden); } ticking false; }); });第二個優(yōu)化是支持用戶中途打斷。如果點擊返回頂部后用戶立刻滾動基礎(chǔ)版的 smooth 行為會跟用戶的操作打架。完善的做法是記錄一個標(biāo)志位滾動事件觸發(fā)時把標(biāo)志位清零并停止動畫。一般我會用更可控的方式實現(xiàn)不用 window.scrollTo 的 behavior而是手動用 requestAnimationFrame 做逐幀滾動每幀移動固定距離滾動事件打斷時取消動畫幀let scrollAnimationId null; function scrollToTop() { if (scrollAnimationId) { cancelAnimationFrame(scrollAnimationId); } const startY window.scrollY; const distance -startY; const duration 400; const startTime performance.now(); function step(currentTime) { const progress Math.min((currentTime - startTime) / duration, 1); const eased 1 - Math.pow(1 - progress, 3); // easeOutCubic window.scrollTo(0, startY distance * eased); if (progress 1) { scrollAnimationId requestAnimationFrame(step); } } scrollAnimationId requestAnimationFrame(step); } window.addEventListener(scroll, () { if (scrollAnimationId) { cancelAnimationFrame(scrollAnimationId); scrollAnimationId null; } // ...顯隱控制 });這段代碼里用到了 cancelAnimationFrame 清理動畫幀核心思路是視覺上用戶一動程序自動讓位。這也是整套 DOM 方法配合中最值得體會的部分方法本身不復(fù)雜復(fù)雜的是方法之間的節(jié)奏控制。8. 返回值細節(jié)與性能陷阱這些年我踩過的 DOM 方法坑最后這一章聊聊實際開發(fā)中因為 DOM 方法用得不當(dāng)而踩過的坑。每個坑背后都是返回值類型、實時性或者事件綁定細節(jié)在作祟很值得花時間沉淀總結(jié)。8.1 高頻 DOM 操作的布局抖動布局抖動Layout Thrashing是讀和寫交替太多導(dǎo)致的性能問題。比如在一個循環(huán)里先讀 offsetHeight再修改 style再讀 offsetWidth再修改 style……每次讀到布局相關(guān)屬性時瀏覽器為了保證結(jié)果是最新的會被迫重新執(zhí)行一次布局計算而這種計算如果刷得比渲染還快性能就崩了。解決思路是讀寫分離先把所有需要的布局?jǐn)?shù)據(jù)讀出來存好再統(tǒng)一修改。這個原則聽著簡單但一旦代碼量大很容易在不經(jīng)意間又混著寫。我對新人的建議是凡是高頻操作 DOM 的地方優(yōu)先考慮用 DocumentFragment 批量創(chuàng)建插入業(yè)務(wù)里循環(huán)改樣式時也盡量把修改集中到一個函數(shù)里執(zhí)行。通過方法組合把操作批次化性能提升是最直接的。8.2 動態(tài)渲染節(jié)點的綁定失效我給每個 li 都綁了 click為什么新加的 li 沒反應(yīng)——這是我在論壇里看到頻率最高的問題之一。本質(zhì)原因很簡單你給 li 綁事件是在頁面初始渲染時執(zhí)行的后來動態(tài)新增的 li 根本沒有經(jīng)過那次綁定自然沒有監(jiān)聽器。解決辦法前面已經(jīng)講了用事件委托。把監(jiān)聽器掛在一個始終保持不變的父容器上通過 closest 判斷目標(biāo)是不是想要的元素。我經(jīng)歷過的很多莫名其妙的 bug 最后都是這么解決的。這不僅是一個技術(shù)選型更是一種面向動態(tài)頁面的思維模式不要給未來的節(jié)點綁定任何東西你要綁定的是那個永遠存在的容器。8.3 常見方法返回 null/undefined的排查鏈路最后一個高頻困惑為什么 getElementById 返回 null為什么 querySelector 返回 null我總結(jié)了一套排查鏈路按順序走基本都能定位先確認(rèn)腳本執(zhí)行時機是不是在 DOM 加載之前。如果你把 script 放在 head 里且沒有 defer這時候 DOM 樹還沒構(gòu)建完查找當(dāng)然是空。解決方法是把 script 放到 body 底部或者用 DOMContentLoaded 事件包一層。檢查選擇器有沒有打錯。ID 大小寫敏感class 要帶點號屬性選擇器要核對引號。瀏覽器控制臺里可以直接document.querySelector(...)試一下立刻能驗證。檢查是不是拼寫和命名空間的問題。比如自定義元素在某些環(huán)境里渲染前查不到需要稍微等一下或使用 MutationObserver 監(jiān)聽。最后別忘了看動態(tài)組件如果元素由前端框架渲染原生查找方法直接執(zhí)行時框架還沒來得及生成 DOM應(yīng)該等生命周期鉤子或 nextTick 再查。這套鏈路我建議直接截圖保存排查時一步步對照比憑空猜測快得多。畢竟 DOM 方法本身不會騙你返回 null 的時候它已經(jīng)誠實地告訴你此刻這棵樹里沒有你要找的那根枝條。寫到這里我已經(jīng)把 HTML DOM 方法從查找、創(chuàng)建、修改、事件到遍歷、實戰(zhàn)和踩坑完整講了一遍。就我的體會而言DOM 方法不難難的是養(yǎng)成樹結(jié)構(gòu)思維——每行代碼都要想清楚操作的是哪個層級、什么節(jié)點類型、會不會影響實時集合。把這些邊界理順之后再寫頁面交互你會明顯感覺到不再是一個方法一個方法地查字典而是整個操作鏈路在腦子里自動跑通。后面你在項目里遇到更復(fù)雜的場景比如虛擬滾動、表格編輯、圖表聯(lián)動回頭再來對照這篇文章提到的套路和原則會發(fā)現(xiàn)底層邏輯始終是同一套。