直接为用户分配指定数据库的read角色是最常见且安全的单库只读配置方式，必须use目标库后执行db.createuser并明确指定{role:"read",db:"test"}，连接时需通过--authenticationdatabase指定认证库，否则认证失败。
直接给用户加 read 角色即可，但必须指定数据库，且不能跨库生效。
用 read 角色授予单库只读权限
这是最常见、最安全的查询权限配置方式。用户只能对指定数据库执行 find、count、distinct 等读操作，无法写入或删改。
- 必须先
use到目标数据库再执行db.createUser()，否则角色会绑定到当前库（比如误在admin库里创建，却想控制test库） -
roles数组里要明确写{ role: "read", db: "test" }，不能只写"read" - 如果用户还需访问其他库的只读数据，得额外加一条
{ role: "read", db: "report" }，MongoDB 不自动继承 - 示例：
use test db.createUser({ user: "reporter", pwd: "secret123", roles: [{ role: "read", db: "test" }] })
避免误用 readAnyDatabase 导致权限过大
这个角色看起来“方便”，但实际风险极高：它允许用户读取所有数据库（包括 admin、config、local），可能泄露系统元数据或备份凭证。
-
readAnyDatabase只能在admin库中创建，且需用户已通过admin认证 - 除非是 BI 工具专用账号且严格限制网络来源（配合
authenticationRestrictions），否则不建议启用 - 替代方案更可控：为每个业务库单独创建
read用户，或用自定义角色限定集合级权限
连接时必须指定 authenticationDatabase
用户凭证存在哪个库，就得告诉客户端——否则即使密码正确也会报 Authentication failed。
- 如果用户建在
test库：mongo -u "reporter" -p "secret123" --authenticationDatabase "test" - 如果用户建在
admin库（比如超级只读账号）：--authenticationDatabase "admin" - 用
db.auth()方式登录时，也得先use到对应库：use test db.auth("reporter", "secret123") - 遗漏
--authenticationDatabase是生产环境最常见的连接失败原因
真正麻烦的不是加权限，而是搞错角色作用域和认证库——这两个点一旦出错，日志里只显示模糊的 unauthorized 错误，排查起来反而比写代码还费时间。
