前言

很多前端同学知道 Map但真正写业务时却很少用。说起来，

原因也很简单这方面。接口返回的数据通常是数组，表单提交的数据通常是对象或数组，最终给后端的也是 JSON。大多数时候，数组和普通对象已经够用了。

但有一类问题，只要出现。Map 就会非常顺手：

• 根据一个唯一 key，快速找到对应的数据。怎么说呢，

换个角度Map 的主要价值不是“存数据”。而是把一组数据整理成一张索引表。

这篇文章用三个场景说明：

• 什么时候数组更合适。
• 什么时候可以用 Map 管理选中项。
• 接口刷新后如何用 Map 保留使用者编辑。

先看一个判断标准

当你写出这种代码时就可以想一下是不是该用 Map

listA.map(itemA => {
const itemB = listB.find
})

This code itself is fine.

The underlying signal is that you are searching by id. If this search happens only once or twice。find's clarity wins. But if it appears inside a loop over a large array,it turns into repeated scans:

// worst case
listA.forEach(a => {
listB.find
})

This can lead to O time complexity.

A 娱乐ter pattern is to build an index first:

const listBMap = new Map(
listB.map
);listA.forEach(itemA => {
const itemB = listBMap.get;
})，

The two-step process:

1. Create a map from second array.
2. Dive into it directly by key.

场景一这方面。简单 checkbox，用数组就够了

This is most common scenario – multi-select products.

const goods =;

Vue 示例

为什么不需要 Map？

• A simple array of ids matches form semantics and API payloads perfectly.
• No need for complex lookups – you just send ids back to server.
• If your UI logic never needs to access full product object based on selection state。you’re already done.

---

说到痛点，当你需要更多信息时…

• If you later realize you need product names or prices for calculation or display within same component,using an array of ids forces you to re‑search each time with #find。which becomes painful when lists grow large.
• You might end up writing duplicate “lookup” code scattered across components – a maintenance headache that could be avoided by storing a mapping once upfront.

---

使用 Map 的好处

• A single lookup per selection change keeps logic tidy and scales linearly regardless of list size.

说到场景二，选中项需要完整对象，可以考虑 Map

从思路来看，商品 id → 商品对象

{
//…}

⚠️ 错误示例 不要把整行订单存进 Map 因为刷新后会被覆盖。老实说，

主要代码