map 仅应承担键值高效查找职责，直接挂载属性（如map.customflag）会污染语义、导致序列化丢失与维护混乱；应改用weakmap或封装类管理元数据。
Map 是个好工具，但不是万能容器。它该管的只有一件事：用键高效查值。一旦越界承担额外职责，问题就悄悄来了。
别往 Map 上加属性（.prop）
给 Map 实例直接挂属性，比如 map.customFlag = true 或 map.meta = {...}，表面省事，实则污染它的语义边界。Map 不是普通对象，它的设计契约里没有“自定义字段”这一项。这种写法会带来两个隐患：
- 代码可读性下降——别人看到 map.customFlag，无法判断这是业务逻辑的一部分，还是误操作残留
- 序列化或调试时容易遗漏——JSON.stringify(map) 完全忽略这些附加属性，导致状态不一致
- 后续维护易混淆——当多个模块都往同一个 Map 上塞不同字段，谁负责清理？谁保证命名不冲突？
真正需要关联元数据时，用 WeakMap 建立私有映射，或把 Map 封装进类，把附加状态作为类字段管理，更清晰可控。
别用大对象当 key
拿一个带 10 个字段的用户实例、一个嵌套配置对象，甚至整个 Vue 组件实例作 Map 的 key，短期可能跑得通，长期必出问题：
- 内存泄漏风险高——Map 对 key 是强引用，只要这个对象没被外部释放，整条键值对就卡在内存里出不去
- 哈希计算开销大——每次 get/has/remove 都要调用 hashCode（或 JS 中的 Object.prototype.toString 衍生逻辑），若内部含深遍历或未缓存计算，单次耗时可能达毫秒级
- 查找不稳定——临时 new 出结构相同但引用不同的对象去查，结果永远是 undefined，因为默认比较的是引用而非内容
推荐做法：提取稳定标识字段（如 id、code、timestamp）拼成字符串，或封装轻量不可变 Key 类；必须用对象时，确保已正确重写 hashCode 和 equals（JS 中对应 Symbol.hasInstance 或自定义比对逻辑），并缓存哈希值。
别用 Map 传查询参数（尤其超两个）
在接口层、服务调用或跨模块通信中，把一堆查询条件塞进 Map
- 语义模糊——map.get("status") 是订单状态？审核状态？还是支付状态？没人知道
- 类型失控——value 可能是 String、Integer、LocalDateTime，取值时容易漏判类型，引发 ClassCastException 或空指针
- 校验困难——没法用注解（如 @NotNull、@Min）做统一参数校验，只能靠手动 if 判断
- 扩展脆弱——加个新参数要改所有调用方，还容易键名拼错（"user_id" vs "userId"）
超过两个参数的查询场景，应定义明确的 DTO 类，让字段名、类型、约束一目了然。
别用 Map 替代专用数据结构
Map 的核心优势是“任意类型键 + O(1) 查找”，但它不擅长其他事：
- 不需要排序？别用 Map 存有序列表——数组或 Set 更轻量
- 只是去重？用 Set 更语义准确，也避免 value 占位符（如 new Map().set(item, true)）的冗余
- 要频繁遍历全部值且不关心键？普通数组通常更快，V8 对数组遍历做了大量优化
- 需要响应式更新（如 Vue/React 状态）？Map 本身不触发响应，得靠包装或转成 reactive 对象，徒增复杂度
选数据结构，先问一句：我真正要解决的问题，是不是“根据某个标识快速拿到对应值”？如果不是，Map 很可能不是最优解。
