Map 与普通对象是本质不同的数据结构：键支持任意类型、无原型链、有确定插入顺序、提供 size/clear/has 等原生方法；而普通对象键仅限字符串/Symbol、存在类型强制转换、遍历顺序不完全可靠、操作更繁琐。
Map 对象不是“带下划线的普通对象”，它和 {} 是完全不同的数据结构，不能用点号访问、没有原型链继承、键可以是任意类型——这些差异直接影响你能不能正确存取数据。
Map 的键可以是任意值，而普通对象只能是字符串或 Symbol
普通对象的键会被强制转为字符串（比如 {[1,2]: 'a'} 实际上是 {'1,2': 'a'}），Map 则保留原始类型：
-
new Map().set({}, 'value')—— 用空对象作键，合法且可查 -
new Map().set(NaN, 'nan')——NaN作为键能被正确识别（普通对象里obj[NaN] = 'x'等价于obj['NaN'] = 'x'） -
obj[123]和obj['123']指向同一个属性；map.get(123)和map.get('123')是两个独立键
Map 有确定的插入顺序，普通对象在 ES2015 后才部分保证
遍历 Map 时，keys()、values()、entries() 都严格按插入顺序返回；普通对象的属性顺序虽然现在大多遵循插入顺序，但仍有例外：
- 数字键（如
'1'、'10'）会被提前排序，{'10':1,'1':2}遍历时先输出'1'再'10' - Symbol 键总在最后，字符串键在前，但具体行为依赖引擎实现
-
Map不受这些干扰，map.set('a',1).set(2,3).set(Symbol(),4)就按这个顺序迭代
Map 的 size、遍历、清空操作更直接，普通对象要手动处理
普通对象没有原生 size 属性，也不能直接 clear()，常用写法容易出错：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
const obj = { a: 1, b: 2 };
console.log(Object.keys(obj).length); // ✅ 得到 2，但要遍历一次
obj = {}; // ❌ 重赋值不改变原引用，其他地方仍持有旧对象
Object.keys(obj).forEach(k => delete obj[k]); // ✅ 但性能差、不可靠（可能跳过不可枚举属性）
const map = new Map();
map.set('a', 1).set('b', 2);
console.log(map.size); // ✅ 直接读取，O(1)
map.clear(); // ✅ 原地清空，无引用残留
-
map.has(key)比key in obj或obj.hasOwnProperty(key)更准确（不涉及原型链） -
for (const [k, v] of map)可直接解构，for...in遍历对象会包含继承属性 - 没有
map.toJSON()，要转 JSON 得手动Array.from(map)或[...map]
Map 不是语法糖，不能替代对象做配置或 DOM 属性映射
如果你只是存字符串键、不需要弱引用、也不关心键类型，用 {} 更轻量、可读性更好。Map 的开销明显更高：
- 每个
Map实例都带额外内存结构，初始化比空对象慢约 3–5 倍 - V8 中
Map查找复杂度平均 O(1)，但常数项比对象高；小数据量（ - 不能用点号或方括号语法直接访问：
map.key或map['key']总是undefined，必须用map.get(key) - JSON 序列化不支持 Map，
JSON.stringify(new Map([['a',1]]))得到'{}'
真正该用 Map 的场景很明确：需要非字符串键、依赖插入顺序、频繁增删且关注性能一致性。其余时候，别为了“新”而换——尤其当团队成员还在用 for...in 遍历对象时，Map 的 for...of 会悄悄漏掉逻辑。
