readAnyDatabase是集群级只读角色，可跨库读取任意非系统集合；read是库级只读角色，仅限显式授权的单个数据库，二者作用域不同且不可互换。
readAnyDatabase 是全局读权限，read 是库级读权限
本质区别就一句话：readAnyDatabase 能跨库读任意集合（包括新创建的库），read 只能读被显式授权过的某个库。不是“功能更强”，而是“作用域不同”——前者是集群维度角色，后者是数据库维度角色。
常见错误现象：给用户加了 read 角色却连不上新库，或者误以为加了 readAnyDatabase 就能写数据（它真不能写）。
-
read必须在具体数据库上下文中授予，比如db.grantRolesToUser("alice", [{role: "read", db: "orders"}]) -
readAnyDatabase只能在admin库授予，且不指定db字段：db.runCommand({grantRolesToUser: "alice", roles: ["readAnyDatabase"]}) - 如果用户需要读多个已有库，用
read更细粒度；如果要支持动态新增库（如 SaaS 多租户场景），readAnyDatabase才实际可用
readAnyDatabase 不包含对 system.* 集合的读权限
很多人以为“any database”就是所有东西都能读，结果发现查 system.users 或 system.roles 直接报 not authorized。这是因为 MongoDB 把权限拆得更细：readAnyDatabase 只覆盖普通用户集合，不碰系统集合。
使用场景：审计脚本、备份工具、监控 agent 需要遍历所有业务库时，往往还得额外加 clusterMonitor 或 backup 角色才能读 admin.system.version 这类元数据。
- 查
local.oplog.rs？不行，readAnyDatabase无效，得用clusterMonitor - 想看
admin.system.roles？必须显式授予read角色到admin库，或用userAdminAnyDatabase -
readAnyDatabase+clusterMonitor组合，才接近“只读全览”的实用配置
read 角色在分片集群里不会自动同步到所有分片
这是容易被忽略的坑。在分片集群中，read 角色只在授权时所在的 config server 或 mongos 上生效。如果用户直连某个 shard，而该 shard 没有对应角色记录，查询就会失败——readAnyDatabase 则没这个问题，它是内置角色，所有节点都认。
性能影响不大，但运维成本明显：用 read 就得确保每个库（尤其是新库）都在所有相关节点上重复执行授权；用 readAnyDatabase 一次授予，全集群生效。
- 直连 shard 执行
db.coll.find()报not authorized？先检查是不是绕过了 mongos - 自动化部署新库时，别只在 mongos 上授
read，还得跑一遍sh.addShardToZone类似的同步逻辑（其实更推荐直接用readAnyDatabase避开这层） -
readAnyDatabase的权限检查发生在 mongos 层，不穿透到每个 shard 做二次鉴权，反而更轻量
readAnyDatabase 无法降权为 read，也不能被 read 替代
两者不可互转，也不是“父子关系”。MongoDB 的角色模型里，readAnyDatabase 是独立内置角色，和 read 平级。删掉 readAnyDatabase 后，用户不会自动继承任何 read 权限；反过来，给一堆 read 也凑不出 readAnyDatabase 的效果。
最容易被忽略的地方：权限变更后，连接不会自动刷新。用户可能还拿着旧的认证凭证，看起来像“改了没生效”。必须让客户端重连，或调 db.logout() 再重新 db.auth()。
- 临时测试时，别只改角色，记得
db.runCommand({revokePrivilegesFromRole: ...})后强制重连 - CI/CD 自动化脚本里，如果用
read授权新库，一定要确认 mongos 和所有 shard 的角色状态一致，否则上线即故障 - 审计日志里看到大量
Unauthorized，优先查角色是否落在了错误的数据库上下文（比如把read加到了test库，但应用连的是prod）
