mongodb中不存在getrole命令，应使用db.runcommand({rolesinfo: ..., showprivileges: true})查询角色权限；rolesinfo需显式启用showprivileges:true才能显示privileges和authenticationrestrictions等关键信息。
getRole 命令在 MongoDB 中并不存在 —— 这是常见误记，实际应使用 rolesInfo 命令。直接调用 db.runCommand({rolesInfo: ...}) 才能展开角色背后的真实权限动作和资源范围。
为什么 db.getRole() 会报错
执行 db.getRole("readWrite") 会返回类似 "no such command: getRole" 的错误。MongoDB 官方从未提供 getRole 这个 shell 方法；它只存在于部分过时文档或用户混淆了 getUser 和角色查询逻辑。
-
getUser是合法的 shell 方法，用于查用户（含其 roles 数组） -
rolesInfo是数据库命令（command），必须通过db.runCommand()调用 - Shell 中没有
getRole、listRoles等便捷方法，全靠rolesInfo驱动
rolesInfo 命令的正确调用方式
要查内置角色（如 readWrite）或自定义角色的完整权限，必须显式启用 showPrivileges: true，否则返回结果里 privileges 字段为空或被省略。
- 查 admin 库中的
readWrite角色：db.runCommand({rolesInfo: {role: "readWrite", db: "admin"}, showPrivileges: true}) - 查当前数据库（如
myapp）里的自定义角色：db.runCommand({rolesInfo: {role: "appReader", db: "myapp"}, showPrivileges: true}) - 批量查本库所有角色（含内置）：
db.runCommand({rolesInfo: 1, showPrivileges: true, showBuiltinRoles: true})
注意 authenticationRestrictions 和作用域限制
权限不只是“能做什么”，还包括“在哪做”和“谁可以做”。rolesInfo 返回的 privileges 数组中每个对象都含 resource 字段，它决定操作是否受限于特定集合或数据库；而 authenticationRestrictions（若存在）会进一步限定 IP 或客户端证书要求。
- 例如
resource: {collection: "logs", db: "myapp"}表示该权限仅对myapp.logs生效 - 若返回中含
authenticationRestrictions: [{clientSource: ["10.0.1.0/24"]}]，说明即使有角色，也只允许来自该网段的连接使用 - 这些限制不会出现在
db.getUser()结果里，必须靠rolesInfo+showPrivileges: true才能看到
权限继承关系必须手动展开
MongoDB 角色可继承其他角色（比如自定义角色 A grantsRolesToRole B），但 rolesInfo 默认不递归展开继承链。若想看到最终合并后的全部权限，得自己逐层调用：
- 先查角色 A 的
rolesInfo，看它的inheritedRoles字段 - 再对每个继承的角色（如
{role: "read", db: "otherdb"}）单独发一次rolesInfo - 内置角色（如
dbOwner）本身也继承自更底层角色，但官方不公开其继承路径，只能依赖showPrivileges: true直接看最终效果
真正麻烦的不是查不到，而是查到之后还得人工拼权限集——尤其当多个角色叠加、且作用域不一致时，容易漏掉某条 find 权限只在 system.views 上有效这种细节。
