mongodb不允许在事务中修改分片键值，这是分片协议层的硬性拦截；仅允许通过mongos发起的独立可重试写入操作，在完整分片键等值过滤条件下更新非空值，且不能导致跨分片迁移。
事务内修改分片键值会直接报错
不能在事务中修改分片键值，不是语法或驱动问题，而是 MongoDB 分片协议层的硬性拦截。只要 updateOne、replaceOne 或 findOneAndUpdate 的更新操作涉及分片键字段（哪怕只改其中一个字段），且该集合已分片，mongos 就会在事务提交前拒绝执行，返回类似 cannot modify shard key 的错误。
哪些操作看似可行但实际失败
常见误解包括：以为用 db.collection.bulkWrite() 包裹单条更新就能绕过限制，或认为在事务外先 db.runCommand({ collMod: ... }) 修改索引就能“松动”分片键 —— 这些全无效。
-
collMod对分片键字段的索引完全无影响，命令会静默忽略或报already sharded -
bulkWrite中即使只有一条更新含分片键修改，整个批量也会被 mongos 拒绝，不进任何分片 - 直接连到某个 shard 节点执行更新（绕过 mongos）会导致数据不一致，且后续路由失效，属于危险操作
唯一允许修改分片键值的场景
仅当满足全部以下条件时，updateOne 才能成功修改分片键字段：
- 操作必须通过
mongos发起（不能直连 shard） - 查询 filter 必须包含完整的分片键等值条件（如分片键是
{tenant_id: 1, seq: 1}，filter 就得是{tenant_id: "a", seq: 123}） - 更新内容不能让分片键字段变为
null或缺失（$unset分片键字段会失败） - 不能在事务中执行 —— 必须是独立的、可重试的单次写入
注意：即便满足这些，修改后若导致文档需跨分片迁移，性能开销也远高于普通更新，且无法批量处理。
为什么设计成这样
分片键值决定文档归属哪个 chunk、哪个 shard，而 chunk 边界和位置由 config server 全局维护。事务要求 ACID，但跨分片移动文档需要协调多个 shard 的状态变更、锁 chunk、拆分/迁移 —— 这些操作本身不可回滚，也不满足原子性。MongoDB 宁可禁止，也不引入最终一致性风险。
真正需要变更分片键语义的场景，只能走重建集合路线，而不是试图在运行中“修补”键值。
