深夜11點半，辦公室里只剩下我們前端組幾個人，屏幕的光映著一張張疲憊的臉。

線上報警群突然炸了——新上線的配置中心頁面，用戶一加載就白屏，數據量稍大的企業客戶幾乎全軍覆沒。查來查去，性能分析工具最終指向一行我曾引以為傲、寫得無比順手的代碼：

const mergedData = { ...defaultConfig, ...userConfig };

正是這行“優雅”的 ...，這個被我們當作肌肉記憶的拓展運算符，在遇到一個包含數萬條嵌套規則的用戶配置時，成了拖垮整個頁面的元兇。

那個夜晚，我們不得不緊急回滾、重寫合并邏輯，折騰到凌晨才勉強平息。這次慘痛的教訓讓我徹底明白：拓展運算符不是銀彈，濫用它，就是在代碼里埋雷。

簡潔的假象背后：淺拷貝的幽靈

用 ... 或 Object.assign() 合并對象，意圖清晰，代碼漂亮：

const defaults = { theme: 'dark', version: '1.0' };
const userConfig = { theme: 'light', showTips: true };
const finalConfig = { ...defaults, ...userConfig };

但當對象嵌套時，這份“簡潔”便開始滋生副作用。它們進行的都是淺拷貝，只復制了第一層屬性的引用。

const source = {
  user: 'Alice',
  profile: { age: 25, hobbies: ['coding', 'reading'] }
};

const merged = { ...source, user: 'Bob' };
merged.profile.age = 30; // 你以為只在改新對象？

console.log(source.profile.age); // 輸出：30！原始數據被污染了。

在一個復雜的應用里，這種悄無聲息的數據污染如同幽靈，引發的 Bug 往往難以追蹤。你以為在操作一個新對象，實則可能撼動了整個應用狀態的基石。

被忽視的性能炸彈：當數據量爆炸時

淺拷貝的危害尚且屬于邏輯隱患，而更直接、更具破壞性的問題，則發生在大數據量場景下。這正是讓我們團隊加班到深夜的罪魁禍首。

拓展運算符在處理大型數組或深層嵌套的復雜對象時，性能開銷會呈指數級增長。 它需要遍歷所有可枚舉屬性，并將其展開到一個新對象中。當你在合并一個包含數萬條記錄、每條記錄又有復雜子結構的配置對象時，這個過程會阻塞主線程，直接導致頁面渲染卡頓甚至崩潰。

// 假設這是從后端獲取的龐大用戶配置
const hugeUserConfig = fetchHugeConfig(); // 一個深度很大或屬性極多的對象

// 危險操作：試圖用拓展符合并
const combined = {
  ...defaultSettings, // 默認配置
  ...hugeUserConfig   // 海量數據在此展開，可能導致長時間停頓或內存暴漲
};

在我們的案例中，正是這樣的操作，讓瀏覽器在解析和合并階段消耗了遠超預期的時間和內存，最終導致頁面無法響應。

如何安全地“合并”：深拷貝與策略選擇

那么，如何避免踩坑？關鍵在于根據場景，選擇正確的工具。

(1) 深拷貝是隔離副作用的前提

對于需要完全隔離的嵌套數據，應首先進行深拷貝。現代瀏覽器和 Node.js 環境提供了原生的 structuredClone() 方法，它使用結構化克隆算法，安全且高效。

const source = { profile: { age: 25 } };

// 先深拷貝，再合并
const safeMerged = { ...structuredClone(source), user: 'Bob' };
safeMerged.profile.age = 30;
console.log(source.profile.age); // 輸出：25 ? 原始數據安全

(2) 針對大數據量的合并策略

當處理龐大數據時，應避免在內存中進行一次性全量展開和合并。

• 分治策略：如果可能，將大配置拆分成多個模塊，按需加載和合并。
• 惰性合并：只在訪問某個具體屬性時，才計算最終的合并值。
• 使用專用工具庫：對于極其復雜的合并邏輯（如深度合并、自定義規則等），考慮使用 lodash.merge 等經過充分優化的庫，但同樣需警惕其性能開銷。
• 源頭優化：與后端協商，減少不必要的數據傳輸，或在服務端完成部分合并邏輯。