db.dropRole()必须在角色所属数据库中执行，否则静默失败；删前需确认角色未被用户引用，且操作者具备相应权限；批量删除应先人工核对再逐个执行。
db.dropRole() 必须在角色定义的数据库中执行
自定义角色不是全局对象，它绑定在创建时所在的数据库里。比如你在 admin 库执行 db.createRole()，那这个角色就只属于 admin；如果在 app_logs 里建的，就得去 app_logs 删。直接在别的库调 db.dropRole("my_reader") 会静默失败——没报错，也不生效。
确认角色归属：先 use admin，再运行 db.getRole("my_reader", {showPrivileges: true})。如果返回 RoleNotFound，说明角色不在当前库，换库重试：db.getSiblingDB("app_logs").getRole("my_reader")。
删角色前必须确保没人用
MongoDB 不会阻止你删正在被用户引用的角色，但删完会导致对应用户权限丢失——这不是原子操作，也没有回滚。常见误操作是：先删角色，再查用户，结果用户已经连不上库了。
- 查哪些用户用了这个角色：
db.getUsers({filter: {"roles.role": "my_reader"}}) - 查更精确的绑定关系（含库名）：
db.getUsers({filter: {"roles": {$elemMatch: {role: "my_reader", db: "admin"}}}}) - 如果返回非空，别删；要么先给用户换角色，要么确认这些用户本身也该下线
db.dropRole() 返回 false 的常见原因
db.dropRole() 成功返回 true，失败通常返回 false 或抛错。最常遇到的不是语法问题，而是上下文或权限卡点：
-
"not authorized on admin to execute command { dropRole: \"my_reader\" }"：当前登录账号缺少roleAdmin或roleAdminAnyDatabase角色，换管理员账号重连 -
RoleNotFound：角色名写错，或大小写不匹配（"MyReader"≠"myreader"） - 返回
false但无错误：大概率是当前库不对，没切到角色所在库
批量删角色要防“孤儿角色”堆积
脚本批量清理时，别直接 db.getRoles().forEach(r => db.dropRole(r.role))。一来可能删掉还在用的角色，二来容易因网络中断导致部分执行、状态难追踪。
安全做法分两步：
- 先生成待删清单：
db.getRoles({showBuiltinRoles: false}).map(r => r.role).filter(n => n.startsWith("legacy_")) - 人工核对每个角色是否真无人使用，再逐个执行
db.dropRole("legacy_app_writer")
真正麻烦的从来不是命令怎么敲，而是你删掉的那个角色，上周刚被另一个团队悄悄绑到了新用户上——查用户比删角色慢不了多少，但能省掉半夜的故障复盘。
