可以，但必须在admin数据库中执行且仅能回收用户显式拥有的角色；若权限来自继承（如clusteradmin）或内置角色嵌套，则需先用rolesinfo查清有效角色再逐个撤销。
revokeRolesFromUser 命令能直接回收集群管理权限吗？
可以，但必须在 admin 数据库上下文中执行，且目标角色必须是用户当前实际拥有的角色。如果用户是通过角色继承（比如从 clusterAdmin 角色继承了 dropCollection 权限），而你只 revoke 了显式授予的角色，权限不会消失——这是最常被忽略的前提。
常见错误现象：revokeRolesFromUser 执行成功但用户仍能执行 shutdownServer() 或 listShards；根本原因是没查清用户当前有效角色来源（显式授予 vs. 角色继承 vs. 内置角色嵌套）。
怎么确认用户当前真实拥有的集群管理相关角色？
别只看 db.getUser("u1") 的 roles 字段，它只显示显式授予的角色。要查“有效角色”（effective roles），得用 db.runCommand({connectionStatus: 1}) 搭配登录该用户后执行，或更可靠的方式：用管理员账号运行：
db.runCommand({
rolesInfo: {
users: [{user: "u1", db: "admin"}],
showPrivileges: true,
showBuiltinRoles: true
}
})
重点关注输出中 inheritedRoles 和 privileges 数组里是否包含 clusterAdmin、root、clusterManager 等集群级角色。这些才是你要 revoke 的目标。
执行 revokeRolesFromUser 的正确姿势
必须切换到 admin 数据库，命令语法严格，参数不能省略：
- 连接 MongoDB 后先运行
use admin - 执行命令时，
roles参数必须是数组，哪怕只撤一个角色也要写成[{"role": "clusterAdmin", "db": "admin"}] - 角色名和数据库名大小写敏感；
clusterAdmin只存在于admin库，写成{"role": "clusterAdmin", "db": "test"}会静默失败 - 如果用户有多个集群角色（如同时有
clusterAdmin和root），必须全部列在数组里，否则只撤部分
示例（安全做法，一次只撤一个明确角色）：
use admin
db.runCommand({
revokeRolesFromUser: "u1",
roles: [{"role": "clusterAdmin", "db": "admin"}]
})
撤完权限后为什么用户还能执行某些集群命令？
有三个典型原因：
- 用户仍持有其他等效角色，比如
root角色隐含全部权限，撤了clusterAdmin但没撤root，权限照旧 - 应用连接串里用了
authSource=admin但实际连的是test库，而用户在test库被授予了dbOwner—— 这个角色在本库内可dropDatabase，看起来像集群操作 - MongoDB 版本差异：
clusterManager在 4.2+ 才替代部分clusterAdmin功能，老版本用户可能通过自定义角色获得碎片化权限，revokeRolesFromUser不会自动清理这些
真正保险的做法是：先用 rolesInfo 确认所有有效角色，再逐个 revoke；之后用该用户账号直连并尝试关键命令（如 db.adminCommand({listShards: 1})）验证结果。别依赖“命令返回 ok”就认为权限已失。
