mongodb角色继承严格受限于创建库：仅admin库中创建的角色可跨库继承，非admin库角色只能继承本库角色；否则权限不可见或报错。
不同数据库级别的权限继承，核心限制只有一条：角色只能继承同库角色，除非它建在 admin 库。 这不是语义模糊点，而是硬性规则——违反就查不到权限、授不了权、甚至命令直接报错。
角色继承的数据库范围规则
MongoDB 对角色继承做了明确隔离：
- 在
test库创建的角色，roles字段里只能写test库里已存在的角色名（比如"reader"），不能写sales库里的角色 - 只有在
admin库创建的角色，roles字段才允许跨库引用，例如：{ role: "read", db: "logs" }或{ role: "dbAdmin", db: "config" } - 内置角色（如
read、readWrite）默认属于当前数据库上下文；想用其他库的内置角色，必须显式带db字段，且仅admin角色能这么干
rolesInfo 查权限时为什么看不到继承链？
常见现象：你给 myapp_role 加了 { role: "read", db: "analytics" }，但执行 db.runCommand({rolesInfo: "myapp_role"}) 返回的 privileges 里没出现 analytics 库的 find 权限——这不是 bug，是预期行为。
-
rolesInfo默认只返回该角色「直接定义」的权限，不展开继承项 - 必须加
showPrivileges: true才能看到完整权限集（含继承来的） - 正确命令是：
db.runCommand({rolesInfo: "myapp_role", showPrivileges: true}) - 如果角色建在非
admin库，且试图继承外库角色，这个命令会直接报错："RoleNotFound: role 'xxx' not found"
用户跨库操作权限怎么配才生效？
用户本身没有“跨库”概念，权限全靠角色堆叠。关键在角色部署位置和组合方式：
- 方案一（推荐）：在
admin库建一个聚合角色，比如app_full_access，它继承{ role: "readWrite", db: "orders" }+{ role: "read", db: "customers" } - 方案二（受限）：分别在
orders和customers库各建一个角色，再给用户在两个库分别db.grantRolesToUser()——但用户连哪个库就得切到哪个库才能用对应权限 - 注意：
db.createUser()时指定的roles数组，每个元素的db字段必须真实存在，且你有权限读取那个库的角色定义（通常只有admin用户能跨库查）
最容易被忽略的是：角色创建时的 db 上下文，决定了它后续能继承谁、被谁用、在哪查得到。建错库，权限就断在第一环，后面所有 grantRolesToUser 都只是静默失败。
