用 db.getUser() 查单个用户权限最直接，但需先切换到对应数据库；db.getUsers() 适合批量查看当前库用户角色；rolesInfo 命令才能展开角色的具体权限动作；还需检查 authenticationRestrictions 和 --authenticationDatabase 配置。
用 db.getUser() 查单个用户的完整权限结构
这是最直接的方式，能拿到用户在哪个库创建、拥有哪些角色、是否有认证限制等全部字段。注意它只查当前数据库下的用户——哪怕你连的是 admin，执行 use myapp 后再运行，查到的就是 myapp 库里的用户，不是全局用户。
常见错误是没切对库就执行，结果返回空数组或查错人。比如想查 root 用户，必须先 use admin，再运行：
db.getUser("root")
返回内容里 roles 数组才是权限核心，每个对象含 role 和 db 字段，代表“在哪个库被授予了什么角色”。authenticationRestrictions 如果非空，说明该用户被限定了IP或客户端证书，这点常被忽略。
用 db.getUsers() 批量看当前库所有用户角色分配
适合快速摸底一个库有哪些人、各自担什么角色。但它不显示权限细节，只列角色名和所属库，没法知道这个 readWrite 是不是加了集合级限制，也没法看出是否继承自其他角色。
实操建议：
- 连上目标库后立即执行，避免误判权限范围
- 如果返回的
roles里有dbOwner，基本等于对该库有全权；但若只有read，得确认是否被privileges字段额外收紧（这个字段只在自定义角色里出现，内置角色不显式列出） - 注意
db.getUsers({showCredentials: true})会暴露密码哈希，生产环境禁用
用 rolesInfo 命令展开角色定义，看清底层权限动作
db.runCommand({rolesInfo: {role: "readWrite", db: "admin"}}) 这类调用，才能看到角色背后真正允许的操作，比如 "find"、"insert"、"dropCollection" 等具体行为，甚至包括作用域（如仅限某几个集合）。
为什么必须这一步？因为 MongoDB 权限是“角色→权限动作→资源”的三层映射。光看 roles 字段就像只读职位名称，不看 rolesInfo 就不知道这个“工程师”到底能不能动服务器、有没有 sudo 权限。
容易踩的坑：
- 查内置角色必须指定
db，比如readWriteAnyDatabase要查admin库，否则报错Role not found - 自定义角色可能引用其他角色（
privileges+roles并存），需递归查，不能只看第一层 -
rolesInfo不返回用户实际生效的最终权限集（比如多个角色叠加后的交集/并集），只是静态定义
权限生效≠角色存在：别漏掉 authenticationRestrictions 和连接时的 --authenticationDatabase
一个用户明明有 root 角色，却连不上集群？大概率是 authenticationRestrictions 里锁了源 IP，或者你连的时候没指定 --authenticationDatabase admin，导致 mongod 按默认库（通常是 test）去找用户凭证，自然失败。
真实场景中，这类配置比角色本身更易出问题，因为它们不参与 rolesInfo 展开，也不在 getUser 的主权限字段里高亮提醒。每次权限异常，先检查这两处比反复改角色更省时间。
复杂点在于：限制条件（如 IP 白名单）和角色权限是“与”关系，缺一不可满足。而角色之间的权限是“或”关系——只要任一角色允许某操作，即算授权通过。这个逻辑差异，调试时很容易绕晕。
