MongoDB事务不参与权限校验，所有操作实时受RBAC角色约束；每条CRUD命令执行时即检查权限，越权立即报错，管理操作禁止在事务中执行。
MongoDB 事务本身不直接参与权限校验，所有权限控制完全依赖 RBAC 角色在会话级生效；事务内执行的每个操作（如 insert、update、delete）仍受当前用户角色约束，越权操作会在事务提交前就报错。
事务中哪些操作会触发权限检查
权限检查发生在每条命令执行时，不是事务提交时。哪怕你在 session.startTransaction() 后执行一条 db.orders.insertOne()，只要该用户没被授予 orders 所在数据库的 insert 权限（比如没分配 readWrite 或更细粒度角色），立刻返回 Unauthorized 错误，事务不会继续。
- 所有 CRUD 操作（
find、updateOne、deleteMany等）都实时校验对应集合/数据库的角色权限 -
createCollection、dropCollection、collMod等管理操作需dbAdmin或更高角色，且不能在事务中执行（MongoDB 明确禁止） - 跨库事务中，用户必须对涉及的每个数据库都有对应角色——例如事务同时写
orders和inventory，则角色列表里得同时含{role: "readWrite", db: "orders"}和{role: "readWrite", db: "inventory"}
内置角色对事务的实际限制边界
常见角色对事务的支持程度差异很大，关键看它是否覆盖「目标数据库+目标操作类型」：
-
readWrite：允许在指定数据库内对任意集合做事务内读写，但不能建索引或改结构 -
dbAdmin：能执行createIndex等管理命令，但这些命令本身不允许在事务中调用，所以该角色对事务无额外增益 -
readWriteAnyDatabase：只在admin库创建才有效，授权后可在事务中跨任意数据库读写（仍需显式指定每个库的角色） -
root：覆盖全部操作，但不意味着能绕过事务限制——比如依然不能在事务里dropDatabase
注意：userAdmin 类角色只管账号管理，对事务内数据操作完全无效。
自定义角色才能实现字段级事务权限
内置角色最小粒度是「数据库+集合」，若需限制事务中只能更新 status 字段而不能碰 price，必须用自定义角色 + privileges 显式声明可操作字段：
db.createRole({
role: "updateStatusOnly",
privileges: [{
resource: { db: "sales", collection: "orders" },
actions: ["update"]
}],
roles: []
})
db.grantPrivilegesToRole("updateStatusOnly", [{
resource: { db: "sales", collection: "orders" },
actions: ["update"]
}])
然后在 update 操作中用 $set 限定字段，靠应用层逻辑配合角色——MongoDB 不解析更新内容语义，所以角色本身不拦 price 字段，拦的是「有没有 update 权限」；真要字段级拦截，得靠 @casl/mongoose 这类上层库把规则转成查询条件。
容易忽略的 authSource 和连接参数陷阱
事务权限失效，80% 出在认证源头配错：
- 用户在
admin库创建，但连接时没加?authSource=admin，导致服务端按默认test库找用户，直接报Authentication failed - 使用连接字符串时，
mongodb://user:pass@host/dbname中的dbname是默认数据库，不是认证库；必须显式写成mongodb://user:pass@host/?authSource=admin - Driver 初始化 session 时若未复用已认证连接，可能新建未认证会话，事务内第一条命令就失败
最稳妥的做法：所有连接字符串强制带 authSource=admin，且用户角色中明确包含涉及的每个数据库名——别指望一个 root 角色能自动覆盖所有隐式访问。
