JS循環藏了3個坑，47%新手踩過第2個

2024年Stack Overflow調研顯示，JavaScript連續第11年霸榜最常用語言，但同期CodePen的bug報告里，「無限循環導致頁面崩潰」的投訴量同比漲了23%。這像什么？就像給了所有人一把電鉆，卻沒教他們怎么關電源。

for循環的「跑步機陷阱」

最基礎的for循環，語法結構像健身房跑步機——啟動條件、持續條件、步進節奏，三步缺一不可。MDN文檔里的標準寫法：for (let i = 0; i < 5; i++)，執行流程是：i從0起跑，每次+1，跑到5自動停表。

但47%的新手會在「步進節奏」上翻車。要么寫成i--讓跑步機倒著跑，要么干脆忘掉這行代碼。后果？瀏覽器標簽頁直接轉圈至死，風扇狂轉像要起飛。Chrome的DevTools里有個「停止無限循環」的隱藏按鈕，按Ctrl+Shift+J調出控制臺才能看到——這設計本身就很說明問題。

GitHub 2023年的代碼掃描報告有個扎心數據：開源項目里的死循環bug，平均存活周期是11個月。為什么？因為本地測試時數據量小，循環幾次就停了；上線后遇到真實用戶數據，直接引爆。

while循環的「薛定諤條件」

while循環更隱蔽。它只有持續條件，沒有內置的步進機制，像一輛沒裝剎車的滑板車。你寫while (user.isActive)，邏輯上沒問題——用戶活躍就繼續推送消息。但isActive這個狀態誰更新？什么時候更新？

Facebook 2019年出過一件事：Messenger的某個版本在弱網環境下反復嘗試重連，while條件永遠為true，導致手機電量20分鐘耗盡。工程師事后復盤，發現條件判斷里漏了「重試次數上限」這個變量。換句話說，while循環的信任成本比for高得多，你得手動確認所有退出路徑。

現在主流框架都在規避這個問題。React的useEffect要求顯式聲明依賴數組，Vue的watch默認只執行一次，本質都是給while套個安全繩。

forEach的「偽同步幻覺」

ES6之后，數組方法forEach、map、filter成了新寵。寫法優雅，沒有索引變量，看起來也更「現代」。但這里有個認知陷阱：forEach不支持break和continue，遇到需要提前終止的場景，你只能干瞪眼。

Stack Overflow上有個經典問答，點贊最高的回復是：「用some或every代替forEach，它們返回布爾值，可以模擬break效果。」這個答案被引用了超過4000次——側面說明踩坑的人有多少。

更隱蔽的是異步問題。你寫array.forEach(async item => await fetch(item))，期望按順序發請求，實際卻是并行執行。因為forEach的回調函數不會等待Promise解析，它只是把10個Promise同時扔出去。要順序執行，得退回for...of配合await，或者用reduce鏈式調用——這算ES6語法糖里的回馬槍。

性能戰的「反直覺結論」

最后說個反常識的。JS引擎優化了20年，for循環和while循環的性能差距已經小到可以忽略——V8的TurboFan編譯器會把它們編譯成幾乎相同的機器碼。但for...in遍歷對象屬性時，依然會枚舉原型鏈上的可枚舉屬性，除非你用Object.hasOwn過濾。

2023年有個性能測試在Hacker News上引發討論：遍歷100萬個數組元素，傳統for循環比forEach快約15%，但差距主要來自函數調用開銷，而非循環本身。真正拖慢速度的是循環體里的DOM操作或網絡請求——這時候糾結循環類型，就像爭論 Titanic 沉沒時該用哪種救生艇。

Google的Lighthouse性能審計工具，會把「循環中修改DOM」標紅警告，但不會因為用了forEach而非for就扣分。工具的態度很明確：寫法是風格問題，阻塞主線程才是生死問題。

MDN文檔在for循環的頁面底部埋了一句話，很少人注意到：「現代JavaScript中，考慮使用更語義化的數組方法替代傳統循環。」但緊接著又補了半句——「除非你需要精細控制迭代過程。」這算是官方認證的「看場景」吧。

你最近一次寫循環時，是先敲的for還是.map？有沒有遇到過本地跑得好好的、上線就卡死的經歷？