db.getuser()是查单个用户角色最直接方式，需先use到对应数据库，返回该库中显式授予的角色及authenticationrestrictions限制，但不显示跨库或继承权限。
db.getUser() 是查单个用户角色的最直接方式
它返回用户在当前数据库下被授予的所有角色，包括 role 和 db 字段，清楚标明“谁在哪个库被给了什么角色”。但必须先 use 到对应数据库——比如查 admin 库里的 root 用户，得先执行 use admin，再运行 db.getUser("root")。否则返回空或查到错误库的同名用户。
常见错误是连着 admin 库却没切库就执行 db.getUser("appuser")，结果查不到——因为该用户可能只在 myapp 库创建。返回结果里的 authenticationRestrictions 字段如果非空，说明这个用户还受 IP 或证书限制，不能只看角色就认为能连上。
db.getUsers() 适合快速列出当前库所有用户及其角色
它不展开权限细节，但能一眼看清当前数据库里有哪些人、各自担哪些角色。比如执行 use myapp 后运行 db.getUsers()，就能看到 appReader 用户是否被赋予了 read 角色，或者 appWriter 是否有 readWrite。
- 别用
db.getUsers({showCredentials: true})——它会暴露密码哈希，生产环境严禁 - 返回的
roles数组只包含显式授予的角色，不体现继承关系（比如某角色内部又roles了另一个角色） - 若用户有跨库角色（如
userAdminAnyDatabase），这个命令不会显示，因为它只查当前库
usersInfo 命令能查指定用户的完整角色快照，但容易漏掉集群级权限
它比 db.getUser() 更底层，也更严格：必须显式指定 db 参数，且只返回该数据库上下文中的角色。例如：db.runCommand({ usersInfo: { user: "admin_user", db: "admin" } }) 才能查到 admin 库里定义的全局角色。
如果你在 test 库执行 usersInfo 查一个拥有 clusterAdmin 的用户，结果里根本不会出现这个角色——因为 clusterAdmin 只能在 admin 库中定义和查询。所以审计时务必确认目标用户是否在 admin 库被授予权限，不能只依赖当前连接库的结果。
角色 ≠ 实际权限，别跳过 rolesInfo 这一步
db.getUser() 和 usersInfo 都只告诉你“有哪些角色”，但不告诉你这些角色到底允许做什么操作。比如 readWrite 看似明确，但它在不同数据库里生效范围可能不同；自定义角色还可能叠加 authenticationRestrictions 或限定到特定集合。
真正要看清权限边界，必须用 db.runCommand({ rolesInfo: { role: "xxx", db: "yyy" }, showPrivileges: true })。尤其注意：
- 内置角色（如
readWriteAnyDatabase）必须查admin库，否则报Role not found - 自定义角色若引用了其他角色，
rolesInfo不自动递归展开，得手动查被引用角色 -
showPrivileges: true必须显式写，否则返回里privileges字段为空
权限最终是否生效，还取决于连接时的 --authenticationDatabase、实际网络来源是否匹配 authenticationRestrictions，以及有没有 localhost exception 等隐性规则——光看角色列表，永远只是半截真相。
