核心是切断db.dropDatabase()执行路径，即禁用root角色并显式授予最小权限角色；root隐含__system权限可绕过隔离，而readWrite等内置角色不包含dropDatabase，须通过disableListDatabase参数或自定义角色彻底封禁跨库操作。
直接禁止删库操作，核心不是靠“加限制命令”，而是从权限模型源头切断 db.dropDatabase() 的执行路径。MongoDB 没有“禁用某个命令”的开关，只有“不给执行它的权限”这一种可靠方式。
为什么给 readWrite 角色仍可能删库
常见误解是：只要没给 dbAdmin 就不能删库。但现实是——只要账号拥有 root 角色（哪怕只在 admin 库创建），它就能 use production 后立刻执行 db.dropDatabase()，且不会报错。
-
root隐式含__system权限，绕过所有库级隔离 - 错误示例：
db.createUser({user:"app", pwd:"x", roles:["root"]})—— 这个用户连上任意库都能删 - 云服务（如 Atlas）可能屏蔽部分系统命令，但
dropDatabase通常仍被允许，取决于底层实现
正确做法：显式绑定最小权限到目标库
权限必须写死在 roles 数组里，且每个角色都带 db:"myapp" 字段。MongoDB 不会根据连接串中的 authSource 或默认库自动推断作用域。
- ✅ 正确创建：
db.createUser({user:"app_user", pwd:"p", roles:[{role:"readWrite", db:"myapp"}]})（在admin库执行） - ❌ 错误写法：
roles:["readWrite"]—— 权限实际落在当前认证库（通常是admin），对myapp库无效 -
readWrite不含dropDatabase，也不含createCollection；建集合需额外加dbAdmin，且必须同属db:"myapp"
彻底封死跨库和删库入口
仅靠内置角色还不够。用户仍可 use otherdb 再试操作，或通过 listDatabases 发现所有库名。必须叠加配置层控制：
- 启动时加参数：
--setParameter disableListDatabase=1（MongoDB 4.2+ 支持），否则任何有角色的用户都能看到全部库名 - 更稳妥的是自定义角色，只放必要动作：
db.createRole({role:"appMinimal", privileges:[{resource:{db:"myapp", collection:""}, actions:["find","insert","update","remove"]}], roles:[]}) - 验证是否生效：
db.adminCommand({listDatabases:1})应返回"not authorized"；use logs后执行db.collection.find()必须失败
最容易被忽略的一点：销毁保护（SetDBInstanceDeletionProtection）只防控制台/API 删实例，不防应用账号执行 db.dropDatabase()。权限隔离和参数禁用才是数据库内真正的“删库熔断器”。
