處理 JS 數(shù)組去重幾乎是每個(gè)前端和 Node 開發(fā)都繞不開的事。平時(shí)數(shù)據(jù)量小怎么寫都不卡可一旦數(shù)據(jù)量拉到百萬(wàn)級(jí)不同去重方式之間的差距會(huì)從“都能用”變成“一個(gè)幾十毫秒、一個(gè)卡死頁(yè)面”。我之前在優(yōu)化一個(gè)數(shù)據(jù)清洗腳本時(shí)就因?yàn)轫樖钟昧薴ilter indexOf去重 100 萬(wàn)行數(shù)據(jù)跑了將近十分鐘一度以為程序死循環(huán)了。后來(lái)?yè)Q成 Set幾十毫秒出結(jié)果。這個(gè)反差讓我徹底明白js 去重方式不是隨手挑一個(gè)就行在百萬(wàn)級(jí)數(shù)據(jù)量級(jí)下選錯(cuò)方式是真的會(huì)出事。這篇內(nèi)容主要講兩件事一是各種主流 js 去重方式的底層原理和時(shí)間復(fù)雜度二是我在百萬(wàn)級(jí)數(shù)據(jù)下實(shí)際跑出來(lái)的結(jié)果以及不同場(chǎng)景下到底該怎么選。無(wú)論你是剛接觸前端不久還是在搞埋點(diǎn)日志、數(shù)據(jù)清洗這份對(duì)比和踩坑記錄都值得收藏。1. 去重方式的底層差異為什么 Set 能把百萬(wàn)級(jí)數(shù)據(jù)按在地上摩擦1.1 先說(shuō)結(jié)論查重思路決定時(shí)間復(fù)雜度常見的去重方式有 Set、Map、filter indexOf、對(duì)象鍵值法、排序去重、雙重循環(huán)。表面上看都是“把重復(fù)元素干掉”但它們判斷重復(fù)的方式完全不同性能差距也由此而來(lái)。Set 和 Map 底層都是哈希表結(jié)構(gòu)。插入一個(gè)元素時(shí)能平均在 O(1) 時(shí)間內(nèi)完成“這個(gè)值我之前有沒有見過(guò)”的判斷。循環(huán) n 個(gè)元素總時(shí)間復(fù)雜度就是 O(n)。filter indexOf 則完全不同每次 indexOf 都要從數(shù)組頭開始掃描判斷一個(gè)元素需要遍歷一遍已有數(shù)組內(nèi)層循環(huán)套外層循環(huán)整體就是 O(n2)。百萬(wàn)級(jí)數(shù)據(jù)下n 1,000,000O(n2) 意味著大約 10^12 次操作而 O(n) 只有一百萬(wàn)次理論差距就是百萬(wàn)倍。即便哈希表有常數(shù)開銷這個(gè)數(shù)量級(jí)差距也已經(jīng)決定勝負(fù)了。1.2 百萬(wàn)級(jí)數(shù)據(jù)量到底放大了什么100 萬(wàn)條數(shù)據(jù)對(duì)瀏覽器來(lái)說(shuō)已經(jīng)不是小數(shù)目。一個(gè)純數(shù)字的數(shù)組按 Number 類型每個(gè) 8 字節(jié)算大約占用 8MB 左右如果存的是字符串或者對(duì)象內(nèi)存占用會(huì)成倍上漲。這個(gè)時(shí)候如果去重方法還要?jiǎng)?chuàng)建大量中間數(shù)組、反復(fù)深拷貝或者出現(xiàn)嵌套循環(huán)內(nèi)存和 GC 壓力會(huì)跟著爆炸不是光慢那么簡(jiǎn)單有可能直接把標(biāo)簽頁(yè)搞崩。我用一個(gè)生活化類比indexOf 去重就像是新來(lái)一個(gè)人要挨個(gè)問(wèn)前面所有人“你們見過(guò)這個(gè)人嗎”每來(lái)一個(gè)都問(wèn)一遍人越多詢問(wèn)次數(shù)膨脹得越離譜。而 Set 是給每個(gè)值一個(gè)獨(dú)立柜子看到新名字先打開對(duì)應(yīng)柜子看看有沒有人有就跳過(guò)沒有就登記。柜子查找是常數(shù)時(shí)間即便 100 萬(wàn)人也只需要 100 萬(wàn)次開柜子。差距就是這么來(lái)的。1.3 核心衡量指標(biāo)時(shí)間復(fù)雜度、內(nèi)存、可讀性選去重方式不能只看速度還要兼顧內(nèi)存和可讀性。時(shí)間復(fù)雜度在百萬(wàn)級(jí)數(shù)據(jù)下基本決定一切Set、Map 這類哈希方案統(tǒng)治級(jí)領(lǐng)先。內(nèi)存方面Set/Map 本身要有額外哈希表開銷但相比 O(n2) 方案不斷創(chuàng)建臨時(shí)數(shù)組和頻繁調(diào)用棧通常還是更劃算?？勺x性上Set 一行代碼最直觀Map 做對(duì)象數(shù)組按字段去重時(shí)邏輯也很清晰。我一般按這個(gè)順序權(quán)衡先看會(huì)不會(huì)修改原數(shù)組再看時(shí)間復(fù)雜度和內(nèi)存最后考慮代碼給別人看的時(shí)候要不要解釋半天。百萬(wàn)級(jí)數(shù)據(jù)場(chǎng)景下時(shí)間和內(nèi)存優(yōu)先級(jí)最高代碼稍微繞一點(diǎn)加注釋就行但性能不行就真的不行。2. 百萬(wàn)級(jí)數(shù)據(jù)實(shí)測(cè)搭一個(gè)能復(fù)現(xiàn)的基準(zhǔn)測(cè)試2.1 測(cè)試環(huán)境與數(shù)據(jù)準(zhǔn)備先說(shuō)測(cè)試環(huán)境Node.js 18.16.0M1 MacBook Pro16G 內(nèi)存。瀏覽器端結(jié)論類似但不同 JS 引擎對(duì) Set 的優(yōu)化有差異數(shù)字不會(huì)完全一致。想復(fù)現(xiàn)的話把代碼粘到 Node 環(huán)境直接跑就行。數(shù)據(jù)準(zhǔn)備很關(guān)鍵。不能用固定順序的數(shù)組如果數(shù)據(jù)恰好有序排序去重會(huì)占大便宜。為了模擬真實(shí)混排數(shù)據(jù)我用隨機(jī)數(shù)生成 100 萬(wàn)條數(shù)組取值范圍 0 到 499999這樣重復(fù)率不會(huì)太低也不會(huì)全部重復(fù)。生成代碼很簡(jiǎn)單const arr Array.from({ length: 1000000 }, () Math.floor(Math.random() * 500000));這行代碼會(huì)在內(nèi)存里生成約 100 萬(wàn)個(gè)隨機(jī)數(shù)。取值范圍 50 萬(wàn)理論上隨機(jī)生成 100 萬(wàn)個(gè)位置去重后大約 43 萬(wàn)左右重復(fù)率約 57%。真實(shí)業(yè)務(wù)里的臟數(shù)據(jù)通常就是這個(gè)量級(jí)有重復(fù)但不至于全是重復(fù)。2.2 測(cè)試代碼與運(yùn)行方式因?yàn)?Set 這類方案耗時(shí)可能只有幾十毫秒而 filter indexOf 直接跑 100 萬(wàn)可能等到天荒地老所以我把所有方案放在同一份腳本里用 performance.now 計(jì)時(shí)多跑幾次取中位數(shù)避免單次抖動(dòng)。每個(gè)方案都傳入同一個(gè) arr但方法內(nèi)部自己拷貝需要處理的數(shù)據(jù)避免前面方法改了原數(shù)組影響后面的結(jié)果。const { performance } require(perf_hooks); function test(name, fn, data) { const start performance.now(); const result fn(data); const end performance.now(); console.log(name, (end - start).toFixed(2) ms, 去重后長(zhǎng)度:, result.length); } // filterindexOf 在 100 萬(wàn)數(shù)據(jù)下太慢單獨(dú)準(zhǔn)備一個(gè) 5 萬(wàn)子集 const smallArr arr.slice(0, 50000); test(Set去重, (data) [...new Set(data)], arr); test(Map去重, (data) [...new Map(data.map((item) [item, item])).keys()], arr); test(對(duì)象鍵值去重, (data) { const obj {}; return data.filter((item) { if (obj[item]) return false; obj[item] true; return true; }); }, arr); test(排序相鄰去重, (data) { const sorted [...data].sort((a, b) a - b); return sorted.filter((item, i) i 0 || item ! sorted[i - 1]); }, arr); test(filterindexOf, (data) data.filter((item, index) data.indexOf(item) index), smallArr);我在測(cè)試時(shí)特意把 filter indexOf 單獨(dú)放到 5 萬(wàn)條數(shù)據(jù)上不直接跑 100 萬(wàn)因?yàn)?100 萬(wàn)條下它可能要等好幾分鐘腳本看起來(lái)就像卡死了。這也是踩坑之后學(xué)到的教訓(xùn)基準(zhǔn)測(cè)試也要先評(píng)估被測(cè)試方法能不能扛住測(cè)試規(guī)模不能拍腦袋直接全部跑 100 萬(wàn)。2.3 從數(shù)據(jù)上理解為什么差了幾個(gè)數(shù)量級(jí)我這邊跑出來(lái)的結(jié)果大致如下具體數(shù)字和運(yùn)行環(huán)境有關(guān)但數(shù)量級(jí)差距不會(huì)變?nèi)ブ胤绞綌?shù)據(jù)量耗時(shí)去重結(jié)果長(zhǎng)度Set100 萬(wàn)約 25~35ms約 43 萬(wàn)Map100 萬(wàn)約 35~45ms約 43 萬(wàn)對(duì)象鍵值100 萬(wàn)約 50~70ms約 43 萬(wàn)排序相鄰100 萬(wàn)約 120~180ms約 43 萬(wàn)filterindexOf5 萬(wàn)約 1500~2000ms約 4.8 萬(wàn)注意表格里的 filter indexOf 只跑了 5 萬(wàn)條數(shù)據(jù)。它的復(fù)雜度是 O(n2)數(shù)據(jù)量從 5 萬(wàn)漲到 100 萬(wàn)變成了 20 倍耗時(shí)理論上要變成 400 倍。按 1.5 秒估算到 100 萬(wàn)就是 600 秒約 10 分鐘。這個(gè)數(shù)量級(jí)基本是災(zāi)難不是優(yōu)化能救回來(lái)的。3. 五種主流去重方式逐個(gè)拆解與結(jié)果對(duì)比3.1 Set 去重一行代碼為什么最快Set 去重是現(xiàn)在最常用的寫法核心就是利用 Set 存唯一值的特性const unique [...new Set(arr)]; // 或者 Array.from(new Set(arr))Set 底層使用哈希表插入時(shí)計(jì)算哈希值定位到桶沖突概率小的話平均 O(1) 完成插入。整個(gè)過(guò)程只需要一次循環(huán)不需要額外的 indexOf 掃描內(nèi)存多出一份 Set 結(jié)構(gòu)的大小。字符串、數(shù)字、布爾值這些原始類型都可以直接存NaN 也能正確去重這是它相比 indexOf 方案的一個(gè)隱藏優(yōu)勢(shì)。我實(shí)際測(cè)下來(lái)100 萬(wàn)數(shù)據(jù) Set 去重基本都在幾十毫秒內(nèi)代碼只有一行幾乎沒有比它更好的性價(jià)比。唯一的硬傷是對(duì)引用類型Set 比較的是引用地址而不是結(jié)構(gòu)。兩個(gè)內(nèi)容完全一樣的對(duì)象只要不是同一個(gè)引用Set 就不會(huì)去重。這個(gè)后面講對(duì)象數(shù)組去重時(shí)會(huì)單獨(dú)說(shuō)。3.2 filter indexOf典型 O(n2) 反面教材代碼非常好讀const unique arr.filter((item, index) arr.indexOf(item) index);意思就是只有當(dāng)某個(gè)元素在數(shù)組里第一次出現(xiàn)的位置就是當(dāng)前位置時(shí)才保留它。問(wèn)題在于indexOf 每次都要從數(shù)組頭部開始遍歷查找filter 本身也要整體遍歷一遍很多元素會(huì)被反復(fù)掃描。數(shù)據(jù)量小的時(shí)候沒感覺到百萬(wàn)級(jí)就是災(zāi)難。我這邊測(cè) 5 萬(wàn)條數(shù)據(jù)已經(jīng)要 1.5 秒以上如果強(qiáng)行跑 100 萬(wàn)10 分鐘是保守估計(jì)。這還沒算 filter 會(huì)創(chuàng)建新數(shù)組indexOf 在查找時(shí)不斷訪問(wèn)原數(shù)組帶來(lái)大量?jī)?nèi)存和 CPU 緩存開銷。真實(shí)瀏覽器環(huán)境里這段代碼會(huì)讓頁(yè)面長(zhǎng)時(shí)間無(wú)響應(yīng)體驗(yàn)極差。如果業(yè)務(wù)上真的繞不開這個(gè)寫法最多也就處理幾百到幾千條數(shù)據(jù)。超過(guò)這個(gè)量級(jí)老老實(shí)實(shí)用 Set 或 Map。不要覺得 filter indexOf 簡(jiǎn)潔就無(wú)腦用簡(jiǎn)潔在這一場(chǎng)景里是陷阱。3.3 對(duì)象/Map 鍵值法和 Set 很像但陷阱不少對(duì)象鍵值法的常見寫法有兩種一種是對(duì)象當(dāng)哈希表一種是 Map。先說(shuō)對(duì)象const obj {}; const unique arr.filter((item) { if (obj[item]) return false; obj[item] true; return true; });這個(gè)方案看起來(lái)也是 O(n)但有幾個(gè)坑。第一對(duì)象的鍵名只能是字符串或 Symbol數(shù)字會(huì)被轉(zhuǎn)成字符串于是 1 和 1 會(huì)被當(dāng)成同一個(gè)鍵。第二如果數(shù)據(jù)里有 proto、constructor 這類特殊字符串直接 obj[item] 可能造成原型鏈污染甚至誤判。第三對(duì)象普通屬性的讀寫比 Map 要慢一些。所以我用對(duì)象做百萬(wàn)級(jí)測(cè)試時(shí)耗時(shí)通常是 Set 的兩倍左右。用 Map 會(huì)更穩(wěn)const map new Map(); arr.forEach((item) { if (!map.has(item)) map.set(item, true); }); const unique [...map.keys()];Map 的鍵可以是任意類型讀寫性能和 Set 接近而且不會(huì)把數(shù)字強(qiáng)轉(zhuǎn)字符串。如果只做去重Set 其實(shí)更合適如果后續(xù)還要保留每個(gè)鍵對(duì)應(yīng)的某個(gè)值那 Map 是首選。百萬(wàn)級(jí)數(shù)據(jù)下 Map 去重通常比 Set 慢 10~20ms差距不大可以接受。3.4 排序 相鄰比較時(shí)間不差但要注意副作用思路是先排序再遍歷一次只保留和上一個(gè)元素不同的值const sorted [...arr].sort((a, b) a - b); const unique sorted.filter((item, i) i 0 || item ! sorted[i - 1]);排序時(shí)間復(fù)雜度 O(n log n)比 O(n) 差一點(diǎn)但比 O(n2) 好很多。實(shí)測(cè) 100 萬(wàn)數(shù)據(jù)大概 120~180ms某些場(chǎng)景下依然可用。但有兩個(gè)坑一是 sort 會(huì)改變?cè)仨樞蛉绻阆ＭＡ舻谝淮纬霈F(xiàn)的順序排序去重直接不滿足二是比較函數(shù)如果寫不好對(duì)有 NaN 的數(shù)組會(huì)得到很奇怪的結(jié)果。代碼里我用的是數(shù)字比較函數(shù)如果數(shù)組里有字符串需要換成 localeCompare 之類的比較器。還有sort 方法會(huì)修改原數(shù)組所以我先做了淺拷貝 [...arr]這也會(huì)增加一份內(nèi)存。如果原數(shù)組順序無(wú)所謂排序去重是個(gè)折中方案但能 Set 還是首選 Set因?yàn)?Set 代碼更短、更快。3.5 雙重循環(huán) / 標(biāo)記法只適合小數(shù)組或特殊去重有些人不用 Set是因?yàn)闃I(yè)務(wù)場(chǎng)景要求按對(duì)象的某個(gè)字段去重或者要保持原順序。這時(shí)候可能會(huì)寫雙重循環(huán)const unique []; for (let i 0; i arr.length; i) { let isDuplicate false; for (let j 0; j unique.length; j) { if (unique[j] arr[i]) { isDuplicate true; break; } } if (!isDuplicate) unique.push(arr[i]); }這本質(zhì)上也是 O(n2)而且比 filter indexOf 還多一個(gè)數(shù)組 push百萬(wàn)級(jí)數(shù)據(jù)下絕對(duì)不能碰。它唯一的優(yōu)勢(shì)是可以在比較時(shí)寫復(fù)雜邏輯比如比較對(duì)象多個(gè)字段。但更好的做法是用 Map 把查找重復(fù)的復(fù)雜度降到 O(1)循環(huán)本身保持 O(n)。對(duì)于 Canvas 里面實(shí)時(shí)處理上萬(wàn)個(gè)點(diǎn)雙重循環(huán)勉強(qiáng)能用但超過(guò) 10 萬(wàn)就要考慮換方案了。4. 不同業(yè)務(wù)場(chǎng)景下的最佳去重方案4.1 純?cè)贾禂?shù)組無(wú)腦用 Set如果數(shù)組元素是數(shù)字、字符串、布爾值這類原始值不需要額外保留每個(gè)值對(duì)應(yīng)的其他信息Set 就是最優(yōu)解。代碼最簡(jiǎn)單速度最快也不容易出錯(cuò)。唯一要確認(rèn)的是兼容性IE 不支持 Set但現(xiàn)在還在做 IE 適配的場(chǎng)景已經(jīng)不多了就算要兼容也應(yīng)該用 polyfill而不是換成一個(gè) O(n2) 的方案。我之前在優(yōu)化一個(gè)百萬(wàn)級(jí) ID 數(shù)組時(shí)試過(guò)用 reduce 手動(dòng)去重代碼寫了一大段性能還是不如 Set。后面想通了簡(jiǎn)單場(chǎng)景不要炫技直接const uniqueIds [...new Set(ids)];干凈、快、不容易出 bug。4.2 對(duì)象數(shù)組按字段去重用 Map 做 key 映射對(duì)象數(shù)組去重是另一個(gè)高頻場(chǎng)景比如日志列表按 userId 去重商品列表按 sku 去重。如果直接用 Set兩個(gè)字段相同但引用不同的對(duì)象會(huì)被當(dāng)成不同元素去不掉。正確做法是用 Map把要去重的字段拼成 keyconst list [ { id: 1, name: a }, { id: 2, name: b }, { id: 1, name: c }, ]; const map new Map(); for (const item of list) { const key item.id; if (!map.has(key)) map.set(key, item); } const unique [...map.values()];如果去重字段不止一個(gè)可以把多個(gè)字段拼成一個(gè)字符串作 key但要注意分隔符的選擇。比如key ${item.type}-${item.id} 時(shí)如果 type 或 id 本身可能包含 -就會(huì)撞 key。更穩(wěn)妥的辦法是用嵌套 MapouterMap.get(type).set(id, item)或者手動(dòng)構(gòu)造一個(gè)穩(wěn)定的字符串 key。JSON.stringify 一個(gè)只含目標(biāo)字段的小對(duì)象也是一種辦法但要注意字段聲明順序不同會(huì)產(chǎn)生不同 key。這個(gè)坑我在實(shí)際項(xiàng)目中踩過(guò)兩個(gè)重復(fù)項(xiàng)沒被去掉統(tǒng)計(jì)數(shù)據(jù)差了一大截。4.3 超大數(shù)組內(nèi)存敏感分片處理或原地標(biāo)記如果數(shù)據(jù)量不只百萬(wàn)而是上千萬(wàn)或者運(yùn)行環(huán)境是內(nèi)存緊張的設(shè)備Set/Map 的內(nèi)存開銷也要考慮。Set 對(duì)每個(gè)元素都要維護(hù)哈希表項(xiàng)內(nèi)存可能比原數(shù)組大好幾倍。這時(shí)候可以分片處理比如每次處理 20 萬(wàn)條去重后合并用全局 Set 存放已見值function dedupeInChunks(arr, chunkSize 200000) { const seen new Set(); const result []; for (let i 0; i arr.length; i chunkSize) { const chunk arr.slice(i, i chunkSize); for (const item of chunk) { if (!seen.has(item)) { seen.add(item); result.push(item); } } } return result; }這種寫法的時(shí)間復(fù)雜度仍是 O(n)內(nèi)存不會(huì)一次性塞入全部 Set適合數(shù)據(jù)量特別大的場(chǎng)景。代價(jià)是代碼變長(zhǎng)。如果內(nèi)存非常緊張可以不 slice直接通過(guò)索引在原數(shù)組上遍歷。4.4 需要保持順序不同方案順序表現(xiàn)保留順序的需求經(jīng)常被忽略。Set、Map、filter indexOf 天然保留第一次出現(xiàn)的順序。對(duì)象鍵值法如果只用 filter 也是保留順序的但特殊鍵名有風(fēng)險(xiǎn)。排序去重會(huì)改變順序不適合需要按原順序輸出的場(chǎng)景。如果在去重的同時(shí)還需要把每類數(shù)據(jù)的最后一條記錄取出來(lái)Map 也可以實(shí)現(xiàn)更復(fù)雜的操作通過(guò)每次都更新 value 就行。這是 Set 做不到的需要按場(chǎng)景選型。4.5 性能速查表方案時(shí)間復(fù)雜度內(nèi)存占用是否保序百萬(wàn)級(jí)實(shí)測(cè)參考適用場(chǎng)景SetO(n)中是25~35ms原始值數(shù)組首選MapO(n)中是35~45ms對(duì)象按字段去重/需要鍵值映射對(duì)象鍵值O(n)低是50~70ms簡(jiǎn)單場(chǎng)景注意鍵名陷阱排序相鄰O(n log n)高排序拷貝否120~180ms不要求順序數(shù)據(jù)非海量filterindexOfO(n2)中是5萬(wàn)約1.5s只適合幾百到幾千的小數(shù)組表格里的耗時(shí)是我個(gè)人環(huán)境的結(jié)果不代表所有瀏覽器但時(shí)間復(fù)雜度是確定的。你在自己機(jī)器上跑一遍就能驗(yàn)證這個(gè)數(shù)量級(jí)。5. 實(shí)戰(zhàn)案例百萬(wàn)級(jí)日志按用戶去重的完整方案5.1 需求描述與踩坑案例一個(gè)真實(shí)場(chǎng)景某天我需要處理 100 萬(wàn)條登錄日志每條 log 是一個(gè)對(duì)象包含 uid、time、device 等字段。業(yè)務(wù)要求按 uid 去重并且保留每個(gè) uid 最新的一條日志。數(shù)據(jù)量百萬(wàn)級(jí)如果寫雙重循環(huán)或者 filter indexOf頁(yè)面或者 Node 腳本基本就廢了。一開始同事用 sort 按時(shí)間倒序排然后 filter 相鄰 uid 去重logs.sort((a, b) Date.parse(b.time) - Date.parse(a.time)); const result logs.filter((item, i) i 0 || item.uid ! logs[i - 1].uid);這個(gè)方案在 100 萬(wàn)條數(shù)據(jù)下大約跑了 1 秒多看起來(lái)還行但它改變了原數(shù)組順序而且如果 uid 是數(shù)字和字符串混合判斷item.uid ! logs[i - 1].uid就會(huì)把123和123當(dāng)成不同用戶。我們線上就因?yàn)檫@個(gè)踩了坑。5.2 高效實(shí)現(xiàn)與關(guān)鍵代碼最穩(wěn)的方案是直接一遍 Map邊遍歷邊比較時(shí)間保留最新記錄。時(shí)間復(fù)雜度 O(n)也不會(huì)被 uid 類型混合影響const map new Map(); for (const log of logs) { const uid String(log.uid); // 統(tǒng)一字符串 key避免 123 和 123 分離 const old map.get(uid); if (!old || Date.parse(log.time) Date.parse(old.time)) { map.set(uid, log); } } const result [...map.values()];如果不想每次比較都重新 Date.parse可以先預(yù)處理一個(gè)小結(jié)構(gòu)把日志時(shí)間轉(zhuǎn)成時(shí)間戳再進(jìn) Mapconst map new Map(); for (let i 0; i logs.length; i) { const log logs[i]; const uid String(log.uid); const timestamp Date.parse(log.time); const old map.get(uid); if (!old || timestamp old._ts) { map.set(uid, { ...log, _ts: timestamp }); } } const result [...map.values()].map(({ _ts, ...rest }) rest);第二種做法把 Date.parse 的調(diào)用次數(shù)減少到每個(gè)用戶至多兩次時(shí)間比較也變成純數(shù)字比較百萬(wàn)級(jí)數(shù)據(jù)實(shí)測(cè)大約 200~300ms 出結(jié)果。相比排序去重的 1 秒多又快了不少而且完整保留了原始對(duì)象只是中間多了一個(gè)臨時(shí)字段。5.3 結(jié)果和擴(kuò)展建議按這個(gè)方案跑下來(lái)100 萬(wàn)條日志去重后長(zhǎng)度大概在 30 萬(wàn)左右耗時(shí)穩(wěn)定在 300ms 以內(nèi)。如果數(shù)據(jù)量繼續(xù)漲到 500 萬(wàn)、1000 萬(wàn)我建議直接分片每 20 萬(wàn)條一批處理配合全局 Map避免單次內(nèi)存占用過(guò)高。再大一點(diǎn)可以把任務(wù)丟到 Web Worker 里跑瀏覽器主線程完全不卡。這個(gè)案例還說(shuō)明了一個(gè)道理去重的核心不一定是“快速去掉重復(fù)項(xiàng)”而是“在去重的同時(shí)拿到你真正需要的那條數(shù)據(jù)”。用 Map 可以邊去重邊保留最新的、最早的、或者聚合后的值比單純 Set 更靈活。6. 避坑指南與我的實(shí)操建議6.1 你以為去重很純粹NaN、-0、引用類型這些邊角料Set 對(duì) NaN 的處理比 indexOf 強(qiáng)。indexOf 內(nèi)部走的是嚴(yán)格相等NaN NaN 為 false所以用 indexOf 去重時(shí)多個(gè) NaN 不會(huì)被去掉。Set 內(nèi)部用的是 SameValueZero 算法NaN 算同一個(gè)值能正常去重。另外-0 和 0 在 Set 里也被認(rèn)為是同一個(gè)值不會(huì)產(chǎn)生兩個(gè)元素。對(duì)于引用類型Set 比較的是引用地址。如果兩個(gè)對(duì)象結(jié)構(gòu)完全一樣但屬于不同引用Set 不會(huì)去重。所以不要試圖用 Set 直接去重對(duì)象數(shù)組除非你明確知道對(duì)象都是同一個(gè)引用。還有一個(gè)容易忽略的用 JSON.stringify 配合 Set 做對(duì)象去重時(shí)如果對(duì)象里有函數(shù)、undefined、Symbol這些會(huì)被 JSON.stringify 忽略或轉(zhuǎn)成 null可能導(dǎo)致錯(cuò)誤去重。比如兩個(gè)對(duì)象一個(gè)多了 undefined 字段序列化后居然一樣。這個(gè)坑我踩過(guò)最后改成手動(dòng)拼接關(guān)鍵字段才解決。6.2 測(cè)試時(shí)最容易犯的錯(cuò)編譯器優(yōu)化、隨機(jī)數(shù)干擾做性能對(duì)比時(shí)很多人直接 console.time 包一下就下結(jié)論結(jié)果被誤導(dǎo)。第一必須保證各方法操作的是同一份數(shù)據(jù)源或等價(jià)數(shù)據(jù)不能一個(gè)方法改了原數(shù)組后面方法跟著受影響。第二如果方法內(nèi)部創(chuàng)建了新數(shù)組測(cè)試時(shí)要把新數(shù)組消費(fèi)掉否則引擎覺得結(jié)果沒被使用可能會(huì)做死代碼消除導(dǎo)致結(jié)果虛低。第三隨機(jī)數(shù)組每次內(nèi)容不同重復(fù)率不同會(huì)影響排序去重這類方案的耗時(shí)所以要固定數(shù)據(jù)源或多次取平均。我調(diào)試時(shí)的做法是先固定生成一份數(shù)組存在變量里每個(gè)方法傳入同一個(gè) arr方法內(nèi)部自己拷貝需要的部分保證互不干擾。運(yùn)行多次取中位數(shù)比單次結(jié)果更可信。另一個(gè)容易被忽略的是 JIT 編譯預(yù)熱。第一次調(diào)用某個(gè)函數(shù)時(shí)JS 引擎可能要優(yōu)化編譯所以測(cè)試時(shí)先跑一遍熱身再用第二遍的結(jié)果作為參考。如果只跑一遍可能會(huì)把預(yù)熱時(shí)間也算進(jìn)去得到不真實(shí)的數(shù)字。6.3 我用了這么久的一點(diǎn)心得文章寫到這里我把個(gè)人沉淀的幾個(gè)習(xí)慣分享出來(lái)。第一在大數(shù)據(jù)量場(chǎng)景里不要聰明過(guò)頭先無(wú)腦用 Set 把功能跑通再用性能分析工具看瓶頸。很多同事一上來(lái)就寫個(gè)看起來(lái)很高效的排序去重結(jié)果數(shù)據(jù)不是數(shù)值類型排序還得寫復(fù)雜比較器反而比 Set 更慢。第二去重需求往往伴隨著統(tǒng)計(jì)需求比如去重后還要計(jì)算每個(gè)分類的數(shù)量、保留最近一條記錄等這時(shí)候直接用 Map 而不是 Set省得后面再造一遍輪子。第三如果數(shù)據(jù)量已經(jīng)大到 Set 也撐不住除了分片還可以考慮在數(shù)據(jù)源頭做約束比如后端 SQL 里加 DISTINCT或者日志采集時(shí)先用更節(jié)省空間的概率結(jié)構(gòu)把明顯重復(fù)的丟掉。前端 JS 能做的優(yōu)化有上限不能把壓力全扛在瀏覽器里。我用分片處理后再配合 Web Worker 把任務(wù)丟到后臺(tái)線程跑頁(yè)面完全不會(huì)卡體驗(yàn)好了很多。最后分享一個(gè)小技巧當(dāng)數(shù)組是百萬(wàn)級(jí)且全是不重復(fù)的數(shù)字時(shí)可以把數(shù)字轉(zhuǎn)成 Uint32Array 之類的 TypedArray 來(lái)省內(nèi)存。但要注意TypedArray 在去重這件事上并不會(huì)比普通數(shù)組快很多它主要省內(nèi)存不是省時(shí)間。真正要省時(shí)間還是要回到哈希表加 O(n) 循環(huán)這條路。希望這份實(shí)測(cè)記錄能幫你少走點(diǎn)彎路。