JS循環踩坑：1個漏寫的i++讓服務器掛了3小時

2023年某電商大促凌晨，監控突然報警——CPU飆到100%，頁面全部卡死。工程師排查三小時，最后發現是個 junior 在循環里忘了寫 i++。這不是段子，是某廠真實事故復盤里的原話。

循環這東西，寫對了是自動化利器，寫錯就是生產事故。今天把 JS 循環的底褲扒干凈，看完至少少踩80%的坑。

for 循環：最老實的工具，最隱蔽的陷阱

for 循環的結構像一份固定格式的合同：初始化、條件判斷、迭代更新，三部分缺一不可。很多人背得滾瓜爛熟，真寫起來卻栽在"我以為它會自動處理"上。

for (let i = 0; i < 5; i++) 這行代碼，執行順序是：先給 i 賦值為0，然后檢查 i<5 是否成立，成立就執行花括號里的內容，最后執行 i++ 把 i 加1，再回到條件判斷。

那個電商事故的核心代碼大概長這樣：for (let i = 0; i < data.length; ) { process(data[i]); }。迭代更新那一欄空了，i 永遠是0，條件永遠成立，循環永遠跑下去。CPU 被這一個死循環吃光，其他請求全餓死。

這種錯誤在代碼審查里很難一眼看出來，尤其是當循環體很長、把 i++ 擠到第二頁的時候。

while 與 do-while：條件判斷的位置游戲

while 循環把條件提到最前面，先檢查再執行。如果條件一開始就不滿足，循環體一次都不會跑。適合那種"可能根本不需要執行"的場景，比如讀取文件時先判斷文件是否存在。

do-while 則把條件藏到屁股后面，先執行一次再說。哪怕條件一開始就是假的，循環體也已經跑完一輪了。這個特性在需要"至少執行一次"的場景里很有用，比如用戶輸入驗證——先彈窗讓他輸，輸完再檢查合不合法。

但 do-while 的語法結構容易讓人看漏那個結尾的分號：do { ... } while (condition);。漏掉分號在某些壓縮工具里會直接報錯，而且錯誤提示往往指鹿為馬，讓你懷疑人生半小時。

for...of 與 for...in：名字像兄弟，脾氣差很遠

ES6 之后多了兩個新選擇，但混用這兩兄弟的 bug 能在 Stack Overflow 上搜出幾萬條。

for...of 遍歷的是"值"，專門對付可迭代對象——數組、字符串、Map、Set 都行。寫起來清爽：for (const item of array) { console.log(item); }，不用操心索引，直接拿到元素本身。

for...in 遍歷的是"鍵"，而且會把原型鏈上的屬性也扒拉出來。拿它遍歷數組，你得到的不是 1, 2, 3，而是 "0", "1", "2" 這些字符串鍵名，外加可能突然冒出來的 "length" 和其他自定義屬性。數組遍歷用它，等于在雷區跳踢踏舞。

有個經典面試題：給 Array.prototype 加個自定義方法，然后用 for...in 遍歷數組，看看會輸出什么。能答對這道題的人，多半被 for...in 坑出過心理陰影。

性能暗戰：哪種循環最快？

網上流傳過各種 JS 循環性能排行榜，但 2024 年的 V8 引擎已經把差距抹到可以忽略。真要做性能優化，關注點不該在"用哪種循環"，而在"循環里干了什么"。

一個常見陷阱是在循環條件里重復計算長度：for (let i = 0; i < array.length; i++)。每次迭代都要訪問 .length 屬性，雖然現代引擎有優化，但數組長度變化時這個寫法會出詭異 bug。更穩妥的做法是緩存長度：for (let i = 0, len = array.length; i < len; i++)。

另一個隱形殺手是循環體里的 DOM 操作。哪怕你用了最快的 while 循環，每次迭代都去改頁面元素，性能照樣崩。這時候該用的是文檔片段（DocumentFragment）批量操作，或者 requestAnimationFrame 把渲染攤到多個幀里。

至于 forEach、map、filter 這些數組方法，它們不是循環的替代品，是不同抽象層級的工具。forEach 不能 break，map 必須返回新數組，filter 會跳過 falsy 返回值——這些細節用錯地方，調試時間按小時計。

那個凌晨三點修復事故的工程師，在復盤文檔最后寫了句話：「循環是編程里最早學的概念之一，也是生產環境里最常埋雷的地方。因為所有人都覺得自己會了，所以沒人認真檢查。」

你最近一次寫循環，有沒有順手檢查過迭代更新那欄？