indexOf无法通过内容匹配对象，因其内部使用严格相等（===）判断，对象比较的是引用而非结构，故{a:1}=== {a:1}为false，导致[{a:1}].indexOf({a:1})返回-1。

数组的 indexOf 方法无法通过内容匹配对象，只认“是不是同一个东西”，不是“长得一模一样就行”——这是它最核心的局限性。理解这一点，才能避开大量隐性 bug。

为什么 indexOf 查不到对象？

因为 indexOf 内部用的是严格相等（===）判断：

• 基本类型（数字、字符串等）值相同就相等，所以 [1,2,3].indexOf(2) 能返回 1
• 对象是引用类型，每次 {id: 1} 都新建一个内存地址，哪怕结构完全一样，{id: 1} === {id: 1} 也是 false
• 所以 [{id: 1}].indexOf({id: 1}) 必然返回 -1，哪怕你肉眼看着“一模一样”

哪些场景会踩这个坑？

这些写法表面合理，实际都失效：

• 从 API 拿到用户数据后，想查它在本地列表中的位置：userList.indexOf(apiUser) → -1（除非你刻意复用引用）
• 用字面量构造对象做查找：arr.indexOf({status: 'active'}) → 几乎总失败
• 子数组查找：[[1,2]].indexOf([1,2]) → -1（数组也是对象）
• Vue/React 中响应式对象被代理后，原始引用丢失，indexOf 更容易失灵

真正可靠的替代方案

别硬扛，换方法：

• 用 findIndex() + 箭头函数：简洁通用，支持任意条件
  users.findIndex(u => u.id === targetId) 或 u.name.includes('John')
• 需要找最后一个匹配项？优先用原生 findLastIndex()（ES2023），旧环境可降级为 users.slice().reverse().findIndex(...)，但注意大数组性能
• 要频繁做对象内容查找？封装一个带深度比较的工具函数，或引入 Lodash 的 findIndex 配合 isEqual
• 仅需判断是否存在（不要索引）？some() 语义更清晰：arr.some(item => item.id === 5)

额外注意两个边界情况

就算不用对象，indexOf 也有易忽略的陷阱：

• NaN：虽然 NaN === NaN 是 false，但 [NaN].indexOf(NaN) 却返回 0 —— 这是历史特例，不可靠，查 NaN 应用 findIndex(isNaN)
• IE8 及更早版本不支持数组 indexOf，必须 Polyfill 或改用 $.inArray 等兼容方案