revokeRoles 是撤销 MongoDB 用户特定权限的唯一可靠方式，必须通过移除完整角色（含精确 db 字段）实现，不能直接修改权限或拆解角色内部权限。
撤销 MongoDB 用户的特定权限：用 revokeRoles 是唯一可靠方式
MongoDB 不支持“删掉某个 role 里的某条权限”，只能整 role 撤销。想撤掉某项特定权限（比如只去掉 insert，保留 find），必须先查清它属于哪个角色，再把那个角色从用户身上移除——哪怕你只是想微调。
常见错误是试图用 updateUser 直接改 privileges 字段，但 MongoDB 服务端根本不认这种写法，会静默忽略或报错 "cannot modify user privileges directly"。
-
revokeRoles是官方唯一支持的权限回收命令，作用对象是「角色」，不是单条权限 - 内置角色（如
readWrite）和自定义角色都适用，但不能拆解角色内部权限 - 操作前必须用
db.getUser()确认用户当前有哪些角色，避免误撤关键权限（比如不小心撤了dbAdmin导致连collStats都跑不了）
查清楚权限来源：别把 readWrite 当成“一个权限”
看到用户能 insert，别急着撤——先确认这权限来自哪个角色。可能是 readWrite，也可能是你半年前建的自定义角色 analyticsWriter，甚至可能是数据库级角色误绑到了 admin 库。
执行：
db.getUser("alice", { showPrivileges: true })，重点看返回里的 roles 数组和每个 role 的 db 字段。注意：同一角色在不同库上效果不同，{ role: "readWrite", db: "reporting" } 和 { role: "readWrite", db: "logs" } 是两条独立授权。
- 自定义角色要进对应
admin库查定义：db.getRole("myCustomRole", { showPrivileges: true }) - 如果权限来自
clusterAdmin这类高危角色，撤它之前得确认用户是否真不需要shutdown或setParameter - 别漏掉
inheritedRoles——有些权限是通过角色继承来的，源头可能藏在另一个角色里
执行撤销：用 revokeRoles 时必须指定完整 role 结构
语法不是 revokeRoles("alice", ["readWrite"]) 就完事。MongoDB 要求 role 描述和当初授予权限时完全一致，包括 db 字段。少写一个库名，命令就无效。
正确示例（撤掉用户 alice 在 reporting 库的 readWrite 权限）：
db.revokeRolesFromUser("alice", [{ role: "readWrite", db: "reporting" }])
- 多个角色要一起撤：传数组，如
[{role:"read",db:"app"},{role:"readWrite",db:"cache"}] - 如果角色是自定义的，且定义在
admin库，db字段仍填角色定义所在库，不是权限生效的库 - 没加
{ writeConcern: { w: "majority" } }参数？默认是w:1，副本集里可能刚撤完主节点就宕机，权限还在从节点上残留几秒
验证是否生效：别只测 insert，要测实际业务语句
撤完立刻用目标用户连上去，执行一条最贴近真实场景的命令。光测 db.collection.insertOne({}) 不够——应用可能用 bulkWrite、带 upsert 的 update、甚至事务里的写操作，这些触发的权限检查路径略有不同。
典型失败现象：not authorized on mydb to execute command { insert: "events", ... } 是预期结果；但如果报 command find requires authentication，说明你误撤了 read 相关角色，得赶紧加回去。
- 用
db.runCommand({ connectionStatus: 1 })看当前用户身份和已解析的角色列表，比getUser更实时 - 如果应用用连接池，记得重启连接或等旧连接超时，否则缓存的权限状态会误导判断
- 跨库操作容易被忽略：比如用户有
{role:"readWrite",db:"orders"}，但业务代码却连到admin库执行db.orders.insert()——这时权限不生效，不是撤销失败，是根本没匹配上
