在 JavaScript 中，對(duì)象是很方便的。它們?cè)试S我們輕松地將多個(gè)數(shù)據(jù)塊組合在一起。在ES6之后，又出了一個(gè)新的語(yǔ)言補(bǔ)充-- Map。在很多方面，它看起來(lái)像是一個(gè)功能更強(qiáng)的對(duì)象，但接口卻有些笨拙。

然而，大多數(shù)開(kāi)發(fā)者在需要 hash map 的時(shí)候還是會(huì)使用對(duì)象，只有當(dāng)他們意識(shí)到鍵值不能只是字符串的時(shí)候才會(huì)轉(zhuǎn)而使用 Map。因此，Map 在當(dāng)今的 JavaScript 社區(qū)中仍然沒(méi)有得到充分的使用。

在本文本中，我會(huì)列舉一些應(yīng)該更多考慮使用 Map 的一些原因。

為什么對(duì)象不符合 Hash Map 的使用情況

在 Hash Map 中使用對(duì)象最明顯的缺點(diǎn)是，對(duì)象只允許鍵是字符串和 symbol。任何其他類(lèi)型的鍵都會(huì)通過(guò) ??toString?? 方法被隱含地轉(zhuǎn)換為字符串。

const foo = []
const bar = {}
const obj = {[foo]: 'foo', [bar]: 'bar'}
console.log(obj) // {"": 'foo', [object Object]: 'bar'}

更重要的是，使用對(duì)象做 Hash Map 會(huì)造成混亂和安全隱患。

不必要的繼承

在ES6之前，獲得 hash map 的唯一方法是創(chuàng)建一個(gè)空對(duì)象：

const hashMap = {}

然而，在創(chuàng)建時(shí)，這個(gè)對(duì)象不再是空的。盡管 hashMap 是用一個(gè)空的對(duì)象字面量創(chuàng)建的，但它自動(dòng)繼承了 Object.prototype。這就是為什么我們可以在 hashMap 上調(diào)用hasOwnProperty、toString、constructor 等方法，盡管我們從未在該對(duì)象上明確定義這些方法。

由于原型繼承，我們現(xiàn)在有兩種類(lèi)型的屬性被混淆了：存在于對(duì)象本身的屬性，即它自己的屬性，以及存在于原型鏈的屬性，即繼承的屬性。

因此，我們需要一個(gè)額外的檢查（例如hasOwnProperty）來(lái)確保一個(gè)給定的屬性確實(shí)是用戶(hù)提供的，而不是從原型繼承的。

除此之外，由于屬性解析機(jī)制在 JavaScrip t中的工作方式，在運(yùn)行時(shí)對(duì) Object.prototype 的任何改變都會(huì)在所有對(duì)象中引起連鎖反應(yīng)。這就為原型污染攻擊打開(kāi)了大門(mén)，這對(duì)大型的JavaScript 應(yīng)用程序來(lái)說(shuō)是一個(gè)嚴(yán)重的安全問(wèn)題。

不過(guò)，我們可以通過(guò)使用 Object.create(null) 來(lái)解決這個(gè)問(wèn)題，它可以生成一個(gè)不繼承Object.prototype的對(duì)象。

名稱(chēng)沖突

當(dāng)一個(gè)對(duì)象自己的屬性與它的原型上的屬性有名稱(chēng)沖突時(shí)，它就會(huì)打破預(yù)期，從而使程序崩潰。

例如，我們有一個(gè)函數(shù) foo，它接受一個(gè)對(duì)象。

function foo(obj) {
 //...
 for (const key in obj) {
  if (obj.hasOwnProperty(key)) {
   
  }
 }
}

obj.hasOwnProperty(key)有一個(gè)可靠性風(fēng)險(xiǎn)：考慮到屬性解析機(jī)制在JavaScript中的工作方式，如果 obj 包含一個(gè)開(kāi)發(fā)者提供的具有相同名稱(chēng)的 hasOwnProperty 屬性，那就會(huì)對(duì)Object.prototype.hasOwnProperty產(chǎn)生影響。因此，我們不知道哪個(gè)方法會(huì)在運(yùn)行時(shí)被準(zhǔn)確調(diào)用。

