引言
在 JavaScript 中，表面简单的语法背后常藏着隐式转换的陷阱。本文从一个常见面试题出发，分步剖析当对象作为属性键时发生的 ToPrimitive 与 ToPropertyKey 流程，解释为何不同引用会被字符串化为相同键并导致覆盖。随后给出安全替代方案（如 Map、Symbol 或显式唯一 ID）及工程实践建议，帮助在面试与实际开发中避免此类隐式错误。
在一次面试题中，我看到一段看似简单的代码，但它经常让许多开发者掉进理解偏差的陷阱。代码如下：
const a = {};
const b = { key: 'b' };
const c = { key: 'c' };
a[b] = 123;
a[c] = 456;
console.log(a[b]);
直觉可能认为输出是 123，但真实结果是 456。
属性键仅限字符串或 Symbol
在 JavaScript 中，普通对象的属性名只能是字符串或 Symbol。非字符串键会经过 ToPropertyKey（先 ToPrimitive，再转为字符串，Symbol 除外）转换后才成为属性名。于是不同的对象引用可能被隐式字符串化为相同键，导致覆盖或数据丢失。遇到需要以对象区分键的场景，应使用 Map 或为对象生成明确的唯一 ID，避免依赖隐式转换带来的隐患。
对象会如何被转换成字符串
当 JavaScript 将一个对象转换为字符串时，会先触发 ToPrimitive 操作，这通常会按照规范尝试调用对象的 valueOf 或 toString 方法（调用顺序与对象类型及实现有关）。大多数普通对象没有自定义的 valueOf 或 toString，因此会使用 Object.prototype.toString 的默认实现，返回 [object Object] 这样的通用描述。举例说明：
const b = { key: 'b' };
console.log(String(b)); // [object Object]
上述输出说明默认 toString 通常相同，导致不同对象（如 b 和 c）作为普通对象键时都会被转换为 "[object Object]"，从而发生覆盖。只有在对象实现自定义 toString（或在少数场景下通过 valueOf 返回原始值）时，转换结果才会不同。Symbol 是例外：Symbol 键不会被转为字符串，可避免键名冲突。理解这些转换有助于判断何时应显式字符串化或改用 Map/唯一 ID 等更安全的结构。
回到面试题
为了还原原始示例的执行过程，我们逐步分析代码的行为。先看赋值语句：
const a = {};
const b = { key: 'b' };
const c = { key: 'c' };
a[b] = 123; // 等价于 a[String(b)] = 123
a[c] = 456; // 等价于 a[String(c)] = 456
由于默认 String(b) 与 String(c) 都会得到 [object Object]，第二次赋值会覆盖第一次的值。最终 a 的内部结构等价于：
{ "[object Object]": 456 }
当执行 console.log(a[b]) 时，a[b] 会先把 b 转换为字符串 [object Object]，然后返回该键对应的值 456。这个示例揭示了一个容易被忽略的细节：在普通对象上使用非字符串键会触发隐式转换，而这种转换可能把多个不同引用映射到同一个字符串键，从而出现覆盖或数据丢失的问题。在面试场景中，能将这个现象与规范级别的 ToPropertyKey、ToPrimitive 以及默认方法链条联系起来进行解释，会比只给出结果更能体现对语言的深刻理解。
对象做键时用 Map 更安全
当设计需求需要以对象引用本身作为键来区分不同对象时，应该避免使用普通对象作为键值存储容器，改用 ES6 提供的 Map。Map 的键可以是任意类型，并且以引用相等性（reference equality）来区分对象键，不会对对象进行字符串化处理，示例如下：
const m = new Map();
m.set(b, 123);
m.set(c, 456);
console.log(m.get(b)); // 123
console.log(m.get(c)); // 456
Map 的实现使得 b 与 c 两个不同引用即使在默认 toString 下相同，也会作为两个不同的键被区分开来。除此之外，Map 提供了更直观的 API（set、get、has、delete）和内置的迭代支持，通常在需要以任意类型为键、并强调键的插入顺序或需要频繁增删键值对的场景下比普通对象更合适。工程实践中推荐在需要 “对象索引” 语义时优先考虑 Map，而不是依赖对象的隐式字符串化行为；另一个常用替代策略是为对象分配稳定的唯一标识（例如 UUID 或自增 ID），并将该标识作为字符串键存储在普通对象中，从而兼顾性能和可序列化性。
自定义 toString
确实可以通过覆盖对象的 toString 方法使其在字符串化时产生不同结果，从而在普通对象上模拟按对象 “区分键” 的行为。示例如下：
const a = {};
const b = { toString: () => 'b' };
const c = { toString: () => 'c' };
a[b] = 123;
a[c] = 456;
console.log(a[b]); // 123
尽管这个技巧在某些受控场景下有效，但并不推荐作为常规做法。原因包括：依赖隐式类型转换会降低代码可读性和可维护性，其他团队成员可能忽视对象被用作键时会依赖 toString 的实现；此外，这种方式在对象继承、序列化与调试过程中可能引发意外副作用，且与第三方库交互时可能不兼容。更稳健的做法是显式使用 Map、Symbol、或者为对象生成明确的唯一标识并使用该标识作为字符串键，以保证语义清晰、行为可预测并便于后续维护与测试。