不能靠禁止drop命令来限制应用账号，必须通过最小化角色权限实现：只授予{role:"readwrite", db:"app_db"}等限定范围权限，禁用dbadmin、root等含drop权限的高危角色。
不能靠“禁止 drop 命令”来限制应用账号——MongoDB 没有全局禁用某类命令的开关，只能靠角色权限最小化来实现。直接给应用账号赋予 dbAdmin 或 root 角色，等于开了 drop 门；真正有效的做法是：不授权、不建角色、不连 admin 库。
为什么 db.dropUser() 和 db.dropDatabase() 不是一回事？
新手常混淆这两个操作：db.dropUser() 是管理用户（需 userAdmin 权限），db.dropDatabase() 是删整个库（需 dbOwner 或更高级权限）。应用账号通常只需要读写数据，这两者都不该有。误授其中任一权限，就等于允许它清空业务数据或踢掉其他用户。
-
db.dropDatabase()只能在当前use的数据库上下文中执行，且必须拥有该库的dbOwner角色 -
db.dropUser()必须在目标用户所属的认证库中执行（比如删 admin 用户就得use admin），且需要userAdmin类角色 - 即使账号有
readWrite权限，也完全无法调用这两个命令——权限模型是白名单制，没给就不让干
怎么确认应用账号真没 drop 权限？
别只看角色名，要查实际生效权限。MongoDB 的权限继承和作用域容易绕晕，最可靠的方式是登录后手动试错 + 查 db.getUser() 输出。
- 用应用账号登录：
mongo -u app_user -p pwd --authenticationDatabase app_db - 执行
use app_db后尝试db.dropDatabase()→ 应报错"not authorized on app_db to execute command { dropDatabase: 1 }" - 执行
use admin后尝试db.dropUser("xxx")→ 应报错"not authorized on admin to execute command { dropUser: \"xxx\" }" - 运行
db.getUser("app_user")，检查roles字段是否只含{role: "readWrite", db: "app_db"}这类限定范围的条目，不含dbAdmin、userAdminAnyDatabase等高危角色
批量创建时怎么防误授 drop 权限？
运维脚本或 CI/CD 流水线里硬编码 roles: ["readWrite", "dbAdmin"] 是高频雷区。尤其当模板复用、变量未清理时，新账号可能意外带上 dbAdmin——它默认包含 dropDatabase、dropCollection 等权限。
- 创建用户时显式指定最小角色集，例如：
db.createUser({user:"app_rw", pwd:"...", roles:[{role:"readWrite", db:"app_db"}]}) - 避免使用通配符角色名，如
"dbAdmin"要写全{role:"dbAdmin", db:"app_db"}，且仅在确实需要时才加 - 所有用户创建脚本上线前，用测试账号执行
db.runCommand({connectionStatus: 1}).authInfo.roles验证实际权限边界 - 配置文件里启用
security.authorization: enabled是前提，否则所有权限检查都失效
真正的风险不在命令能不能输，而在角色配得够不够窄——一个 readWrite 角色不会自动升级成 dbAdmin，但运维复制粘贴时多敲了一个角色，系统就认了。每次加权限，都要问一句：这个操作是不是该账号 100% 必须做？