可以做一些防御性編程來(lái)防止這種情況。例如，我們可以從 Object.prototype 中 "借用""真正的 hasOwnProperty 來(lái)代替：

function foo(obj) {
 //...
 for (const key in obj) {
  if (Object.prototype.hasOwnProperty.call(obj, key)) {
   // ...
  }
 }
}

還有一個(gè)更簡(jiǎn)短的方法就是在一個(gè)對(duì)象的字面量上調(diào)用該方法，如{}.hasOwnProperty.call(key)，不過(guò)這也挺麻煩的。這就是為什么還會(huì)新出一個(gè)靜態(tài)方法Object.hasOwn 的原因了。

次優(yōu)的人機(jī)工程學(xué)

Object 沒(méi)有提供足夠的人機(jī)工程學(xué)，不能作為 hash map 使用，許多常見(jiàn)的任務(wù)不能直觀地執(zhí)行。

size

Object 并沒(méi)有提供方便的API來(lái)獲取 size，即屬性的數(shù)量。而且，對(duì)于什么是一個(gè)對(duì)象的 size ，還有一些細(xì)微的差別:

• 如果只關(guān)心字符串、可枚舉的鍵，那么可以用Object.keys() 將鍵轉(zhuǎn)換為數(shù)組，并獲得其length。
• 如果k只想要不可枚舉的字符串鍵，那么必須得使用Object.getOwnPropertyNames 來(lái)獲得一個(gè)鍵的列表并獲得其 length。
• 如果只對(duì) symbol  鍵感興趣，可以使用getOwnPropertySymbols? 來(lái)顯示 symbol  鍵。或者可以使用Reflect.ownKeys 來(lái)一次獲得字符串鍵和 symbol  鍵，不管它是否是可枚舉的。

上述所有選項(xiàng)的運(yùn)行時(shí)復(fù)雜度為**O(n)**，因?yàn)槲覀儽仨毾葮?gòu)造一個(gè)鍵的數(shù)組，然后才能得到其長(zhǎng)度。

iterate

循環(huán)遍歷對(duì)象也有類(lèi)似的復(fù)雜性。

我們可以使用 for...in循環(huán)。但它會(huì)讀取到繼承的可枚舉屬性。

Object.prototype.foo = 'bar'
const obj = {id: 1} 
for (const key in obj) {
 console.log(key) // 'id', 'foo'
}

我們不能對(duì)一個(gè)對(duì)象使用 for ... of，因?yàn)槟J(rèn)情況下它不是一個(gè)可迭代的對(duì)象，除非我們明確定義 Symbol.iterator 方法在它上面。

我們可以使用 Object.keys、Object.values 和 Object.entry 來(lái)獲得一個(gè)可枚舉的字符串鍵（或/和值）的列表，并通過(guò)該列表進(jìn)行迭代，這引入了一個(gè)額外的開(kāi)銷(xiāo)步驟。

還有一個(gè)是 插入對(duì)象的鍵的順序并不是按我們的順序來(lái)的，這是一個(gè)很蛋疼的地方。在大多數(shù)瀏覽器中，整數(shù)鍵是按升序排序的，并優(yōu)先于字符串鍵，即使字符串鍵是在整數(shù)鍵之前插入的：

const obj = {}
obj.foo = 'first'
obj[2] = 'second'
obj[1] = 'last'
console.log(obj) // {1: 'last', 2: 'second', foo: 'first'}

clear

沒(méi)有簡(jiǎn)單的方法來(lái)刪除一個(gè)對(duì)象的所有屬性，我們必須用 delete 操作符一個(gè)一個(gè)地刪除每個(gè)屬性，這在歷史上是眾所周知的慢。

檢查屬性是否存在

最后，我們不能依靠點(diǎn)/括號(hào)符號(hào)來(lái)檢查一個(gè)屬性的存在，因?yàn)橹当旧砜赡鼙辉O(shè)置為 undefined。相反，得使用 Object.prototype.hasOwnProperty 或 Object.hasOwn。

const obj = {a: undefined}
Object.hasOwn(obj, 'a') // true

Map

