1. 項(xiàng)目概述為什么“去重”是前端開(kāi)發(fā)者的基本功在JavaScript的日常開(kāi)發(fā)里處理數(shù)據(jù)是家常便飯而數(shù)組和對(duì)象又是其中最核心的數(shù)據(jù)結(jié)構(gòu)。我敢說(shuō)幾乎每個(gè)前端開(kāi)發(fā)者都遇到過(guò)這樣的場(chǎng)景從后端拿到一個(gè)用戶(hù)列表里面可能有重復(fù)的用戶(hù)ID或者處理一組商品數(shù)據(jù)需要合并不同來(lái)源但可能重復(fù)的商品信息。這時(shí)候“去重”就成了一個(gè)繞不開(kāi)的操作。簡(jiǎn)單數(shù)組去重比如[1, 2, 2, 3]變成[1, 2, 3]方法很多Set、filter加indexOf信手拈來(lái)。但問(wèn)題一旦升級(jí)到對(duì)象數(shù)組事情就變得棘手了。[{id: 1}, {id: 1}]這兩個(gè)對(duì)象看起來(lái)一樣但在JavaScript引擎眼里它們是兩個(gè)獨(dú)立的內(nèi)存引用直接比較{} {}結(jié)果是false。這就意味著那些對(duì)簡(jiǎn)單數(shù)組行之有效的方法在對(duì)象數(shù)組面前幾乎全部失效?！癑S對(duì)象數(shù)組去重”這個(gè)標(biāo)題背后直指的就是這個(gè)高頻且具體的痛點(diǎn)。它不是一個(gè)炫技的算法題而是一個(gè)實(shí)實(shí)在在的工程問(wèn)題。處理不好輕則導(dǎo)致前端展示重復(fù)用戶(hù)體驗(yàn)下降重則可能在數(shù)據(jù)統(tǒng)計(jì)、狀態(tài)同步時(shí)引發(fā)邏輯錯(cuò)誤。因此掌握一套可靠、高效且適應(yīng)不同場(chǎng)景的對(duì)象數(shù)組去重方案是區(qū)分一個(gè)合格前端和熟練前端的重要標(biāo)志之一。接下來(lái)我就結(jié)合自己多年的踩坑經(jīng)驗(yàn)把對(duì)象數(shù)組去重的門(mén)道給你徹底講透。2. 核心思路拆解從“相等”的定義出發(fā)對(duì)象數(shù)組去重的核心在于如何定義兩個(gè)對(duì)象“相等”。對(duì)于計(jì)算機(jī)來(lái)說(shuō)沒(méi)有模糊的概念我們必須給出精確、可執(zhí)行的判斷規(guī)則。根據(jù)業(yè)務(wù)場(chǎng)景的不同這個(gè)“相等”的定義通常分為幾個(gè)層次選擇的方案也截然不同。2.1 基于唯一標(biāo)識(shí)符的去重這是最常見(jiàn)、也最實(shí)用的場(chǎng)景。對(duì)象數(shù)組中每個(gè)對(duì)象都有一個(gè)或多個(gè)屬性可以唯一標(biāo)識(shí)它自己比如用戶(hù)的id、商品的sku、文章的postId。我們的目標(biāo)就是保留這些唯一標(biāo)識(shí)符首次出現(xiàn)的對(duì)象。為什么這是首選方案因?yàn)樵谡鎸?shí)的業(yè)務(wù)數(shù)據(jù)中對(duì)象往往是復(fù)雜且動(dòng)態(tài)的。除了核心ID其他屬性如name,price,status可能會(huì)因?yàn)閿?shù)據(jù)來(lái)源不同、更新時(shí)間不同而有細(xì)微差異。如果我們追求所有屬性完全一致反而可能丟失有效的數(shù)據(jù)版本?；谖ㄒ粯?biāo)識(shí)符去重邏輯清晰符合大多數(shù)業(yè)務(wù)語(yǔ)義例如同一個(gè)用戶(hù)不應(yīng)該在列表中出現(xiàn)兩次。實(shí)現(xiàn)思路我們需要一個(gè)臨時(shí)存儲(chǔ)通常用Map或普通對(duì)象來(lái)記錄已經(jīng)出現(xiàn)過(guò)的“鍵”。遍歷數(shù)組為每個(gè)對(duì)象生成一個(gè)“鍵”通常是標(biāo)識(shí)符屬性的值檢查這個(gè)鍵是否已存在。如果不存在則記錄該鍵并將當(dāng)前對(duì)象放入結(jié)果數(shù)組如果已存在則跳過(guò)。2.2 基于對(duì)象全等比較的去重這種場(chǎng)景相對(duì)較少但確實(shí)存在。比如你需要確保數(shù)組中的每個(gè)對(duì)象引用都是唯一的或者你的數(shù)據(jù)對(duì)象結(jié)構(gòu)簡(jiǎn)單且穩(wěn)定要求所有屬性值必須完全一致才視為重復(fù)。為什么使用場(chǎng)景有限因?yàn)镴avaScript中對(duì)象是引用類(lèi)型。即使兩個(gè)對(duì)象的內(nèi)容一模一樣它們也是不同的引用。因此直接比較obj1 obj2只有在它們指向內(nèi)存中同一地址時(shí)才為真。要實(shí)現(xiàn)“內(nèi)容全等”比較就需要深度遍歷對(duì)象的每一個(gè)屬性進(jìn)行遞歸或序列化比較性能開(kāi)銷(xiāo)較大且對(duì)于包含函數(shù)、循環(huán)引用的對(duì)象處理起來(lái)很麻煩。實(shí)現(xiàn)思路通常采用序列化的方式將對(duì)象轉(zhuǎn)換為字符串如JSON.stringify然后用字符串去重的方法。但這種方法有局限性函數(shù)、undefined、特定對(duì)象類(lèi)型會(huì)被忽略或轉(zhuǎn)換且性能不是最優(yōu)。更嚴(yán)謹(jǐn)?shù)淖龇ㄊ菍?shí)現(xiàn)一個(gè)深度比較函數(shù)但復(fù)雜度高一般只在特殊需求下使用。2.3 基于自定義比較函數(shù)的去重這是最靈活的方式。當(dāng)“相等”的邏輯不能用簡(jiǎn)單的屬性名或深度比較概括時(shí)就需要自定義。例如去重規(guī)則是“姓名和城市相同即視為同一人”或者“價(jià)格相差在5元以?xún)?nèi)視為相同商品”當(dāng)然這嚴(yán)格來(lái)說(shuō)不是去重是聚類(lèi)但邏輯類(lèi)似。為什么需要靈活性業(yè)務(wù)邏輯是千變?nèi)f化的?？蚣芎蛶?kù)提供的是通用能力而自定義比較函數(shù)是將業(yè)務(wù)規(guī)則注入到工具方法中的橋梁。它把判斷兩個(gè)對(duì)象是否“重復(fù)”的權(quán)力完全交給了開(kāi)發(fā)者。實(shí)現(xiàn)思路實(shí)現(xiàn)一個(gè)通用的去重函數(shù)它接受一個(gè)數(shù)組和一個(gè)比較函數(shù)作為參數(shù)。這個(gè)比較函數(shù)接收兩個(gè)對(duì)象返回一個(gè)布爾值表示它們是否相等。在內(nèi)部仍然需要通過(guò)遍歷和臨時(shí)存儲(chǔ)來(lái)記錄已經(jīng)出現(xiàn)過(guò)的“等價(jià)類(lèi)”但比較邏輯由外部函數(shù)決定。3. 方案實(shí)現(xiàn)與深度解析理論講完了我們直接上代碼看看每種思路具體怎么實(shí)現(xiàn)并深入分析其中的細(xì)節(jié)和陷阱。3.1 方案一使用 Map 與唯一鍵推薦這是目前性能最佳、語(yǔ)義最清晰的方案適用于絕大多數(shù)基于標(biāo)識(shí)符去重的場(chǎng)景。/** * 根據(jù)對(duì)象中指定的唯一鍵進(jìn)行去重 * param {Array} arr - 待去重的對(duì)象數(shù)組 * param {String|Function} key - 唯一鍵的屬性名或一個(gè)生成唯一鍵的函數(shù) * returns {Array} 去重后的新數(shù)組 */ function uniqueByKey(arr, key) { // 參數(shù)校驗(yàn) if (!Array.isArray(arr)) { throw new TypeError(Expected an array as the first argument); } if (arr.length 0) return []; const map new Map(); const result []; for (const item of arr) { // 處理key為函數(shù)的情況允許動(dòng)態(tài)生成唯一標(biāo)識(shí) const identifier typeof key function ? key(item) : item[key]; // 關(guān)鍵檢查標(biāo)識(shí)符是否為有效值避免undefined或null作為鍵導(dǎo)致的問(wèn)題 if (identifier null) { // 寬松相等檢查 null 和 undefined // 處理策略可以選擇跳過(guò)、拋出錯(cuò)誤或允許其通過(guò)。這里我們選擇跳過(guò)并給出警告生產(chǎn)環(huán)境可記錄日志 console.warn(Item with invalid key (${identifier}) encountered and skipped:, item); continue; } // 如果Map中還沒(méi)有這個(gè)標(biāo)識(shí)符則存入并加入結(jié)果數(shù)組 if (!map.has(identifier)) { map.set(identifier, true); // 值存true即可我們只關(guān)心鍵是否存在 result.push(item); } // 如果已存在則跳過(guò)。這里可以根據(jù)需要保留第一次或最后一次出現(xiàn)的項(xiàng)。 // 當(dāng)前邏輯保留第一次出現(xiàn)的項(xiàng)。 } return result; } // 使用示例 const users [ { id: 1, name: Alice }, { id: 2, name: Bob }, { id: 1, name: Alice Again }, // 重復(fù)的id { id: 3, name: Charlie }, { id: 2, name: Bob the Second }, // 重復(fù)的id { name: NoID } // 缺少id屬性的對(duì)象 ]; console.log(uniqueByKey(users, id)); // 輸出: [{ id: 1, name: Alice }, { id: 2, name: Bob }, { id: 3, name: Charlie }] // 注意NoID對(duì)象被跳過(guò)并警告 // 使用函數(shù)生成復(fù)雜鍵 const orders [ { userId: 1, productId: A, date: 2023-10-01 }, { userId: 1, productId: B, date: 2023-10-01 }, { userId: 1, productId: A, date: 2023-10-02 }, { userId: 2, productId: A, date: 2023-10-01 }, ]; // 去重邏輯同一用戶(hù)在同一日期下的同一產(chǎn)品只保留第一單 const uniqueOrders uniqueByKey(orders, (order) ${order.userId}-${order.productId}-${order.date}); console.log(uniqueOrders);深度解析與注意事項(xiàng)為什么用Map而不用普通對(duì)象{}鍵的類(lèi)型Map的鍵可以是任何類(lèi)型包括對(duì)象、函數(shù)而普通對(duì)象的鍵只能是字符串或 Symbol。雖然我們的標(biāo)識(shí)符通常是字符串或數(shù)字但使用Map更具通用性和嚴(yán)謹(jǐn)性避免了數(shù)字鍵被自動(dòng)轉(zhuǎn)換為字符串等隱式轉(zhuǎn)換問(wèn)題。性能在頻繁的增刪查操作中Map的性能通常優(yōu)于普通對(duì)象尤其是在鍵的數(shù)量較多時(shí)。順序Map會(huì)記住鍵的原始插入順序這在某些需要保持去重后順序的場(chǎng)景下是個(gè)優(yōu)點(diǎn)雖然我們這里用數(shù)組本身來(lái)保證順序。對(duì)key參數(shù)的處理支持字符串和函數(shù)兩種形式極大地增強(qiáng)了靈活性。函數(shù)形式讓你可以處理復(fù)合鍵、計(jì)算鍵等復(fù)雜場(chǎng)景?？罩堤幚磉@是非常關(guān)鍵的一點(diǎn)如果對(duì)象的標(biāo)識(shí)符屬性是undefined或nullMap可以存儲(chǔ)它們Map可以存undefined和null作為鍵但這通常意味著數(shù)據(jù)有問(wèn)題。上面的實(shí)現(xiàn)選擇跳過(guò)并警告防止無(wú)效數(shù)據(jù)污染結(jié)果集。在實(shí)際項(xiàng)目中你需要和業(yè)務(wù)方確認(rèn)對(duì)此類(lèi)數(shù)據(jù)的處理策略。保留首次還是末次上述代碼保留首次出現(xiàn)的項(xiàng)這是最常見(jiàn)的需求。如果你想保留最后一次出現(xiàn)的項(xiàng)只需將result.push(item)的邏輯改為更新對(duì)應(yīng)位置但這會(huì)更復(fù)雜。一個(gè)簡(jiǎn)單的技巧是反向遍歷數(shù)組然后反轉(zhuǎn)結(jié)果但會(huì)改變相對(duì)順序。更清晰的做法是在Map里存儲(chǔ)對(duì)象本身最后用Array.from(map.values())但這會(huì)丟失首次出現(xiàn)之后、末次出現(xiàn)之前其他對(duì)象的順序。3.2 方案二使用 JSON.stringify 與 Set慎用這個(gè)方案常被新手想到因?yàn)樗a非常簡(jiǎn)短。function uniqueByJSON(arr) { if (!Array.isArray(arr)) return []; const stringSet new Set(); const result []; for (const obj of arr) { const str JSON.stringify(obj); if (!stringSet.has(str)) { stringSet.add(str); result.push(obj); } } return result; }深度解析與嚴(yán)重缺陷警告此方法不推薦用于生產(chǎn)環(huán)境僅適用于非常特定的、可控的簡(jiǎn)單場(chǎng)景。序列化陷阱JSON.stringify有眾所周知的局限性u(píng)ndefined、函數(shù)、Symbol 類(lèi)型的屬性值會(huì)被完全忽略不會(huì)出現(xiàn)在字符串中。{a: undefined, b: 1}和{b: 1}會(huì)被認(rèn)為是相同的。如果對(duì)象有循環(huán)引用直接調(diào)用會(huì)報(bào)錯(cuò)。NaN和Infinity會(huì)被轉(zhuǎn)換成null。Date對(duì)象會(huì)被轉(zhuǎn)換成字符串。屬性的順序可能會(huì)影響序列化結(jié)果雖然ECMA規(guī)范未定義對(duì)象屬性的枚舉順序但大多數(shù)現(xiàn)代引擎會(huì)按創(chuàng)建順序不過(guò)依賴(lài)這個(gè)并不安全。性能問(wèn)題對(duì)于大對(duì)象或大數(shù)組序列化整個(gè)對(duì)象是昂貴的操作尤其是當(dāng)對(duì)象結(jié)構(gòu)復(fù)雜時(shí)。什么情況下可以用僅當(dāng)你100%確定數(shù)組中的對(duì)象是簡(jiǎn)單的、平面的沒(méi)有嵌套對(duì)象/數(shù)組、不包含上述特殊值、并且屬性順序穩(wěn)定時(shí)可以作為一種“快速原型”手段。即便如此我也建議用更明確的方案一。3.3 方案三使用 reduce 與 find/findIndex理解思路但不推薦這是一種更“函數(shù)式”的寫(xiě)法但在性能上存在隱患。// 使用 findIndex 進(jìn)行深度比較假設(shè)有 deepEqual 函數(shù) function uniqueByDeepCompare(arr) { return arr.reduce((acc, current) { // 在累積數(shù)組acc中查找是否已存在“深度相等”的對(duì)象 const isDuplicate acc.some(item deepEqual(item, current)); if (!isDuplicate) { acc.push(current); } return acc; }, []); } // 使用 findIndex 基于某個(gè)鍵 function uniqueByKeyWithReduce(arr, key) { return arr.reduce((acc, current) { const isDuplicate acc.findIndex(item item[key] current[key]) -1; if (!isDuplicate) { acc.push(current); } return acc; }, []); }深度解析與性能瓶頸算法復(fù)雜度這是這種方法最大的問(wèn)題。對(duì)于數(shù)組中的每一個(gè)元素n個(gè)都要在結(jié)果數(shù)組最壞情況下也是n個(gè)中遍歷查找findIndex或some是 O(n) 操作。這導(dǎo)致了 O(n2) 的時(shí)間復(fù)雜度。當(dāng)數(shù)組長(zhǎng)度超過(guò)幾百時(shí)性能下降會(huì)非常明顯。deepEqual的代價(jià)如果使用深度比較每次比較的代價(jià) O(k)k為對(duì)象大小會(huì)疊加在 O(n2) 上使得性能雪上加霜?？勺x性雖然reduce很強(qiáng)大但這段代碼的邏輯不如方案一中的for...of循環(huán)配合Map那樣直觀易懂尤其是對(duì)不熟悉函數(shù)式編程的同事。結(jié)論不推薦在需要處理可能較大數(shù)組的場(chǎng)景下使用此方法。方案一Map的時(shí)間復(fù)雜度是 O(n)空間復(fù)雜度也是 O(n)性能優(yōu)勢(shì)巨大。3.4 方案四終極靈活方案——自定義比較函數(shù)將比較邏輯抽象出來(lái)提供一個(gè)通用的去重工具函數(shù)。/** * 通用對(duì)象數(shù)組去重函數(shù) * param {Array} arr - 待去重的對(duì)象數(shù)組 * param {Function} comparator - 比較函數(shù)接收兩個(gè)對(duì)象返回true表示相等 * returns {Array} 去重后的新數(shù)組 */ function uniqueByComparator(arr, comparator) { if (!Array.isArray(arr)) return []; if (typeof comparator ! function) { throw new TypeError(Comparator must be a function); } const result []; // 這里我們?nèi)匀恍枰粋€(gè)機(jī)制來(lái)記錄“已見(jiàn)過(guò)”的對(duì)象。 // 但由于比較規(guī)則自定義我們無(wú)法簡(jiǎn)單地用一個(gè)鍵來(lái)記錄。 // 一種方法是對(duì)于result中的每個(gè)新元素都遍歷result中已存在的元素進(jìn)行比較。 // 但這又回到了O(n2)的復(fù)雜度。 // 更優(yōu)的方法是要求comparator能生成一個(gè)可哈希的“簽名”或者接受一個(gè)額外的keyGetter函數(shù)。 // 下面提供一個(gè)更實(shí)用的變體它結(jié)合了key生成器和比較器。 return result; // 基礎(chǔ)框架實(shí)現(xiàn)見(jiàn)下方變體 } /** * 增強(qiáng)版結(jié)合鍵生成器和比較器優(yōu)先使用鍵進(jìn)行高效去重鍵沖突時(shí)使用比較器 * param {Array} arr * param {Function} keyGetter - 生成用于快速查找的鍵的函數(shù) * param {Function} [comparator] - 可選當(dāng)鍵沖突時(shí)用于精細(xì)比較的函數(shù) * returns {Array} */ function uniqueAdvanced(arr, keyGetter, comparator) { const map new Map(); const result []; for (const item of arr) { const key keyGetter(item); // 如果鍵無(wú)效處理策略同方案一 if (key null) { console.warn(Invalid key generated, item skipped:, item); continue; } if (!map.has(key)) { // 如果這個(gè)鍵第一次出現(xiàn)直接存入 map.set(key, item); result.push(item); } else if (comparator) { // 如果鍵已存在并且提供了比較器則用比較器判斷當(dāng)前對(duì)象和已存儲(chǔ)的對(duì)象是否“重復(fù)” const existingItem map.get(key); if (!comparator(existingItem, item)) { // 如果比較器認(rèn)為不重復(fù)注意這里邏輯是“不重復(fù)才添加”根據(jù)comparator語(yǔ)義調(diào)整 // 但通常相同的key我們已經(jīng)認(rèn)為是同一類(lèi)這里comparator用于處理“key相同但實(shí)際不同”的邊緣情況。 // 更常見(jiàn)的需求是key相同且comparator也認(rèn)為相同才去重。否則我們需要一個(gè)新的、不沖突的key // 這揭示了設(shè)計(jì)上的復(fù)雜性。通常keyGetter應(yīng)該能生成絕對(duì)唯一的標(biāo)識(shí)。 // 因此comparator在這里可能不是必須的或者用于二次確認(rèn)。 // 一個(gè)更簡(jiǎn)單的通用設(shè)計(jì)是只使用comparator但用Map存儲(chǔ)序列化后的比較結(jié)果這又回到了性能問(wèn)題。 // 結(jié)論對(duì)于極度復(fù)雜的去重邏輯可能需要專(zhuān)門(mén)定制算法而非通用函數(shù)。 } } // 如果鍵已存在且沒(méi)有提供comparator或comparator認(rèn)為重復(fù)則跳過(guò)保留首次出現(xiàn)的 } return result; }深度解析與設(shè)計(jì)權(quán)衡這個(gè)方案展示了設(shè)計(jì)通用工具的復(fù)雜性。純comparator的方案會(huì)導(dǎo)致性能低下O(n2)。而keyGetter方案本質(zhì)上就是我們的方案一。keyGettercomparator的混合模式試圖在效率和靈活性間取得平衡但邏輯變得復(fù)雜且comparator的調(diào)用場(chǎng)景鍵沖突時(shí)可能很少。實(shí)操建議99%的場(chǎng)景使用方案一uniqueByKey就足夠了。確保你的數(shù)據(jù)有一個(gè)可靠的主鍵或復(fù)合鍵。對(duì)于那1%需要復(fù)雜判等邏輯的場(chǎng)景認(rèn)真評(píng)估是否真的需要通用的去重函數(shù)。也許針對(duì)那個(gè)特定場(chǎng)景寫(xiě)一個(gè)特殊的去重邏輯更簡(jiǎn)單、更高效。如果一定要寫(xiě)通用函數(shù)可以考慮讓comparator函數(shù)同時(shí)返回一個(gè)用于快速查找的“哈希碼”不要求嚴(yán)格唯一但能大大減少需要深度比較的候選對(duì)但這實(shí)現(xiàn)起來(lái)就更復(fù)雜了。4. 性能對(duì)比與實(shí)戰(zhàn)選型光說(shuō)不練假把式我們寫(xiě)個(gè)簡(jiǎn)單的測(cè)試來(lái)對(duì)比一下方案一Map、方案三ReducefindIndex和方案二JSON的性能差異。我們構(gòu)造一個(gè)包含10000個(gè)對(duì)象的數(shù)組其中約有30%的重復(fù)項(xiàng)。// 生成測(cè)試數(shù)據(jù) function generateTestData(size, duplicateRate) { const data []; for (let i 0; i size; i) { data.push({ id: i, value: Value${i}, nested: { prop: Math.random() } }); } // 添加一些重復(fù)項(xiàng) const duplicateCount Math.floor(size * duplicateRate); for (let i 0; i duplicateCount; i) { const randomIndex Math.floor(Math.random() * size); data.push({ ...data[randomIndex] }); // 淺拷貝創(chuàng)建內(nèi)容相同但引用不同的對(duì)象 } return data.sort(() Math.random() - 0.5); // 打亂順序 } const testData generateTestData(10000, 0.3); console.log(測(cè)試數(shù)據(jù)量${testData.length}); // 方案一Map console.time(uniqueByKey-Map); const result1 uniqueByKey(testData, id); console.timeEnd(uniqueByKey-Map); console.log(結(jié)果長(zhǎng)度${result1.length}); // 方案三Reduce findIndex (基于鍵) console.time(uniqueByKey-Reduce); const result3 testData.reduce((acc, current) { const isDuplicate acc.findIndex(item item.id current.id) -1; if (!isDuplicate) acc.push(current); return acc; }, []); console.timeEnd(uniqueByKey-Reduce); console.log(結(jié)果長(zhǎng)度${result3.length}); // 方案二JSON (僅作對(duì)比數(shù)據(jù)符合其要求) // 注意我們的測(cè)試數(shù)據(jù)包含nested對(duì)象和Math.randomJSON序列化后由于nested.prop值不同重復(fù)項(xiàng)可能無(wú)法被正確識(shí)別。 // 為了公平對(duì)比我們使用一個(gè)更簡(jiǎn)單的數(shù)據(jù)。 const simpleData generateTestData(10000, 0.3).map(({id, value}) ({id, value})); // 只保留id和value console.time(uniqueByJSON); const result2 uniqueByJSON(simpleData); console.timeEnd(uniqueByJSON); console.log(結(jié)果長(zhǎng)度${result2.length});在我的環(huán)境中運(yùn)行一次結(jié)果可能類(lèi)似測(cè)試數(shù)據(jù)量13000 uniqueByKey-Map: 2.5ms 結(jié)果長(zhǎng)度10000 uniqueByKey-Reduce: 150.0ms 結(jié)果長(zhǎng)度10000 uniqueByJSON: 15.0ms (在簡(jiǎn)單數(shù)據(jù)上) 結(jié)果長(zhǎng)度10000結(jié)果分析Map方案~2.5ms速度最快時(shí)間復(fù)雜度 O(n)與數(shù)據(jù)量成線性關(guān)系即使數(shù)據(jù)量增大性能衰減也最平緩。Reduce findIndex方案~150ms慢了兩個(gè)數(shù)量級(jí)這是因?yàn)槠?O(n2) 的復(fù)雜度。當(dāng)數(shù)據(jù)量翻倍時(shí)耗時(shí)可能增加近4倍。JSON方案~15ms在簡(jiǎn)單數(shù)據(jù)上表現(xiàn)尚可但如前所述它有嚴(yán)格的適用條件且序列化本身也有開(kāi)銷(xiāo)。實(shí)戰(zhàn)選型指南默認(rèn)選擇Map方案無(wú)論是性能、代碼清晰度還是安全性都是最佳選擇。用它處理基于唯一標(biāo)識(shí)符的去重。永遠(yuǎn)避免Reduce findIndex全量查找方案除非你能絕對(duì)保證數(shù)組長(zhǎng)度永遠(yuǎn)很小比如小于50否則不要使用。謹(jǐn)慎使用JSON方案僅用于臨時(shí)性的、數(shù)據(jù)格式極其簡(jiǎn)單的場(chǎng)景并且要充分了解其缺陷。不要將其作為默認(rèn)方案。復(fù)雜邏輯定制化如果去重邏輯異常復(fù)雜無(wú)法用單一鍵表示優(yōu)先考慮在數(shù)據(jù)源頭進(jìn)行處理或者編寫(xiě)專(zhuān)門(mén)的、非通用的函數(shù)來(lái)解決。犧牲一定的通用性來(lái)?yè)Q取可讀性和性能是值得的。5. 特殊場(chǎng)景與邊界情況處理在實(shí)際項(xiàng)目中數(shù)據(jù)從來(lái)都不是完美的。下面是一些常見(jiàn)的“坑”以及如何處理它們。5.1 處理可能為空的標(biāo)識(shí)符我們?cè)诜桨敢坏拇a中已經(jīng)初步處理了。這里再?gòu)?qiáng)調(diào)一下策略跳過(guò)并記錄如上所示這是比較安全的做法避免無(wú)效數(shù)據(jù)影響主要結(jié)果。適用于標(biāo)識(shí)符缺失為異常情況的場(chǎng)景。保留并視為特殊值如果null或undefined本身就是有意義的標(biāo)識(shí)雖然不常見(jiàn)你可以允許它們作為Map的鍵。但要注意Map可以區(qū)分null、undefined和不存在而普通對(duì)象{}做不到。拋出錯(cuò)誤如果標(biāo)識(shí)符是必填的缺失屬于數(shù)據(jù)錯(cuò)誤應(yīng)該盡早拋出異常讓調(diào)用者處理。5.2 需要保留最后一次出現(xiàn)的對(duì)象業(yè)務(wù)需求有時(shí)是“保留最新的那條記錄”。這時(shí)方案一稍作修改即可。function uniqueByKeyKeepLast(arr, key) { const map new Map(); // 第一遍遍歷用Map記錄每個(gè)鍵最后一次出現(xiàn)的對(duì)象 for (const item of arr) { const identifier typeof key function ? key(item) : item[key]; if (identifier ! null) { map.set(identifier, item); // 始終用最新的對(duì)象覆蓋 } } // 第二遍遍歷按原始順序或標(biāo)識(shí)符順序輸出但每個(gè)鍵只取最后一次的值 // 注意如果要嚴(yán)格保持原數(shù)組中“最后一次出現(xiàn)”的相對(duì)順序需要更復(fù)雜的邏輯。 // 簡(jiǎn)單的方法是直接返回Map的值但順序是Map的插入順序即鍵第一次出現(xiàn)的順序。 // 如果順序不重要 // return Array.from(map.values()); // 如果需要按照鍵的最后一次出現(xiàn)在原數(shù)組中的順序 const result []; const seenKey new Set(); // 倒序遍歷原數(shù)組這樣先遇到的是最后一次出現(xiàn) for (let i arr.length - 1; i 0; i--) { const item arr[i]; const identifier typeof key function ? key(item) : item[key]; if (identifier ! null !seenKey.has(identifier)) { seenKey.add(identifier); // 因?yàn)槲覀兪堑剐虿迦胨孕枰迦氲浇Y(jié)果數(shù)組的頭部或者最后反轉(zhuǎn)數(shù)組 result.unshift(item); // unshift在數(shù)組頭部插入但大數(shù)據(jù)量下性能差 } } // 或者用正序遍歷但用Map存儲(chǔ)索引最后排序邏輯更復(fù)雜。 // 一個(gè)平衡性能和邏輯清晰的做法是用Map存儲(chǔ)對(duì)象再用一個(gè)數(shù)組記錄順序。 const orderMap new Map(); const orderArr []; for (const item of arr) { const identifier typeof key function ? key(item) : item[key]; if (identifier ! null) { orderMap.set(identifier, item); // 記錄順序如果重復(fù)更新索引不我們需要最后一次的順序。 // 更簡(jiǎn)單遍歷完成后再逆序處理。 } } // ... 代碼會(huì)變得冗長(zhǎng)。根據(jù)具體性能要求和數(shù)據(jù)規(guī)模選擇實(shí)現(xiàn)。 // 對(duì)于大多數(shù)情況如果順序不是嚴(yán)格必須Array.from(map.values()) 是可接受的。 return Array.from(map.values()); }可以看到保留末次的邏輯比保留首次要復(fù)雜尤其是對(duì)順序有要求時(shí)。在需求評(píng)審時(shí)盡量明確“保留首次”這更符合直覺(jué)和大多數(shù)場(chǎng)景。5.3 超大數(shù)組的性能與內(nèi)存考慮當(dāng)數(shù)組長(zhǎng)度達(dá)到十萬(wàn)甚至百萬(wàn)級(jí)別時(shí)即使是 O(n) 的算法也需要考慮優(yōu)化。使用Map而非{}如前所述Map在大量鍵值對(duì)時(shí)性能更好。避免在循環(huán)中創(chuàng)建臨時(shí)對(duì)象比如key是函數(shù)且返回新對(duì)象這會(huì)導(dǎo)致大量小對(duì)象被創(chuàng)建和垃圾回收。流式處理如果數(shù)據(jù)來(lái)自文件或網(wǎng)絡(luò)流可以考慮邊讀取邊去重而不是全部加載到內(nèi)存中再處理。這需要數(shù)據(jù)源支持迭代。使用更高效的數(shù)據(jù)結(jié)構(gòu)在極端性能要求下如果鍵是數(shù)字或特定范圍的字符串可以考慮使用Array或TypedArray作為哈希表但這犧牲了通用性。5.4 嵌套對(duì)象與循環(huán)引用如果你的對(duì)象非常深且基于嵌套屬性去重keyGetter函數(shù)需要能安全地訪問(wèn)深層次屬性?？梢允褂胠odash的_.get或自己寫(xiě)一個(gè)安全訪問(wèn)函數(shù)。function getSafe(obj, path, defaultValue) { return path.split(.).reduce((acc, key) (acc acc[key] ! undefined) ? acc[key] : defaultValue, obj); } const data [{ user: { profile: { id: 123 } } }, { user: { profile: { id: 456 } } }]; const key (item) getSafe(item, user.profile.id, null); const uniqueData uniqueByKey(data, key);對(duì)于循環(huán)引用JSON.stringify會(huì)直接報(bào)錯(cuò)。如果去重邏輯涉及序列化必須確保數(shù)據(jù)中沒(méi)有循環(huán)引用或者使用可以處理循環(huán)引用的序列化庫(kù)如flatted。6. 在現(xiàn)代JS項(xiàng)目中的集成與實(shí)踐掌握了核心方法我們來(lái)看看如何將它優(yōu)雅地集成到你的項(xiàng)目中。6.1 封裝為工具函數(shù)或類(lèi)方法在你的項(xiàng)目工具庫(kù)例如src/utils/array.js中導(dǎo)出穩(wěn)定的去重函數(shù)。// utils/array.js export const uniqueBy (arr, key) { // ... 實(shí)現(xiàn)方案一包含健壯的錯(cuò)誤處理 }; export const uniqueByKeepLast (arr, key) { // ... 實(shí)現(xiàn)保留末次的版本 }; // 或者提供一個(gè)配置更全的函數(shù) export const unique (arr, { key, comparator, keep first } {}) { // 根據(jù)參數(shù)選擇不同的內(nèi)部實(shí)現(xiàn) };6.2 與 Lodash 或 Ramda 等工具庫(kù)對(duì)比像lodash這樣的庫(kù)提供了_.uniqBy和_.uniqWith函數(shù)。_.uniqBy(array, [iteratee_.identity])類(lèi)似于我們的uniqueByKeyiteratee可以是屬性名字符串或函數(shù)。_.uniqWith(array, [comparator])使用自定義比較函數(shù)但注意它內(nèi)部可能也是 O(n2) 的復(fù)雜度用于小型數(shù)組或特殊比較。使用建議如果你的項(xiàng)目已經(jīng)引入了lodash并且其體積不是問(wèn)題直接使用_.uniqBy是很好的選擇它經(jīng)過(guò)充分測(cè)試處理了各種邊界情況。如果你追求極致的包體積或者想避免引入大型工具庫(kù)那么自己實(shí)現(xiàn)一個(gè)輕量級(jí)的uniqueByKey是更優(yōu)解。我們的實(shí)現(xiàn)通常只有十幾行代碼功能完全夠用。6.3 在Vue/React狀態(tài)管理中的應(yīng)用在前端框架中去重操作經(jīng)常發(fā)生在處理狀態(tài)時(shí)。Vue (Pinia) 示例// stores/userStore.js import { defineStore } from pinia; import { uniqueBy } from /utils/array; export const useUserStore defineStore(user, { state: () ({ userList: [], }), actions: { // 從API合并用戶(hù)列表并去重 mergeUsers(newUsers) { const merged [...this.userList, ...newUsers]; this.userList uniqueBy(merged, id); }, // 或者作為一個(gè)getter }, getters: { // 獲取去重后的用戶(hù)列表計(jì)算屬性 uniqueUsers: (state) uniqueBy(state.userList, id), }, });React (Redux Toolkit) 示例// features/users/usersSlice.js import { createSlice } from reduxjs/toolkit; import { uniqueBy } from ../../utils/array; const usersSlice createSlice({ name: users, initialState: { list: [] }, reducers: { usersReceived(state, action) { // 假設(shè)action.payload是新獲取的用戶(hù)數(shù)組 const merged [...state.list, ...action.payload]; state.list uniqueBy(merged, id); }, }, }); // 在組件中 import { useSelector } from react-redux; const uniqueUserList useSelector(state uniqueBy(state.users.list, id));關(guān)鍵點(diǎn)在狀態(tài)管理中去重應(yīng)該作為一個(gè)純函數(shù)被調(diào)用確保相同的輸入永遠(yuǎn)得到相同的輸出不產(chǎn)生副作用。這符合Redux和Vuex/Pinia的設(shè)計(jì)原則。6.4 與異步數(shù)據(jù)流結(jié)合RxJS在處理流數(shù)據(jù)時(shí)去重也是一個(gè)常見(jiàn)操作。import { from, of } from rxjs; import { mergeMap, toArray, reduce } from rxjs/operators; // 假設(shè)有一個(gè)發(fā)出用戶(hù)對(duì)象數(shù)組的Observable const userObservable from([ [{id: 1, name: A}, {id: 2, name: B}], [{id: 2, name: B}, {id: 3, name: C}], // 包含重復(fù)的id:2 [{id: 1, name: A}, {id: 4, name: D}], // 包含重復(fù)的id:1 ]); // 我們需要合并所有發(fā)出的數(shù)組并去重 userObservable.pipe( // 將每個(gè)發(fā)出的數(shù)組合并成一個(gè)數(shù)組 reduce((acc, currentArray) acc.concat(currentArray), []), // 對(duì)最終合并的數(shù)組進(jìn)行去重 mergeMap(combinedArray of(uniqueBy(combinedArray, id))) ).subscribe(uniqueUsers { console.log(去重后的用戶(hù)列表:, uniqueUsers); // 輸出: [{id:1,name:A}, {id:2,name:B}, {id:3,name:C}, {id:4,name:D}] });在RxJS中還有distinct、distinctUntilChanged等操作符用于流中單個(gè)值的去重但針對(duì)對(duì)象數(shù)組的合并去重通常還是需要在最終階段使用我們實(shí)現(xiàn)的工具函數(shù)。7. 總結(jié)與個(gè)人心得對(duì)象數(shù)組去重這個(gè)看似簡(jiǎn)單的問(wèn)題深入下去卻涉及數(shù)據(jù)結(jié)構(gòu)選擇、算法復(fù)雜度、API設(shè)計(jì)、邊界處理以及與現(xiàn)代開(kāi)發(fā)流的結(jié)合。經(jīng)過(guò)上面一番梳理我的核心建議可以總結(jié)為三點(diǎn)第一明確“相等”語(yǔ)義是前提。在動(dòng)手寫(xiě)代碼之前一定要和產(chǎn)品經(jīng)理或后端同事確認(rèn)清楚到底什么叫“重復(fù)”是基于ID還是基于幾個(gè)字段的組合抑或是所有字段完全一致這個(gè)定義直接決定了實(shí)現(xiàn)方案。第二Map 唯一鍵是王道。對(duì)于99%的業(yè)務(wù)場(chǎng)景基于Map和對(duì)象唯一標(biāo)識(shí)符的方案是最佳選擇。它性能好O(n)代碼清晰易于理解和維護(hù)。自己封裝一個(gè)uniqueByKey函數(shù)處理好null/undefined鍵的邊界情況就能覆蓋絕大部分需求。第三警惕性能陷阱和語(yǔ)法糖誘惑。JSON.stringify雖然寫(xiě)起來(lái)短但坑太多不要用它處理重要數(shù)據(jù)。array.reduce配合array.find看起來(lái)很“函數(shù)式”但 O(n2) 的復(fù)雜度在數(shù)據(jù)量稍大時(shí)就會(huì)成為性能瓶頸。在追求代碼簡(jiǎn)潔的同時(shí)一定要心里有性能這根弦。最后分享一個(gè)我自己的習(xí)慣在工具函數(shù)中永遠(yuǎn)加上參數(shù)類(lèi)型校驗(yàn)和簡(jiǎn)單的錯(cuò)誤提示。就像我們?cè)趗niqueByKey里做的那樣檢查輸入是否為數(shù)組。這行代碼可能一輩子都不會(huì)觸發(fā)但一旦觸發(fā)比如有人不小心傳了個(gè)null進(jìn)來(lái)它能為你節(jié)省大量的調(diào)試時(shí)間。好的工具函數(shù)不僅是能干活還要能“友好地”告訴調(diào)用者哪里用錯(cuò)了。