readWrite角色不包含dropDatabase权限，因其仅授权集合级读写操作；真正可执行dropDatabase的最小内置角色是dbAdmin，需显式授予目标数据库。
readWrite角色根本不管dropDatabase操作
因为 readWrite 是集合级（collection-level）角色，它只授权对指定数据库内**已有集合**的 find、insert、update、delete 等操作，但明确不包含任何数据库结构变更权限——比如 dropDatabase、createCollection、dropCollection 都不在其范围内。
哪怕你用 db.createUser({roles: [{role: "readWrite", db: "myapp"}]}) 创建用户，该用户连 db.myapp.dropCollection("logs") 都会报 not authorized on myapp to execute command { drop: "logs" }，更别说整个库了。
删库需要dbAdmin或更高权限角色
真正能执行 db.dropDatabase() 的最小内置角色是 dbAdmin（注意不是 dbAdminAnyDatabase），但它必须被显式赋予目标数据库：
-
dbAdmin：允许在指定数据库上执行dropDatabase、createCollection、collMod、compact等管理操作 -
dbOwner：等价于readWrite + dbAdmin + userAdmin，适合需要完全控制单个库的运维人员 -
dbAdminAnyDatabase或root：可删任意库，但属于高危权限，生产环境应避免直接分配
例如，要让某用户能删 reporting 库，得这样建用户：
use reporting
db.createUser({
user: "reporting_admin",
pwd: "xxx",
roles: ["dbAdmin"]
})
常见误判场景：误以为use admin就能绕过限制
即使你用管理员账号登录 admin 数据库，再切换到 use reporting，执行 db.dropDatabase() 依然失败——MongoDB 的权限检查是**按连接凭证绑定的角色生效**，不是按当前 use 的数据库动态判断。也就是说：
- 用户A在
reporting库下只有readWrite角色 → 不能删库，也不能删集合 - 用户B在
admin库下有userAdminAnyDatabase→ 能管所有用户，但依然不能删reporting库（除非也加了dbAdminAnyDatabase） - 角色作用域（
db字段）和当前操作所在的数据库无关，只决定该角色能覆盖哪些资源
自定义角色时最容易漏掉的resource声明
如果你用 db.createRole() 自定义一个“可删库但不可建库”的角色，必须显式声明 resource: { db: "mydb", collection: "" } 才能覆盖数据库级操作；只写 { db: "mydb", collection: "users" } 是无效的：
db.createRole({
role: "dropOnlyMydb",
privileges: [{
resource: { db: "mydb", collection: "" }, // ← 必须是空字符串，表示整个库
actions: ["dropDatabase"]
}],
roles: []
})
否则，即使角色创建成功，授权后调用 db.dropDatabase() 仍会返回 not authorized —— 这个空字符串 "" 很容易被忽略，且文档里不强调，但它是 MongoDB 权限模型中区分库级与集合级操作的关键标识。