ES6 為我們帶來(lái)了 Map，首先，與只允許鍵值為字符串和 symbols 的 Object 不同，Map 支持任何數(shù)據(jù)類(lèi)型的鍵。

但更重要的是，Map 在用戶(hù)定義的和內(nèi)置的程序數(shù)據(jù)之間提供了一個(gè)干凈的分離，代價(jià)是需要一個(gè)額外的 Map.prototype.get 來(lái)獲取對(duì)應(yīng)的項(xiàng)。

Map 也提供了更好的人機(jī)工程學(xué)。Map 默認(rèn)是一個(gè)可迭代的對(duì)象。這說(shuō)明可以用 for ... of 輕松地迭代一個(gè) Map，并做一些事情，比如使用嵌套的解構(gòu)來(lái)從 Map 中取出第一個(gè)項(xiàng)。

const [[firstKey, firstValue]] = map

與 Object 相比，Map 為各種常見(jiàn)任務(wù)提供了專(zhuān)門(mén)的API:

• Map.prototype.has? 檢查一個(gè)給定的項(xiàng)是否存在，與必須在對(duì)象上使用Object.prototype.hasOwnProperty/Object.hasOwn 相比，不那么尷尬了。
• Map.prototype.get 返回與提供的鍵相關(guān)的值。有的可能會(huì)覺(jué)得這比對(duì)象上的點(diǎn)符號(hào)或括號(hào)符號(hào)更笨重。不過(guò)，它提供了一個(gè)干凈的用戶(hù)數(shù)據(jù)和內(nèi)置方法之間的分離。
• Map.prototype.size 返回 Map 中的項(xiàng)的個(gè)數(shù)，與獲取對(duì)象大小的操作相比，這明顯好太多了。此外，它的速度也更快。
• Map.prototype.clear 可以刪除 Map 中的所有項(xiàng)，它比 delete 操作符快得多。

性能差異

在 JavaScript 社區(qū)中，似乎有一個(gè)共同的信念，即在大多數(shù)情況下，Map 要比 Object 快。有些人聲稱(chēng)通過(guò)從 Object 切換到 Map 可以看到明顯的性能提升。

我在 LeetCode 上也證實(shí)了這種想法，對(duì)于數(shù)據(jù)量大的 Object 會(huì)超時(shí)，但 Map 上則不會(huì)。

然而，說(shuō) "Map 比 Object 快" 可能是算一種歸納性的，這兩者一定有一些細(xì)微的差別，我們可以通過(guò)一些例子，把它找出來(lái)。

測(cè)試

測(cè)試用例有一個(gè)表格，主要測(cè)試 Object 和 Map 在插入、迭代和刪除數(shù)據(jù)的速度。

插入和迭代的性能是以每秒的操作來(lái)衡量的。這里使用了一個(gè)實(shí)用函數(shù) measureFor，它重復(fù)運(yùn)行目標(biāo)函數(shù)，直到達(dá)到指定的最小時(shí)間閾值（即用戶(hù)界面上的 duration 輸入字段）。它返回這樣一個(gè)函數(shù)每秒鐘被執(zhí)行的平均次數(shù)。

function measureFor(f, duration) {
  let iterations = 0;
  const now = performance.now();
  let elapsed = 0;
  while (elapsed < duration) {
    f();
    elapsed = performance.now() - now;
    iterations++;
  }
  return ((iterations / elapsed) * 1000).toFixed(4);
}

至于刪除，只是要測(cè)量使用 delete  操作符從一個(gè)對(duì)象中刪除所有屬性所需的時(shí)間，并與相同大小的 Map 使用 Map.prototype.delete 的時(shí)間進(jìn)行比較。也可以使用Map.prototype.clear，但這有悖于基準(zhǔn)測(cè)試的目的，因?yàn)槲抑浪隙〞?huì)快得多。

在這三種操作中，我更關(guān)注插入操作，因?yàn)樗俏以谌粘９ぷ髦凶畛?zhí)行的操作。對(duì)于迭代性能，很難有一個(gè)全面的基準(zhǔn)，因?yàn)槲覀兛梢詫?duì)一個(gè)給定的對(duì)象執(zhí)行許多不同的迭代變體。這里我只測(cè)量 for ... in 循環(huán)。

