分片集群中\_id冲突不立即报错，仅在单分片内校验唯一性；跨分片重复\_id导致静默冲突，查询结果不一致；唯一索引必须含shard key，否则建索引失败。
分片集群中 _id 冲突时到底报什么错
MongoDB 分片集群对 _id 字段仍强制唯一，但**只在单个分片内校验**。如果两个不同分片上插入了相同的 _id，不会立刻报错——错误会延迟到后续查询或主键索引重建时暴露，最常见的是：duplicate key error collection，但这个错误往往出现在你执行 insertOne 或 updateOne 时，且仅当目标分片已存在该 _id。
真正危险的是「静默冲突」：两个分片各自成功写入相同 _id，之后任意分片返回结果都可能不一致，find({ _id: ... }) 可能查到任意一个，甚至因 mongos 路由逻辑变化而结果飘移。
- mongos 不做跨分片
_id去重检查，它只按 shard key 路由 - 唯一索引（包括默认
_id索引）只在分片本地构建，不跨片协调 - 如果你用自定义字段建唯一索引（如
{ email: 1 }），且该字段不是 shard key，那根本建不成功——会直接报错：cannot create unique index over { email: 1 } with shards present
为什么 shard key 必须参与唯一性保证
分片集群里，唯一性约束生效的前提是：MongoDB 能把「查重」操作精准路由到同一个分片。只有 shard key 的值确定，才能定位到唯一目标分片；否则就得广播查询所有分片，性能崩盘，还无法原子保证。
- shard key 本身必须是不可变的（否则 moveChunk 会失败）
- 若你强行用
{ email: 1 }做唯一索引，又没把它设为 shard key，MongoDB 直接拒绝建索引 - 哪怕你绕过限制（比如先停集群、手工改 config，再重启），后续任何写入都可能因路由不准导致重复，且无法被检测
- 官方不支持、驱动不兼容、备份恢复时极易出错——这不是配置问题，是架构层禁令
实际能用的全局唯一方案有哪些
别指望 MongoDB 自动帮你管全局唯一。得靠应用层或组合设计兜底，每种都有明确 trade-off：
- 用 ObjectId 作
_id：天然分布式生成，冲突概率极低，但无法业务语义化 - 拼接 shard key + 本地自增：比如
"shardA_1001"，需自己维护每个分片的计数器（用findAndModify更新counters集合），注意高并发下性能瓶颈 - 引入外部服务：如 Redis 自增 ID 或 Snowflake 服务，增加系统依赖和延迟，但可控性强
- 用复合 shard key + 应用层校验：例如
{ tenant_id: 1, doc_id: 1 }作 shard key，再在应用里确保同一tenant_id下doc_id不重复——这其实是把「全局」降维成「租户内全局」
最容易被忽略的坑：唯一索引和 chunk 迁移的冲突
即使你严格按规范建了以 shard key 开头的唯一索引（如 { region: 1, uid: 1 }），在 chunk 迁移过程中仍有风险：迁移未完成时，新旧分片可能短暂同时持有相同键值，而唯一性检查只在写入时触发，不扫描存量数据。
- 迁移期间插入重复键，可能只在目标分片报错，源分片已写入，造成数据不一致
-
moveChunk默认不校验目标分片是否已有冲突文档，除非你手动加force参数并配合预检脚本 - 运维时切记：不要在业务高峰期执行大量 chunk 迁移；监控
sh.status()中的balancer状态，避免自动均衡撞上写入高峰 - 备份恢复后务必运行
db.collection.validate(true)，它会跨分片比对，但耗时极长，不能作为日常手段
分片集群的「唯一性」从来不是开箱即用的保障，而是需要你清楚每一层路由、索引、迁移的边界在哪里。一旦越界，错误不会立刻发生，但会在最意想不到的查询路径里突然浮现。
