map 的 size 属性是 o(1) 时间复杂度的直接读取，而 object.keys(obj).length 是 o(n) 的遍历操作；size 是 map 内置实时更新的计数器，不触发迭代、不创建数组、无内存开销，且支持任意键类型；object.keys().length 则需枚举、拷贝、取长，受属性数量、原型污染和不可枚举键影响，高频场景下易成性能瓶颈。
Map 的 size 属性是 O(1) 时间复杂度的直接读取，而 Object.keys(obj).length 每次调用都需遍历所有可枚举属性、生成新数组，本质是 O(n) 操作——两者不是同一层级的机制，不能简单等价替换。
size 是内置计数器，不是“计算出来的”
Map 内部维护一个实时更新的整数字段，每次 set()、delete() 或 clear() 都自动增减。读取 map.size 就像读一个变量，不触发任何迭代、不创建中间结构，无论 Map 里有 1 个还是 50 万个键值对，耗时几乎不变。
- 不依赖键的类型（对象、函数、Symbol 都算一个）
- 不涉及原型链，只统计自身键值对
- 无内存分配开销
Object.keys(obj).length 是一次完整遍历
这个表达式实际执行三步：枚举所有自有可枚举字符串键 → 拷贝进新数组 → 取数组 length。哪怕你只想要个数字，也必须走完全部流程。
- 数据量越大，时间与内存开销越明显
- 若对象有大量属性或被污染（如往 Object.prototype 加了可枚举属性），结果可能意外偏大
- 无法反映 Symbol 键，也不包含不可枚举属性
高频读写场景下差距会被放大
在缓存淘汰、事件监听器计数、路由注册监控等需要「频繁增删 + 实时查数量」的逻辑中，反复调用 Object.keys().length 很容易成为性能瓶颈；而 map.size 始终轻量稳定。
- LRU 缓存中判断是否超限：
if (cache.size > MAX)比if (Object.keys(cache).length > MAX)更安全高效 - 服务端监控已注册路由数，用
router.size可避免每次请求都触发数组构建 - 循环中多次统计？缓存
Object.keys(obj).length结果不如直接换用 Map
别拿不公平的测试对比下结论
常见错误是这样测性能：
- Map 测
map.size（单次属性访问） - Object 却测
Object.keys(obj).length（完整遍历+建数组）
这种对比忽略了操作语义差异。真正公平的前提是：只比「纯计数」，且数据量足够（建议 ≥10k 条目），否则 V8 的优化可能掩盖真实差距。