在這里使用了三種類(lèi)型的 key。

• 字符串，例如：Yekwl7caqejth7aawelo4。
• 整數(shù)字符串，例如：123。
• 由Math.random().toString() 生成的數(shù)字字符串，例如：0.4024025689756525。

所有的鍵都是隨機(jī)生成的，所以我們不會(huì)碰到V8實(shí)現(xiàn)的內(nèi)聯(lián)緩存。我還在將整數(shù)和數(shù)字鍵添加到對(duì)象之前，使用 toString 明確地將其轉(zhuǎn)換為字符串，以避免隱式轉(zhuǎn)換的開(kāi)銷(xiāo)。

最后，在基準(zhǔn)測(cè)試開(kāi)始之前，還有一個(gè)至少100ms的熱身階段，在這個(gè)階段，我們反復(fù)創(chuàng)建新的對(duì)象和 Map，并立即丟棄。

如果你也想玩，代碼已經(jīng)放在 CodeSandbox 上。

我從大小為 100 個(gè)屬性/項(xiàng)的 Object 和 Map 開(kāi)始，一直到 5000000，并讓每種類(lèi)型的操作持續(xù)運(yùn)行 10000ms，看看它們之間的表現(xiàn)如何。下面是測(cè)試結(jié)果：

string keys

一般來(lái)說(shuō)，當(dāng)鍵為（非數(shù)字）字符串時(shí)，Map 在所有操作上都優(yōu)于 Object。

但細(xì)微之處在于，當(dāng)數(shù)量并不真正多時(shí)（低于100000），Map 在插入速度上 是Object 的兩倍，但當(dāng)規(guī)模超過(guò) 100000 時(shí)，性能差距開(kāi)始縮小。

上圖顯示了隨著條目數(shù)的增加（x軸），插入率如何下降（y軸）。然而，由于X軸擴(kuò)展得太寬（從100 到 1000000），很難分辨這兩條線之間的差距。

然后用對(duì)數(shù)比例來(lái)處理數(shù)據(jù)，做出了下面的圖表。

可以清楚地看出這兩條線正在重合。

這里又做了一張圖，畫(huà)出了在插入速度上 Map 比 Object 快多少。你可以看到 Map 開(kāi)始時(shí)比 Object 快 2 倍左右。然后隨著時(shí)間的推移，性能差距開(kāi)始縮小。最終，當(dāng)大小增長(zhǎng)到 5000000時(shí)，Map 只快了 30%。

雖然我們中的大多數(shù)人永遠(yuǎn)不會(huì)在一個(gè) Object 或 Map 中擁有超過(guò)1 00 萬(wàn)的條數(shù)據(jù)。對(duì)于幾百或幾千個(gè)數(shù)據(jù)的規(guī)模，Map 的性能至少是 Object 的兩倍。因此，我們是否應(yīng)該就此打住，并開(kāi)始重構(gòu)我們的代碼庫(kù)，全部采用 Map？

這不太靠譜......或者至少不能期望我們的應(yīng)用程序變得快 2 倍。記住我們還沒(méi)有探索其他類(lèi)型的鍵。下面我們看一下整數(shù)鍵。

integer keys

我之所以特別想在有整數(shù)鍵的對(duì)象上運(yùn)行基準(zhǔn)，是因?yàn)閂8在內(nèi)部?jī)?yōu)化了整數(shù)索引的屬性，并將它們存儲(chǔ)在一個(gè)單獨(dú)的數(shù)組中，可以線性和連續(xù)地訪問(wèn)。但我找不到任何資源來(lái)證實(shí)它對(duì) Map 也采用了同樣的優(yōu)化方式。

我們首先嘗試在 [0, 1000] 范圍內(nèi)的整數(shù)鍵。

如我所料，Object 這次的表現(xiàn)超過(guò)了 Map。它們的插入速度比 Map 快65%，迭代速度快16%。

接著， 擴(kuò)大范圍，使鍵中的最大整數(shù)為 1200。

似乎現(xiàn)在 Map 的插入速度開(kāi)始比 Object 快一點(diǎn)，迭代速度快 5 倍。

