JS中用filter+includes求交集，为何对对象数组失效？

Question

在 JavaScript 中，用 `arr1.filter(item => arr2.includes(item))` 求两个数组交集，对基本类型（如数字、字符串）有效，但对对象数组**必然失效**。根本原因在于：`includes()` 内部使用 **SameValueZero 算法**（类似 `===`），而对象比较的是**引用地址**，而非结构或内容。即使两个对象字面量完全相同（如 `{id: 1}` 和 `{id: 1}`），它们在内存中是不同实例，引用不等，`includes()` 永远返回 `false`。例如： ```js const a = [{id: 1}]; const b = [{id: 1}]; a.filter(x => b.includes(x)); // → []（空数组） ``` 这不是 `filter` 或 `includes` 的 bug，而是 JS 对象语义的固有特性。解决需改用深比较（如 `JSON.stringify` 粗略方案）、`some()` + 自定义相等逻辑（推荐），或借助 `Map/Set` 预处理键值。理解“引用比较”与“值比较”的差异，是避免此类陷阱的关键。

Answer 1

```html

一、现象层：交集操作在对象数组中“静默失败”

开发者常误以为 arr1.filter(item => arr2.includes(item)) 是通用交集方案。对基本类型（['a','b'] 与 ['b','c']）返回 ['b']，一切正常；但对对象数组：
const a = [{id: 1, name: 'Alice'}]; const b = [{id: 1, name: 'Alice'}];
执行后始终返回空数组 [] —— 无报错、无警告，仅逻辑失效。

二、机制层：SameValueZero 与引用语义的底层碰撞

• Array.prototype.includes() 采用 SameValueZero 算法（ES2015+），等价于 Object.is(a, b) 的宽松版（允许 +0 === -0，NaN === NaN）
• 该算法对对象一律执行 严格引用比较：仅当两个变量指向内存中同一地址时才返回 true
• 字面量对象 {id: 1} 每次声明都创建新堆内存实例，地址唯一 → 即使结构/值完全一致，includes() 也必判为 false

三、验证层：用代码实证引用差异

const obj1 = { id: 1 };
const obj2 = { id: 1 };
console.log(obj1 === obj2);        // false（引用不同）
console.log(JSON.stringify(obj1) === JSON.stringify(obj2)); // true（序列化后值相同）
console.log(Object.is(obj1, obj2)); // false

四、解决方案全景图

方案	适用场景	时间复杂度	局限性
filter + some + deepEqual	任意嵌套结构，需精确语义	O(m×n)	需引入 Lodash 或手写深比较，性能敏感场景慎用
JSON.stringify 键映射	扁平对象、无函数/undefined/Symbol/循环引用	O(m+n)	键序敏感（{a:1,b:2} ≠ {b:2,a:1}）、丢失类型信息
Map 预建索引（按唯一键）	对象含稳定业务主键（如 id）	O(m+n)	依赖预定义键名，无法处理复合条件或动态 schema

五、工程实践推荐：基于主键的 Map 加速方案

这是兼顾性能、可读性与健壮性的首选模式：

function intersectBy(arr1: T[], arr2: T[], keyFn: (item: T) => string | number): T[] {
  const keySet = new Set(arr2.map(keyFn));
  return arr1.filter(item => keySet.has(keyFn(item)));
}

// 使用示例：
const usersA = [{id: 1, name: 'Alice'}, {id: 2, name: 'Bob'}];
const usersB = [{id: 1, name: 'ALICE'}, {id: 3, name: 'Charlie'}];
const intersection = intersectBy(usersA, usersB, u => u.id); // [{id: 1, name: 'Alice'}]

六、进阶陷阱：JSON.stringify 的隐式雷区

• ❌ undefined、function、Symbol 字段被静默丢弃
• ❌ Date 对象转为字符串（"2023-01-01T00:00:00.000Z"），精度丢失风险
• ❌ 键顺序不保证（V8 引擎下数字键优先，但规范未强制），导致 {a:1, b:2} 与 {b:2, a:1} 序列化结果不同
• ✅ 仅适用于 DTO 类扁平数据，且团队已约定字段规范与序列化契约

七、原理升华：JavaScript 的“值 vs 引用”双轨模型

JavaScript 数据比较语义分层图

┌───────────────────────┐
│     基本类型（值类型）      │ ← SameValueZero 直接比内容（7 种 primitive）
├───────────────────────┤
│   对象/数组/函数（引用类型）  │ ← SameValueZero 只比内存地址（pointer equality）
├───────────────────────┤
│       深比较（应用层）       │ ← 开发者自行定义“相等”：结构、键值、业务规则
└───────────────────────┘

八、架构启示：何时该放弃数组交集思维？

当对象交集成为高频操作时，应反思数据建模合理性：

• ✅ 将核心实体抽象为 class Entity { get id() { return this._id; } }，统一提供 .equals(other) 方法
• ✅ 在状态管理（如 Redux Toolkit）中，用 createEntityAdapter 内置的 selectIds + getSelectors 实现 O(1) 关联查询
• ✅ 后端 API 设计阶段即约定 id 作为幂等标识，前端避免用全量对象做集合运算

九、TypeScript 强化：编译期预防误用

// 定义泛型约束，强制要求传入 key 提取器
declare function safeIntersect<T, K extends keyof T>(
  a: T[], 
  b: T[], 
  key: K
): T[];

// 调用时若未提供 key，TS 报错：Expected 3 arguments, but got 2.
safeIntersect(usersA, usersB); // ❌ 编译失败
safeIntersect(usersA, usersB, 'id'); // ✅ 类型安全

十、终极心智模型：交集不是语法糖，而是领域契约

所谓“两个对象是否相同”，从来不由 JavaScript 决定，而由你的业务语义定义：

• 用户维度：可能以 email 为唯一标识
• 订单维度：可能需同时匹配 orderId + userId 复合键
• 配置项维度：可能要求 JSON.stringify(config) === JSON.stringify(other)（容忍字段顺序）
• 永远不要写 a.filter(x => b.includes(x)) 处理对象数组 —— 这不是快捷方式，是未声明的契约漏洞

```