直接结论：用db.grantrolestouser()追加角色，别用db.updateuser()覆盖角色——因后者全量替换roles字段，易误删原有权限；grantrolestouser需在用户所属认证数据库上下文中执行，大小写敏感且须匹配真实库名。
直接结论：用 db.grantRolesToUser() 追加角色，别用 db.updateUser() 覆盖角色——除非你明确想清空旧权限。
为什么不能直接用 updateUser 修改 roles？
db.updateUser() 的 roles 字段是全量替换。比如用户原本有 [{role:"read", db:"orders"}]，你执行：db.updateUser("alice", {roles: [{role:"readWrite", db:"orders"}]})，结果是“只读”权限被彻底删除，只剩“读写”。这在生产环境极易引发误操作导致服务异常。
真正安全的做法是只追加、不覆盖。MongoDB 提供了专用命令：db.grantRolesToUser() 和 db.revokeRolesFromUser()，它们只增/删角色，不影响其他已有权限。
grantRolesToUser 的实际用法和常见错误
必须在**用户所属角色定义的数据库上下文**中执行该命令。例如，给 testdb 中的用户 appuser 添加 dbAdmin 角色，得先 use testdb，再运行命令：
use testdb
db.grantRolesToUser("appuser", [{role: "dbAdmin", db: "testdb"}])
常见错误包括：
- 在
admin库里对非admin用户执行 —— 报错no such user（因为用户元数据存在目标库的system.users集合里） - 角色名拼错，比如写成
"readwrite"（小写）—— MongoDB 严格区分大小写，正确是"readWrite" - 试图授予跨库角色（如
readWriteAnyDatabase）却没在admin库执行 —— 必须use admin后再调用
如何验证权限是否生效？
不要只查 db.getUser("username")，它只显示配置，不反映实际行为。真实验证要模拟应用操作：
- 用新权限用户连接：
mongosh -u appuser -p password --authenticationDatabase testdb - 尝试执行目标操作，例如：
db.orders.insertOne({item: "book"})（测试写权限）或db.getCollectionNames()（测试dbAdmin） - 遇到
not authorized错误时，检查两点：1）当前 shell 是否在正确数据库下（use testdb）；2）错误信息里的resource是否匹配你授的角色范围（比如报错说无权访问logs集合，但你只给了orders的readWrite）
权限变更后连接失败？注意 authenticationDatabase
很多用户改完权限后发现连不上，问题常出在连接时没指定 --authenticationDatabase。MongoDB 认证凭据默认存于用户创建时所在的数据库（不是角色作用的数据库）。比如你在 testdb 里创建了用户，那认证库就是 testdb，连接时必须显式带上：mongosh -u appuser -p pwd --authenticationDatabase testdb。
如果省略或写成 admin，就会报 Authentication failed，哪怕密码完全正确。
这个细节极容易被忽略，尤其当用户在 admin 库创建、却管理其他库时，更需反复确认认证库与用户元数据所在库一致。
