如果你每天都在改代碼→切瀏覽器→按刷新→等頁面加載這個(gè)循環(huán)里待著說明你的前端開發(fā)工作流還缺了最后一環(huán)自動(dòng)化。這個(gè)需求太常見了幾乎所有現(xiàn)代構(gòu)建工具都內(nèi)置了熱更新能力但很多人只是把它當(dāng)黑盒使用——頁面為什么自己刷新了、文件監(jiān)聽到底原理是什么、壞了怎么排查一概不知。我也經(jīng)歷過這個(gè)階段后來干脆花了一晚上用Node.js原生能力加一個(gè)WebSocket庫從零手寫了一個(gè)能用的熱重載頁面腳本徹底搞懂了底層的每一步。這篇就把完整過程和踩過的坑寫出來。熱重載頁面說白了就是三件事起一個(gè)本地靜態(tài)文件服務(wù)、監(jiān)聽文件內(nèi)容變化、把變化了這個(gè)信號(hào)推送到瀏覽器然后自動(dòng)刷新。它非常適合靜態(tài)頁面、輕量Demo、活動(dòng)頁這類不依賴重型構(gòu)建鏈的項(xiàng)目也適合任何想理解前端自動(dòng)化底層的開發(fā)者。你不需要先會(huì)框架只要懂一點(diǎn)Node.js基礎(chǔ)就能跟著跑起來。1. 熱重載到底在優(yōu)化什么一次改代碼實(shí)時(shí)看效果的拆解在動(dòng)手寫代碼之前我覺得有必要先把熱重載這個(gè)概念解剖清楚。很多新手會(huì)把熱重載和模塊熱替換HMR混為一談但它們解決的問題層次完全不同這種認(rèn)知偏差會(huì)在后面寫代碼時(shí)帶來很大的方向性問題。1.1 手動(dòng)刷新丟失的不僅是時(shí)間還有心流狀態(tài)改一個(gè)CSS顏色值人眼在編輯器里看的是代碼里的#409EFF但最終效果在瀏覽器渲染層才能看到。如果每次改完都要切窗口、找刷新按鈕、等資源重新加載一天下來這個(gè)動(dòng)作不知道要重復(fù)多少次。這種機(jī)械操作最傷的不是時(shí)間而是專注力——每次打斷都要重新進(jìn)狀態(tài)比網(wǎng)絡(luò)請(qǐng)求慢多了。熱重載頁面把這個(gè)環(huán)節(jié)壓縮成了保存即看到結(jié)果。它本質(zhì)上是在幫你完成一個(gè)動(dòng)作鏈文件系統(tǒng)發(fā)生變化 → 監(jiān)聽器檢測(cè)到事件 → 通知瀏覽器 → 瀏覽器重新拉取資源。鏈條上的每一步都值得單獨(dú)優(yōu)化這也是我后面把架構(gòu)拆成三個(gè)組件的原因。1.2 現(xiàn)有方案的兩類局限黑盒依賴和殺雞用牛刀大部分人在真實(shí)項(xiàng)目里用的是腳手架自帶的HMR功能比如創(chuàng)建項(xiàng)目時(shí)自動(dòng)配好的開發(fā)服務(wù)器。它確實(shí)好用但有個(gè)共同特點(diǎn)你只看到的是一行配置或一句命令內(nèi)部的工作機(jī)制被完整封裝。一旦遇到文件改了但頁面沒刷新這類基礎(chǔ)問題你翻開文檔也只能找到重啟開發(fā)服務(wù)器這種粗放解法。另一類方案是通用刷新工具比如帶自動(dòng)刷新的編輯器插件或?yàn)g覽器插件。這類工具勝在配置簡(jiǎn)單但它的監(jiān)聽范圍、刷新策略都是固定的你沒法針對(duì)特定目錄做精細(xì)控制也沒法在頁面里加入自己的處理邏輯——比如我只想在CSS變化時(shí)替換樣式而不想整頁刷新通用工具就很難滿足。1.3 自己實(shí)現(xiàn)熱重載頁面能獲得什么做輪子不是目的理解機(jī)制才是。自己用Node.js寫一遍熱重載你會(huì)獲得三層收益首先是原理層面的認(rèn)知你會(huì)清楚知道瀏覽器和本地服務(wù)之間的消息是怎么流動(dòng)的其次是定制能力想監(jiān)聽哪類文件、想合并多快內(nèi)的變更事件、要不要排除目錄全都變成幾行配置最后是故障排查能力以后再用任何工具熱更新失效你能迅速判斷是哪一環(huán)出了問題。我這次的目標(biāo)很明確不用任何重型框架只依賴Node.js原生模塊和一個(gè)WebSocket庫寫一個(gè)約百行代碼、能跑起來的完整熱重載服務(wù)。這個(gè)量級(jí)正好適合把原理講透也足夠在真實(shí)項(xiàng)目中頂一陣子。2. 自己從零搭熱重載的三大核心件靜態(tài)服務(wù)、文件監(jiān)聽、消息通道整個(gè)熱重載由三個(gè)相互獨(dú)立又需要協(xié)作的組件構(gòu)成。我把它們比作三個(gè)齒輪靜態(tài)文件服務(wù)是貨架負(fù)責(zé)把磁盤上的資源按請(qǐng)求發(fā)給瀏覽器文件監(jiān)聽是哨兵盯著文件系統(tǒng)有沒有變動(dòng)消息通道是傳令兵把變更信號(hào)及時(shí)送到瀏覽器。少了任何一個(gè)鏈條都轉(zhuǎn)不起來。2.1 靜態(tài)文件服務(wù)Node.js十幾行代碼就能撐起一個(gè)本地站點(diǎn)瀏覽器要訪問本地文件最直接的方式是file://協(xié)議打開HTML。但這種方式?jīng)]法建立WebSocket連接——瀏覽器安全策略允許頁面在HTTP(S)下建立WS連接卻不會(huì)給file://頁面這種能力。而且file://協(xié)議下跨域加載資源也經(jīng)常出問題所以熱重載第一步必須是一個(gè)真正的HTTP服務(wù)。Node.js的http模塊做這件事非常順。核心邏輯就是根據(jù)請(qǐng)求URL拼出磁盤路徑讀取文件后按擴(kuò)展名返回對(duì)應(yīng)的Content-Type。像HTML、CSS、JS這類文本文件還要注意字符集我一般用text/html; charsetutf-8這種格式避免瀏覽器用默認(rèn)編碼猜出亂碼。這里有一個(gè)容易被忽略的細(xì)節(jié)靜態(tài)服務(wù)最好把目錄邊界守住。因?yàn)閁RL路徑經(jīng)過解碼后可能包含../這類片段如果不做校驗(yàn)用戶可以通過構(gòu)造特殊的URL讀出項(xiàng)目目錄之外的敏感文件這在你把本地服務(wù)暴露到局域網(wǎng)時(shí)尤其危險(xiǎn)。我在這篇文章的實(shí)現(xiàn)里會(huì)用path.join加startsWith雙重檢查確保最后解析出的路徑一定在項(xiàng)目根目錄之下。2.2 文件監(jiān)聽fs.watch不是免費(fèi)的午餐你需要知道它的脾性Node.js提供的文件監(jiān)聽API是fs.watch它基于操作系統(tǒng)原生事件實(shí)現(xiàn)響應(yīng)非?？旎臼呛撩爰?jí)。用法上很簡(jiǎn)單指定要監(jiān)聽的目錄或文件回調(diào)里就能收到變化事件和文件名。但我在實(shí)際使用中很快發(fā)現(xiàn)它有幾個(gè)脾性首先是Linux平臺(tái)對(duì)recursive: true的支持并不理想在本地開發(fā)機(jī)上你可能用macOS或Windows能遞歸監(jiān)聽但一到部署調(diào)試環(huán)境或者某些Linux生產(chǎn)服務(wù)器上遞歸參數(shù)就直接失效目錄里深層文件的變化根本監(jiān)聽不到其次是同一個(gè)保存動(dòng)作可能被系統(tǒng)拆成多個(gè)事件比如很多編輯器保存時(shí)會(huì)先寫入臨時(shí)文件再原子替換回調(diào)可能被觸發(fā)兩三次最后是回調(diào)返回的filename在某些平臺(tái)上可能是null如果你不做兜底下面的路徑拼接會(huì)直接報(bào)錯(cuò)。針對(duì)這幾個(gè)問題答案不是去找一個(gè)萬能API而是采取組合策略遞歸監(jiān)聽能力不可靠就自己寫深度遍歷函數(shù)逐個(gè)目錄注冊(cè)fs.watch事件觸發(fā)太頻繁就在外層加防抖合并filename可能為空就用目錄本身做兜底。這些經(jīng)驗(yàn)會(huì)在后面的代碼里完整展示。2.3 消息通道WebSocket對(duì)比輪詢到底贏在哪瀏覽器收到文件變了這個(gè)信號(hào)有兩條路可走一種是頁面定時(shí)用HTTP去請(qǐng)求后端有沒有變化這叫輪詢另一種是后端主動(dòng)把消息推給瀏覽器這就是WebSocket。輪詢的問題在于實(shí)時(shí)性和開銷沒法兩全。把輪詢間隔設(shè)成500ms頁面就要每秒發(fā)起兩次HTTP請(qǐng)求即使什么都沒變網(wǎng)絡(luò)棧和服務(wù)器也要處理一堆空請(qǐng)求功能上能跑但顯然不是最優(yōu)解。WebSocket則不同它在HTTP基礎(chǔ)上做一個(gè)協(xié)議升級(jí)后建立一條全雙工的長(zhǎng)連接數(shù)據(jù)可以從服務(wù)端主動(dòng)推給客戶端實(shí)時(shí)性天然就是毫秒級(jí)而且沒有變更時(shí)幾乎零額外流量。我選擇WebSocket作為熱重載的消息通道還有一層考慮以后想讓頁面顯示開發(fā)服務(wù)器已斷開的提示或者從瀏覽器向服務(wù)端發(fā)送自定義指令WebSocket雙向通信的能力都能直接覆蓋。這個(gè)選擇在代碼實(shí)現(xiàn)上只需要客戶端一二十行并不復(fù)雜。3. 一個(gè)可直接抄走的完整實(shí)現(xiàn)百行代碼跑通熱重載理論鋪墊完現(xiàn)在進(jìn)入實(shí)操。下面這套代碼我做了簡(jiǎn)化但保持完整核心文件就一個(gè)server.js你把它放到任意項(xiàng)目的根目錄運(yùn)行后訪問http://localhost:3000就能體驗(yàn)到保存即刷新的效果。我會(huì)邊貼代碼邊解釋每一段的設(shè)計(jì)動(dòng)機(jī)這樣你能真正理解它而不是只知道復(fù)制。3.1 項(xiàng)目結(jié)構(gòu)一個(gè)文件搞定不搞額外工程化這里不打算引入構(gòu)建步驟。項(xiàng)目結(jié)構(gòu)保持最簡(jiǎn)your-project/ ├── index.html ├── css/ │ └── style.css ├── js/ │ └── app.js └── server.js你在自己的項(xiàng)目根目錄放一份server.js然后執(zhí)行node server.js控制臺(tái)會(huì)打印一行提示。這個(gè)腳本默認(rèn)把啟動(dòng)目錄當(dāng)作靜態(tài)服務(wù)的根目錄所以你在哪個(gè)目錄下啟動(dòng)就把哪個(gè)目錄作為網(wǎng)站根目錄來服務(wù)。需要說明的一點(diǎn)是這個(gè)實(shí)現(xiàn)需要安裝一個(gè)第三方依賴用于WebSocket我選的是Node生態(tài)里最常見的ws庫安裝一行命令npm init -y npm install wsws庫的特點(diǎn)是底層封裝得干凈API小巧用來做開發(fā)期工具非常合適。如果你連依賴都不想裝理論上可以基于原生HTTP自己實(shí)現(xiàn)一個(gè)簡(jiǎn)化版WebSocket握手和幀解析但那是純學(xué)習(xí)目的日常開發(fā)完全沒必要重復(fù)造這個(gè)輪子。3.2 靜態(tài)文件服務(wù)和HTML注入腳本讓頁面自帶熱更能力下面這個(gè)文件包含了HTTP服務(wù)、WebSocket服務(wù)、文件監(jiān)聽三大部分我的做法是放一個(gè)壓縮版先讓你看到整體結(jié)構(gòu)再拆解重點(diǎn)段落。const http require(http); const fs require(fs); const path require(path); const WebSocket require(ws); const PORT process.env.PORT || 3000; const ROOT process.cwd(); const MIME { .html: text/html; charsetutf-8, .css: text/css; charsetutf-8, .js: text/javascript; charsetutf-8, .json: application/json; charsetutf-8, .jpg: image/jpeg, .png: image/png, .svg: image/svgxml, }; const INJECTED_SCRIPT script (function () { let ws; function connect() { ws new WebSocket(ws:// location.host); ws.onmessage function (event) { var msg JSON.parse(event.data); if (msg.type reload) location.reload(); }; ws.onclose function () { setTimeout(connect, 1200); }; } connect(); })(); /script ; function shouldIgnore(filePath) { return filePath.split(path.sep).some(function (segment) { return segment node_modules || segment .git; }); } http.createServer(function (req, res) { const urlPath decodeURIComponent(req.url.split(?)[0]); let filePath path.join(ROOT, urlPath); if (urlPath /) filePath path.join(ROOT, index.html); if (!filePath.startsWith(ROOT)) { res.writeHead(403); res.end(Forbidden); return; } fs.stat(filePath, function (err, stats) { if (err || !stats.isFile()) { res.writeHead(404); res.end(Not Found); return; } let content fs.readFileSync(filePath); if (path.extname(filePath) .html) { content content .toString() .replace(/head, INJECTED_SCRIPT /head); } res.writeHead(200, { Content-Type: MIME[path.extname(filePath)] || application/octet-stream, }); res.end(content); }); }).listen(PORT, function () { console.log(熱重載服務(wù)已啟動(dòng): http://localhost: PORT); });第一段靜態(tài)服務(wù)用了最直觀的同步讀取。開發(fā)期工具我偏向用同步API因?yàn)槲募ǔ：苄?、并發(fā)也不高同步代碼的可讀性和排錯(cuò)性遠(yuǎn)好于回調(diào)嵌套。這里最關(guān)鍵的設(shè)計(jì)是HTML注入我不要求開發(fā)者手動(dòng)在頁面里加任何額外的script標(biāo)簽服務(wù)端在返回HTML時(shí)自動(dòng)把熱更客戶端腳本插入到/head之前這樣原有的項(xiàng)目文件完全不用改動(dòng)。注入腳本里的location.host非常關(guān)鍵它動(dòng)態(tài)取出當(dāng)前頁面的域名和端口確保WebSocket連接地址永遠(yuǎn)和頁面訪問地址一致不用手工配置端口參數(shù)。斷線重連的邏輯也放在這里如果開發(fā)服務(wù)重啟已打開的頁面會(huì)自動(dòng)在1.2秒后嘗試重新連接頁面無需人工刷新就能恢復(fù)熱更能力。shouldIgnore函數(shù)是整個(gè)方案里值得單獨(dú)說的一點(diǎn)。你監(jiān)聽整個(gè)項(xiàng)目目錄時(shí)node_modules和.git這種目錄的變動(dòng)頻率非常高尤其是安裝依賴時(shí)會(huì)有成千上萬次文件寫入每次都會(huì)觸發(fā)事件。如果不把它們排除掉熱重載服務(wù)會(huì)被無意義的文件事件淹沒甚至導(dǎo)致頁面每次裝包時(shí)瘋狂刷新。按路徑段逐個(gè)匹配的方式比較穩(wěn)妥只要是路徑的某一段叫node_modules就跳過能防住各種深層嵌套場(chǎng)景。3.3 文件監(jiān)聽加防抖保存一次只能刷新一次下面是文件監(jiān)聽和消息廣播的部分這其實(shí)是熱重載的核心引擎。const wss new WebSocket.Server({ server: httpServer, }); const clients new Set(); wss.on(connection, function (socket) { clients.add(socket); socket.on(close, function () { clients.delete(socket); }); }); let pending new Set(); let timer null; function broadcast(message) { const data JSON.stringify(message); for (const client of clients) { if (client.readyState WebSocket.OPEN) { client.send(data); } } } function handleChange(filePath) { if (shouldIgnore(filePath)) return; pending.add(filePath); clearTimeout(timer); timer setTimeout(function () { const files Array.from(pending); pending new Set(); console.log([熱更觸發(fā)], files.join(, )); broadcast({ type: reload, files: files }); }, 100); } function watchDir(dir) { fs.watch(dir, function (eventType, filename) { const fullPath path.join(dir, filename || ); handleChange(fullPath); }); fs.readdirSync(dir, { withFileTypes: true }).forEach(function (entry) { if (entry.isDirectory() !shouldIgnore(entry.name)) { watchDir(path.join(dir, entry.name)); } }); } watchDir(ROOT);fs.watch的回調(diào)觸發(fā)頻率比很多人想象的高。我做過一次統(tǒng)計(jì)用某代碼編輯器保存一個(gè)文件時(shí)系統(tǒng)可能依次觸發(fā)重命名、新建、屬性變更等多次事件如果不做任何處理一個(gè)保存動(dòng)作會(huì)讓頁面連續(xù)刷新好幾次體驗(yàn)反而比手動(dòng)刷新還差。所以我在handleChange里用clearTimeout加setTimeout做一個(gè)100毫秒的防抖窗口同一次保存引發(fā)的多個(gè)事件會(huì)被聚合到一次廣播里。這里我用Set而不是一個(gè)簡(jiǎn)單變量是有講究的。防抖窗口內(nèi)如果先后改了多個(gè)文件比如一次格式化操作同時(shí)寫入了多個(gè)文件這些文件路徑都會(huì)被記錄在集合里。廣播出去的消息帶有一個(gè)files數(shù)組雖然客戶端目前只是整頁刷新但服務(wù)端日志能清楚看到哪些文件被納入了此次刷新排查問題時(shí)很有用。watchDir遞歸函數(shù)解決了recursive參數(shù)在Linux上不可靠的問題。它先監(jiān)聽當(dāng)前目錄再讀取這個(gè)目錄下的所有子級(jí)目錄分別注冊(cè)監(jiān)聽實(shí)現(xiàn)一個(gè)跨平臺(tái)可用的遞歸監(jiān)聽。每一層回調(diào)收到變更時(shí)都把相對(duì)路徑拼成絕對(duì)路徑再交給handleChange處理。這個(gè)實(shí)現(xiàn)雖然簡(jiǎn)單但已經(jīng)能覆蓋絕大多數(shù)項(xiàng)目的目錄結(jié)構(gòu)。3.4 跑通驗(yàn)證三種改法的預(yù)期效果部署完成后拿起項(xiàng)目里的HTML文件做三個(gè)實(shí)驗(yàn)。實(shí)驗(yàn)一打開頁面后直接改CSS文件的顏色值。保存的同時(shí)頁面會(huì)在100毫秒后自動(dòng)刷新你看到的新背景色就是剛保存的效果。實(shí)驗(yàn)二往HTML里加一個(gè)標(biāo)題文字。保存后頁面刷新新內(nèi)容直接出現(xiàn)。實(shí)驗(yàn)三在頁面上的輸入框里輸入一些內(nèi)容然后保存任意文件頁面刷新后輸入內(nèi)容會(huì)丟失——這類整頁刷新的行為特征要提前知道如果項(xiàng)目里有需要保留的臨時(shí)狀態(tài)后面章節(jié)我會(huì)講怎么改。這三個(gè)實(shí)驗(yàn)分別驗(yàn)證了靜態(tài)資源服務(wù)、HTTP注入腳本、文件監(jiān)聽的完整鏈路。如果任何一個(gè)環(huán)節(jié)沒生效排查順序也很固定先看服務(wù)端控制臺(tái)有沒有打印[熱更觸發(fā)]沒有說明監(jiān)聽或防抖邏輯有問題有打印但頁面不刷新說明WebSocket連接或客戶端腳本有問題頁面刷新但樣式?jīng)]更新那可能真是瀏覽器緩存需要在響應(yīng)頭加禁用緩存的字段。這個(gè)排查思路我后來排查過不少類似問題現(xiàn)在分享給你。4. 真實(shí)遇到的四個(gè)坑和修復(fù)思路文件監(jiān)聽不是一成不變的手寫熱重載最大的價(jià)值不在那100行能跑的代碼而在你用它踩過坑之后積累的判斷力。下面這四類問題是我在實(shí)際使用過程中真真切切遇到的每一個(gè)都導(dǎo)致了頁面不刷新或者頁面亂刷新我按排查鏈路寫出來希望你一次就能避開。4.1 保存一次文件瀏覽器卻連續(xù)刷新好幾次第一次跑通時(shí)我覺得熱重載真爽結(jié)果馬上就發(fā)現(xiàn)一個(gè)問題我只保存了一下頁面卻像抽風(fēng)一樣反復(fù)刷新。打開Network面板看到頁面在短時(shí)間內(nèi)被請(qǐng)求了三次服務(wù)端日志也打出了三條[熱更觸發(fā)]記錄。原因就是前面提到的編輯器多重事件。保存動(dòng)作在文件系統(tǒng)層面是一系列操作先創(chuàng)建臨時(shí)文件、再重命名覆蓋原文件、再同步屬性元數(shù)據(jù)每個(gè)步驟都可能觸發(fā)一次fs.watch回調(diào)。我最初是在回調(diào)里直接廣播沒有防抖窗口于是瀏覽器就收到了多次刷新指令。修復(fù)方案就是引入100毫秒的聚合窗口。這個(gè)時(shí)長(zhǎng)我試過50毫秒、100毫秒、200毫秒三個(gè)值最終選了100毫秒——太短擋不住同一保存操作的多重事件太長(zhǎng)又會(huì)讓人明顯感覺保存后有一小段空窗期?，F(xiàn)在的通用建議是純文本文件開發(fā)場(chǎng)景100到150毫秒是甜點(diǎn)區(qū)間。4.2 Linux服務(wù)器上深層文件變動(dòng)毫無反應(yīng)有一次把熱重載服務(wù)拿到一臺(tái)Linux機(jī)器上跑卻發(fā)現(xiàn)項(xiàng)目根目錄下的文件改動(dòng)一切正常但兩層目錄深處的文件無論怎么保存頁面都不刷新。第一反應(yīng)是監(jiān)聽代碼出錯(cuò)了我用console.log把watchDir的遞歸路徑打出來發(fā)現(xiàn)目錄都正常注冊(cè)了但深層目錄的事件就是傳不上來。后來查了運(yùn)行環(huán)境的API說明才發(fā)現(xiàn)fs.watch的recursive選項(xiàng)在Linux上并不可用而我最初寫的監(jiān)聽邏輯依賴它結(jié)果就是只能收到根目錄直級(jí)文件的事件。這個(gè)坑特別隱蔽因?yàn)閙acOS和Windows上都不會(huì)暴露問題。最后的修復(fù)就是我上面代碼里的做法放棄依賴操作系統(tǒng)原生的遞歸能力改為自己遍歷目錄深度注冊(cè)單個(gè)監(jiān)聽。它確實(shí)會(huì)讓啟動(dòng)時(shí)多消耗一點(diǎn)時(shí)間讀目錄結(jié)構(gòu)但換來了跨平臺(tái)一致的行為這個(gè)取舍在開發(fā)工具里完全值得。記住一點(diǎn)凡是涉及文件監(jiān)聽的工具跨平臺(tái)兼容性永遠(yuǎn)是第一優(yōu)先級(jí)。4.3 編輯器原子寫入導(dǎo)致監(jiān)聽消失的詭異場(chǎng)景某天突然出現(xiàn)了一個(gè)更奇怪的現(xiàn)象頁面熱重載正常工作了幾個(gè)小時(shí)改某個(gè)特定文件時(shí)突然就不再刷新了而且重啟服務(wù)后又恢復(fù)。我一度以為是fs.watch監(jiān)聽的目錄數(shù)量太多觸發(fā)了系統(tǒng)的watch限制但排查后發(fā)現(xiàn)另有原因。這個(gè)文件是用的某款編輯器改的它保存時(shí)不是直接修改原文件而是先寫一個(gè)臨時(shí)文件再通過rename系統(tǒng)調(diào)用覆蓋目標(biāo)文件。這意味著原inode已經(jīng)被替換了。如果監(jiān)聽的是文件本身而不是文件所在目錄rename操作后原來的監(jiān)聽話柄可能就失效了。解決方案在代碼里其實(shí)已經(jīng)暗含了我堅(jiān)持只對(duì)目錄做監(jiān)聽而不是對(duì)文件做監(jiān)聽。監(jiān)聽目錄的好處是無論目錄下的文件怎么被替換刪除重建只要文件名能匹配回調(diào)照樣觸發(fā)。這是文件監(jiān)聽的一個(gè)基礎(chǔ)原則——想穩(wěn)定監(jiān)聽一批文件去監(jiān)聽它們的父目錄別盯著單個(gè)文件。4.4 開發(fā)服務(wù)中途重啟已打開的頁面怎么恢復(fù)熱重載服務(wù)有個(gè)使用頻率很高的操作改了服務(wù)端代碼比如改了server.js本身后需要重啟服務(wù)。重啟期間WebSocket連接會(huì)斷開但常見情形是頁面打開著沒關(guān)等服務(wù)重啟完成后你卻忘了去刷新頁面于是新服務(wù)已經(jīng)啟動(dòng)、頁面卻還停留在舊狀態(tài)?？蛻舳四_本里的斷線重連就派上了用場(chǎng)。ws.onclose觸發(fā)后腳本會(huì)在1.2秒后嘗試重新建立連接一旦服務(wù)端口重新監(jiān)聽頁面就自動(dòng)恢復(fù)了熱更能力。這個(gè)細(xì)節(jié)讓我免去了無數(shù)次服務(wù)刷完還要回頭手動(dòng)刷新瀏覽器的操作。順帶一提重連間隔不要設(shè)太短否則服務(wù)還在啟動(dòng)過程中會(huì)形成高頻無效連接請(qǐng)求1到2秒是兼顧恢復(fù)速度和資源開銷的合理區(qū)間。5. 從整頁刷新到模塊熱替換熱重載還能往哪走基礎(chǔ)版熱重載能做到保存即刷新但對(duì)很多應(yīng)用開發(fā)場(chǎng)景來說整頁刷新帶來的狀態(tài)丟失仍是個(gè)痛點(diǎn)。這就引出了熱重載的進(jìn)階形態(tài)——模塊熱替換HMR。理解HMR和熱重載的本質(zhì)差別才能決定你的項(xiàng)目到底需要哪一層能力。5.1 熱重載與HMR的本質(zhì)區(qū)別狀態(tài)保留的鴻溝熱重載最簡(jiǎn)單的實(shí)現(xiàn)就是收到信號(hào)后調(diào)用location.reload()一切重建代價(jià)是內(nèi)存中的頁面狀態(tài)全部歸零。HMR則講究只更新變化的模塊其他不動(dòng)。以界面開發(fā)為例你修改了一個(gè)控件的樣式模塊HMR會(huì)找到哪個(gè)組件依賴這份樣式重新執(zhí)行樣式相關(guān)的代碼而組件自身的屬性和渲染結(jié)果盡量保留。這里的關(guān)鍵差異在于HMR要求項(xiàng)目具備模塊化邊界。你可以把頁面看成由一個(gè)個(gè)方塊搭建的積木熱重載是推倒整個(gè)積木塔重新搭一遍HMR則是抽換其中一塊積木而塔身不倒。傳統(tǒng)多頁面網(wǎng)站想用HMR就得先把自己改造成模塊化結(jié)構(gòu)——這也是HMR幾乎總是和現(xiàn)代前端框架配套出現(xiàn)的原因。對(duì)于純靜態(tài)頁面或簡(jiǎn)單腳本項(xiàng)目做HMR的收益很低整頁刷新反而更可靠。5.2 如何讓CSS熱更新而不刷新頁面即便不做完整的模塊化改造有一個(gè)半步是很容易實(shí)現(xiàn)的那就是讓樣式文件變更時(shí)只替換CSS而不刷新頁面。這樣做的好處很大調(diào)試CSS的視覺反饋比整頁刷新更快而且不會(huì)打斷你在開發(fā)者工具里正在查看的DOM狀態(tài)。實(shí)現(xiàn)思路并不復(fù)雜客戶端腳本判斷收到的廣播中如果包含CSS文件的路徑就遍歷頁面里所有l(wèi)ink[relstylesheet]標(biāo)簽找到對(duì)應(yīng)的那一個(gè)給它重新設(shè)置一次href。為了繞過瀏覽器緩存要在URL后面拼上時(shí)間戳或隨機(jī)數(shù)參數(shù)。服務(wù)端廣播時(shí)帶上files數(shù)組客戶端檢查擴(kuò)展名再做分支處理。這種方式在骨架屏、彈窗、動(dòng)畫調(diào)優(yōu)這類場(chǎng)景下非常實(shí)用我強(qiáng)烈建議你試一試。5.3 完整HMR的工程化思路模塊圖、執(zhí)行環(huán)境和狀態(tài)遷移一旦進(jìn)入組件級(jí)別的熱替換復(fù)雜度會(huì)陡增。業(yè)界早期一種經(jīng)典做法是實(shí)現(xiàn)一個(gè)模塊分發(fā)系統(tǒng)每個(gè)模塊執(zhí)行后把自己注冊(cè)到一張全局表里當(dāng)某一個(gè)模塊變化時(shí)系統(tǒng)從模塊表里找出所有依賴它的模塊重新執(zhí)行這些依賴但保留最上層組件實(shí)例的狀態(tài)。這套機(jī)制的三個(gè)關(guān)鍵部件是模塊圖依賴關(guān)系的描述、執(zhí)行環(huán)境能在運(yùn)行時(shí)動(dòng)態(tài)加載新的模塊實(shí)現(xiàn)和狀態(tài)遷移舊實(shí)例怎么把數(shù)據(jù)交給新實(shí)現(xiàn)。任何一個(gè)部件做不好HMR就會(huì)退化成頁面上出現(xiàn)一個(gè)全屏遮罩強(qiáng)制刷新。對(duì)獨(dú)立開發(fā)者來說自己實(shí)現(xiàn)完整HMR投入產(chǎn)出比很低更好的策略是看清自己項(xiàng)目形態(tài)靜態(tài)頁面用熱重載模塊化框架項(xiàng)目直接用腳手架自帶的HMR兩頭都別別扭。5.4 熱重載工具的正確進(jìn)階方向輕量定制如果你不需要HMR又想把手寫的熱重載用得更順手我更推薦在工具友好性上做擴(kuò)展而不是硬啃模塊替換。比如給腳本加上命令行參數(shù)支持讓用戶可以指定--port、--ignore目錄把靜態(tài)目錄從啟動(dòng)目錄改為參數(shù)傳入增加一個(gè)配置文件讓不同項(xiàng)目各自維護(hù)自己的監(jiān)聽規(guī)則。這類擴(kuò)展不會(huì)引入新的概念復(fù)雜度但對(duì)日常體驗(yàn)的提升非常實(shí)在。我現(xiàn)在的server.js已經(jīng)支持了--port和--dir兩個(gè)參數(shù)后續(xù)想給每個(gè)項(xiàng)目配一套獨(dú)立端口啟動(dòng)命令改成node server.js --port 8080 --dir src就行。另外我更愿意把腳本封裝在項(xiàng)目的devDependencies里用npm scripts管理啟動(dòng)命令換機(jī)器重新npm install就能用省去各種環(huán)境記憶負(fù)擔(dān)。6. 這輪手寫腳本的最終沉淀我對(duì)熱重載的新認(rèn)知做完整輪手寫熱重載之后我對(duì)這類開發(fā)工具的看法有了明顯轉(zhuǎn)變。最直接的是排查問題的心態(tài)——以前遇到頁面不更新我只會(huì)拍腦袋試各種靈丹妙藥現(xiàn)在我腦子里會(huì)立刻畫出一條鏈路圖服務(wù)在不在、監(jiān)聽有沒有觸發(fā)、消息有沒有送達(dá)、客戶端有沒有執(zhí)行按位置逐段掐斷排查十有八九五分鐘內(nèi)能定位。其次是對(duì)工具取舍的判斷。熱重載類工具的價(jià)值錨點(diǎn)在于反饋速度和狀態(tài)保持兩者互相牽制想更快就全量刷新想讓狀態(tài)保留就要引入精細(xì)的模塊替換。我現(xiàn)在的日常流程是純展示頁、活動(dòng)Demo這些項(xiàng)目直接丟給我這套輕量腳本一個(gè)終端窗口運(yùn)行其余操作和打開普通網(wǎng)頁沒什么區(qū)別凡是要寫組件邏輯的大型項(xiàng)目該用腳手架用什么把HMR這類重型能力交給專業(yè)工具處理讓它們做它們擅長(zhǎng)的事。最后再分享一個(gè)使用細(xì)節(jié)如果你把server.js放在項(xiàng)目根目錄但它只服務(wù)于src子目錄的前端頁面請(qǐng)記得把監(jiān)聽入口從根目錄改成src目錄否則你在根目錄下隨手新建的臨時(shí)文件、自動(dòng)補(bǔ)全工具生成的緩存文件都會(huì)觸發(fā)刷新徒增干擾。文件監(jiān)聽的范圍永遠(yuǎn)應(yīng)該比資源服務(wù)的范圍收斂一點(diǎn)這是我在實(shí)際使用里幾乎每個(gè)項(xiàng)目都會(huì)調(diào)整一次的習(xí)慣。