更稳妥的处理方式，是直接捕获DuplicateKeyError这类明确的异常，而不是简单地用catch Exception统一兜底；同时要显式导入pymongo.errors.DuplicateKeyError，再结合e.details.get('keyPattern')，把发生冲突的唯一索引精确定位出来。

直接捕获 DuplicateKeyError 是处理 MongoDB E11000 重复键错误最稳妥的方法，不是“try-catch 万能论”，而是因为这是 MongoDB 驱动明确抛出的、可以精准识别的异常类型。

Python 中怎么 catch E11000 错误？

不要使用 except Exception，它可能会吞掉网络中断、权限不足等真正需要告警和排查的问题。正确做法是显式导入并捕获专用异常：

• from pymongo.errors import DuplicateKeyError
• insert_one() 和 insert_many() 都可能触发该异常；update_one(upsert=True) 通常不会直接抛出这个错误，但可能带来字段被意外覆盖的问题
• 错误详情中有 e.details.get('keyPattern')，可以直接告诉你冲突的是哪个索引字段（比如 {'email': 1}），比解析错误字符串更稳定也更可靠

Node.js 里 bulkWrite 怎么跳过重复项不中断？

ordered: false 是解决批量写入时跳过重复数据的关键配置——否则遇到第一个 E11000，整批操作就会立即中断。但要注意：它只是让失败项被跳过，并不代表这些数据写入成功。

• 执行完成后检查 result.writeErrors，筛选 err.code === 11000（注意这里是数字 11000，不是字符串 "E11000"）
• 不要依赖 upsert: true 来“自动去重”：它本质上是先查再改或插入，语义并不等同于去重，而且在高并发场景下，两个请求同时查不到数据时，仍然可能双写并触发 E11000
• 如果批量数据来源于同一个对象引用（例如在 map 循环中没有做深拷贝），最终插入的实际上是同一份内存对象，出现重复几乎是必然的

为什么建了 unique 索引还报重复？

很多情况下，并不是代码逻辑有问题，而是索引未真正生效，或者字段值存在隐藏差异，导致 MongoDB 重复键错误依旧出现。

• 先运行 db.collection.getIndexes() 确认索引状态是否为 "ready"，并检查是否确实设置了 "unique": true
• 检查集合中是否已经存在重复数据：可以使用 aggregate 查询 { $group: { _id: { field: "$field" }, count: { $sum: 1 } } }，找出 count > 1 的记录
• 字符串末尾空格、大小写差异以及 null 值处理方式，都可能绕过唯一校验——可以通过 collation: { locale: "en", strength: 2 } 处理大小写问题，或使用 sparse: true 应对 null 场景

_id 字段莫名冲突怎么办？

如果你没有手动设置 _id，MongoDB 会自动生成 ObjectId；但如果你手动传入了字符串（例如前端传来的 "507f1f77bcf86cd799439011"），却没有转换成 ObjectId，它就会以字符串类型存入数据库，进而导致索引判断异常或误判为重复。

• 插入前统一进行类型转换：new ObjectId(idStr)（Node.js）或 ObjectId(id_str)（Python）
• 尽量避免用时间戳、递增数字等方式手动构造 _id，这类值非常容易重复；如果确实需要可控主键，建议使用 UUID 或服务端生成的雪花 ID
• 在删除集合或重建索引之前，一定要先做好备份——尤其是线上环境，通常 dropIndex 会比 dropCollection 更安全

真正棘手的并不是 MongoDB 报出 E11000 错误本身，而是出错时你无法快速判断冲突到底来自哪条数据、哪个唯一索引，甚至不清楚是不是同一条数据被重复提交。把 keyPattern 和 dup key 的内容完整打印出来，比靠猜测排查高效得多。