能運行，不代表它是對的：五個潛伏在正常功能下的 JavaScript 錯誤
JavaScript 的動態性和復雜性意味著，代碼雖然表面上正常運行，但一些深層次、隱蔽的陷阱往往讓人意想不到，梳理了幾個 JavaScript 開發中難以發現的隱蔽錯誤，旨在幫助我們寫出更健壯、更可預測的代碼。
來看下那些潛伏在代碼中的“惡魔細節”。
1. async/await 的隱式陷阱：忘記 try...catch
async/await 極大地改善了異步代碼的可讀性，但它也帶來了一個隱蔽的風險：未被捕獲的 Promise reject 會變成一個靜默的、未處理的異常。
錯誤場景：
async function fetchData() {
// 如果 API 返回 404 或 500，這個 Promise 會被 reject
const data = await fetch('https://api.example.com/data');
console.log('數據處理完成', data); // 這一行永遠不會執行
}
// 調用函數，但沒有處理潛在的錯誤
fetchData();
console.log('程序繼續執行'); // 程序會繼續，但錯誤被“吞掉”了問題根源：await 只是一個語法糖，它會暫停 async 函數的執行，等待 Promise 解決。如果 Promise被 reject，await 會將其作為異常拋出。如果沒有 try...catch 塊來捕獲這個異常，它就會沿著調用棧向上傳播，最終成為一個 unhandledrejection。
正確姿勢：始終用 try...catch 包裹 await 表達式，或者在調用鏈的更高層級進行捕獲。
async function fetchData() {
try {
const response = await fetch('https://api.example.com/data');
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json();
console.log('數據處理完成', data);
} catch (error) {
console.error('獲取數據失敗:', error);
}
}
fetchData();2. Promise.all 的“一榮俱榮，一損俱損”
當需要并行處理多個 Promise 時，Promise.all 是首選。但高手有時會忘記它的“快速失敗”（Fail-Fast）特性。
錯誤場景：假設我們需要獲取用戶詳情和他的帖子列表，即使獲取帖子失敗，也希望看到用戶詳情。
async function getUserProfile(userId) {
try {
const [user, posts] = await Promise.all([
api.fetchUser(userId), // 這個成功了
api.fetchPosts(userId) // 但這個因為網絡問題失敗了
]);
renderProfile(user, posts);
} catch (error) {
// 整個 block 都失敗了，我們連 user 數據都拿不到
console.error('獲取用戶 Profile 失敗', error);
}
}問題根源：Promise.all 的設計是，只要其中任何一個 Promise被 reject，整個 Promise.all 就會立即 reject，并返回那個失敗的原因，而不會等待其他 Promise 完成。
正確姿勢：使用 Promise.allSettled。它會等待所有 Promise 都有結果（無論是 fulfilled 還是 rejected），然后返回一個包含每個 Promise 狀態和結果（或原因）的對象數組。
async function getUserProfile(userId) {
const results = await Promise.allSettled([
api.fetchUser(userId),
api.fetchPosts(userId)
]);
const userResult = results[0];
const postsResult = results[1];
if (userResult.status === 'fulfilled') {
// 即使帖子失敗，我們依然可以渲染用戶信息
renderUser(userResult.value);
} else {
console.error('獲取用戶失敗:', userResult.reason);
}
if (postsResult.status === 'fulfilled') {
renderPosts(postsResult.value);
} else {
console.error('獲取帖子失敗:', postsResult.reason);
}
}3. 數組迭代中的意外突變
在 forEach 或 for...of 循環中直接修改（增加或刪除）數組本身，是導致不可預測行為的常見原因。
錯誤場景：從數組中移除所有偶數。
問題根源：當你使用 splice 刪除一個元素時，數組的長度和后續元素的索引都會發生變化。但 forEach 的迭代過程并不會根據這個變化來調整它的內部計數器，導致它跳過緊跟在被刪除元素后面的那個元素。
正確姿勢：不要在迭代中修改原數組。最好的方法是創建一個新數組。
如果確實需要在原地修改，請使用反向循環。
4. 閉包的記憶陷阱與內存泄漏
閉包是 JavaScript 的強大特性，但也是內存泄漏的主要來源之一，尤其是在處理 DOM 事件監聽時。
錯誤場景：
問題根源：即使 element 從 DOM 中移除，只要事件監聽器沒有被顯式地移除（removeEventListener），這個監聽器（閉包）就依然存在，并且它會一直引用著 heavyObject。這導致 heavyObject 和 element 都無法被垃圾回收器回收。
正確姿勢：在組件卸載或元素銷毀時，務必清理事件監聽器。
5. 對象的深拷貝與淺拷貝之謎
這是一個永恒的話題。即使是資深開發者，也可能在不經意間對嵌套對象進行了淺拷貝，導致了意想不到的副作用。
錯誤場景：
問題根源：Object.assign() 和展開語法 ... 都只執行淺拷貝。它們會創建一個新的頂層對象，但如果屬性值是對象或數組，它們只會復制引用，而不是值。
正確姿勢：對于深層嵌套的對象，需要使用深拷貝，關于深拷貝可參考前文《一行代碼實現深拷貝？別再用 JSON.stringify 了！》。
簡單場景 (無函數、undefined、Symbol等):const deepCopiedProfile = structuredClone(userProfile); // JSON.parse(JSON.stringify(userProfile));復雜場景: 使用成熟的庫，如 Lodash 的 _.cloneDeep()。
JavaScript 是一門看似簡單實則充滿細節的語言，當我們開始對這些“小問題”變得敏感時，代碼質量和開發效率必將邁上一個新的臺階。
