MongoDB单文档BSON大小上限为16MB，事务内各操作仍受此约束；超限即报DocumentTooLarge错误，无法通过配置放宽，只能用GridFS或拆分文档重构模型。
不是事务本身设了 16MB 限制，而是事务里每个 insertOne、updateOne、findAndModify 操作仍受 MongoDB 单文档 BSON 大小上限约束——即 16MB。超限直接报 DocumentTooLarge（错误码 10334），和事务无关。
为什么事务内写入大文档会报 DocumentTooLarge
事务只是把多个操作打包进一个原子上下文，不改变底层文档尺寸规则。所有操作仍走同一套 BSON 解析与传输逻辑，和普通命令无区别：
-
insertMany在事务中依然按单文档校验，不会合并压缩或跳过大小检查 -
findAndModify若开启$projection返回大量字段，响应体也可能因超限被拦 - 哪怕只在
session.withTransaction()里执行一次insertOne，只要该文档序列化后 >16MB，就立刻失败
transactionLifetimeLimitSeconds 调不了 16MB 限制
这个参数只控制事务最大存活时间（默认 60 秒），和文档大小完全无关。MongoDB 没有提供任何配置项（如 transactionMaxSize 或服务端 flag）来放宽 16MB 上限——它硬编码在 BSON 规范和 WiredTiger 存储引擎的页大小设计中：
- BSON 格式定义单个文档最大为
2^24 - 1字节（即 16MB - 1B），这是协议层边界 - WiredTiger 默认页大小为 4KB，单文档必须能装进连续内存块，过大将导致分配失败
- 复制集 oplog 条目也是 BSON 文档，若允许超限事务提交，oplog 就无法记录，破坏主从一致性
真正可行的绕过方式只有两种
不能“绕过”，只能重构数据模型或拆分操作。事务 ≠ 大数据搬运工具，它的定位是保障多步业务逻辑的原子性，而非突破存储边界：
- 用
GridFS存大内容，但必须同步写一条元数据文档到用户集合（含file_id字段关联fs.files._id），所有可查字段（如timestamp、status）都得显式存进元数据集合并建索引 - 拆文档：把大数组（如日志列表、任务集合）抽到独立集合，主文档只留引用字段（如
projectId）；注意分页、跨文档排序、统计字段原子更新等代价需由应用层承担 - 别碰
fs.chunks或fs.files做聚合——它们结构固定、字段不可索引、不支持$match/$sort/$lookup
最容易被忽略的一点是：即使你用分片集群、调高 transactionLifetimeLimitSeconds、加大 WiredTiger 缓存，只要单次写入的 BSON 文档超过 16MB，WriteCommandError 就会立刻抛出——这个边界没有商量余地。