現(xiàn)在，我們只增加了整數(shù)鍵的范圍，而不是 Object 和 Map 的實(shí)際大小。讓我們加大 size，看看這對(duì)性能有什么影響。

當(dāng)屬性 size 為 1000 時(shí)，Object 最終比 Map 的插入速度快 70%，迭代速度慢2倍。

我玩了一堆 Object/Map size 和整數(shù)鍵范圍的不同組合，但沒(méi)有想出一個(gè)明確的模式。但我看到的總體趨勢(shì)是，隨著 size 的增長(zhǎng)，以一些相對(duì)較小的整數(shù)作為鍵值，Object 在插入方面比Map 更有性能，在刪除方面總是大致相同，迭代速度慢4或5倍。

Object 在插入時(shí)開(kāi)始變慢的最大整數(shù)鍵的閾值會(huì)隨著 Object 的大小而增長(zhǎng)。例如，當(dāng)對(duì)象只有100個(gè)條數(shù)據(jù)，閾值是1200；當(dāng)它有 10000 個(gè)條目時(shí)，閾值似乎是 24000 左右。

numeric keys

最后，讓我們來(lái)看看最后一種類(lèi)型的按鍵--數(shù)字鍵。

從技術(shù)上講，之前的整數(shù)鍵也是數(shù)字鍵。這里的數(shù)字鍵特指由 Math.random().toString() 生成的數(shù)字字符串。

結(jié)果與那些字符串鍵的情況類(lèi)似。Map 開(kāi)始時(shí)比 Object 快得多（插入和刪除快2倍，迭代快4-5倍），但隨著我們規(guī)模的增加，差距也越來(lái)越小。

內(nèi)存使用情況

基準(zhǔn)測(cè)試的另一個(gè)重要方面是內(nèi)存利用率。

由于我無(wú)法控制瀏覽器環(huán)境中的垃圾收集器，這里決定在 Node 中運(yùn)行基準(zhǔn)測(cè)試。

這里創(chuàng)建了一個(gè)小腳本來(lái)測(cè)量它們各自的內(nèi)存使用情況，并在每次測(cè)量中手動(dòng)觸發(fā)了完全的垃圾收集。用 node --expose-gc 運(yùn)行它，就得到了以下結(jié)果。

{
  object: {
    'string-key': {
      '10000': 3.390625,
      '50000': 19.765625,
      '100000': 16.265625,
      '500000': 71.265625,
      '1000000': 142.015625
    },
    'numeric-key': {
      '10000': 1.65625,
      '50000': 8.265625,
      '100000': 16.765625,
      '500000': 72.265625,
      '1000000': 143.515625
    },
    'integer-key': {
      '10000': 0.25,
      '50000': 2.828125,
      '100000': 4.90625,
      '500000': 25.734375,
      '1000000': 59.203125
    }
  },
  map: {
    'string-key': {
      '10000': 1.703125,
      '50000': 6.765625,
      '100000': 14.015625,
      '500000': 61.765625,
      '1000000': 122.015625
    },
    'numeric-key': {
      '10000': 0.703125,
      '50000': 3.765625,
      '100000': 7.265625,
      '500000': 33.265625,
      '1000000': 67.015625
    },
    'integer-key': {
      '10000': 0.484375,
      '50000': 1.890625,
      '100000': 3.765625,
      '500000': 22.515625,
      '1000000': 43.515625
    }
  }
}

很明顯，Map 比 Object 消耗的內(nèi)存少20%到50%，這并不奇怪，因?yàn)?Map 不像 Object 那樣存儲(chǔ)屬性描述符，比如 writable/enumerable/configurable 。

總結(jié)

那么，我們能從這一切中得到什么呢？

• Map 比 Object 快，除非有小的整數(shù)、數(shù)組索引的鍵，而且它更節(jié)省內(nèi)存。
• 如果你需要一個(gè)頻繁更新的 hash map，請(qǐng)使用 Map；如果你想一個(gè)固定的鍵值集合（即記錄），請(qǐng)使用Object，并注意原型繼承帶來(lái)的陷阱。