最可靠方式是直接查询 admin.system.users 集合，因mongodb所有用户信息（含密码哈希、角色、认证库）均持久化于此；须先 use admin，且需 useradminanydatabase 等高权限。
直接查 admin.system.users 集合是最可靠的方式
MongoDB 不提供类似 SHOW GRANTS FOR user 的单命令汇总，所有用户信息（包括密码哈希、角色列表、认证数据库）都持久化在 admin.system.users 集合里。必须先切换到 admin 数据库再查询，否则会提示无权限或查不到数据。
常见错误现象：在非 admin 库执行 show users，只能看到当前库的用户（如果有的话），但看不到角色详情；用普通用户连接后执行 db.runCommand({connectionStatus: 1}) 只能看自己当前生效的角色，不是完整分配记录。
- 连接时需有
userAdmin或更高权限（如userAdminAnyDatabase）才能读取admin.system.users -
db.system.users.find()在旧版本（admin.system.users - 输出中
roles字段是数组，每个元素含role（角色名）和db（该角色定义所在的数据库），例如{"role":"readWrite","db":"orders"}
db.runCommand({listUsers: 1}) 能显示更结构化的用户清单
这个命令比直接查集合更语义清晰，且自动过滤掉系统用户（如 __system），适合快速盘点。但它只返回当前数据库（即你 use 的库）的用户——除非你在 admin 库执行，否则看不到跨库授权的用户。
注意：它不展开角色继承关系。比如用户绑定了自定义角色 reporter，而 reporter 又继承了 read，listUsers 只显示 reporter，不会列出 read 权限。
- 在
admin库执行：use admin; db.runCommand({listUsers: 1})，才可能覆盖全部用户 - 返回结果中
roles字段与admin.system.users一致，但额外带inheritedRoles（仅当启用角色继承时才有值） - 若用户被授予
readAnyDatabase这类全库角色，此处db字段仍显示为"admin"（因为角色定义在 admin 库）
查具体用户的完整权限需要组合两步：角色 + 角色定义
知道用户绑了哪些角色只是第一步。要确认实际能做什么，得查每个角色的具体权限——尤其是自定义角色，其权限不在内置文档里。
例如用户 app_writer 在 admin 库绑了角色 orders_rw，你得再查 orders_rw 定义在哪：
- 先定位角色定义库：
db.runCommand({listRoles: 1, showPrivileges: true})查所有角色（含权限细节），但默认只查当前库；加参数db: "admin"指定范围 - 更精准的做法：
use admin; db.runCommand({listRoles: 1, filter: {role: "orders_rw"}, showPrivileges: true}) - 返回的
privileges数组里，resource字段明确标出作用域（如{"db":"orders","collection":"orders_main"}），actions列出允许的操作（如["find","insert"]）
容易忽略的权限来源：隐式继承和 admin 库绑定
很多权限问题出在“看不见”的继承链上。比如用户没直接受权 read，但绑了一个自定义角色，而该角色又 inherits 了 read；或者用户在 test 库创建，却在 admin 库被授予 readAnyDatabase——此时 test 库查 db.system.users 根本看不到这条记录。
真正完整的权限视图必须满足两个条件：
- 所有用户必须在
admin库中统一管理（MongoDB 最佳实践） - 所有自定义角色必须定义在
admin库（否则无法跨库继承，且listRoles默认不扫描其他库） - 使用
showPrivileges: true参数，否则listRoles默认不返回privileges字段，你会以为角色是空的
权限不是扁平列表，而是树状结构。一次 listUsers 看不到全貌，必须配合 listRoles 展开每一层，尤其当业务用了自定义角色时。
