在 Atlas UI 配置权限最稳妥，但需注意：权限生效有延迟（免费/Flex 层最多 30 秒），角色冲突时取最高权限，自定义角色不可用 mongosh 直接修改（否则被自动回滚）；创建用户须指定身份验证机制（默认仅 SCRAM/X.509），SCRAM 用户密码必设且认证库固定为 admin，X.509 用户库为 $external；内置角色无法细化到字段或动态条件，需自定义角色实现；单用户最多 20 个自定义角色，项目默认上限 100 个，超限需调用 setProjectLimit API 扩容；权限验证应使用 db.runCommand({getPrivileges: 1}) 查看实际生效权限，而非依赖 UI 勾选。
直接在 Atlas UI 里配权限最稳妥，但必须注意：权限生效有延迟、角色冲突时取最高权、自定义角色不能用 mongosh 直接改——否则会被 Atlas 自动回滚。
创建数据库用户时必须指定身份验证机制
Atlas 默认只允许 SCRAM 和 X.509，其他如 Kerberos 或 LDAP 仅限 Enterprise 或特定 Atlas 层级（M10+）。免费层和 Flex 层不支持 LDAP，且 OIDC 和 AWS-IAM 需单独开启并绑定身份提供方。
-
SCRAM用户必须设密码，身份验证数据库固定为admin；旧版 MongoDB 4.0 之前创建的用户需重置密码才能启用SCRAM-SHA-256 -
X.509用户身份验证数据库是$external，但若启用了LDAP授权，则X.509用户无法连接 - 不要在 UI 中勾选“自动创建用户”后就跳过权限检查——它默认只给
read，连listCollections都可能被拒
内置角色 vs 自定义角色的权限边界
内置角色（如 readWrite、dbAdmin）作用域明确，但无法细化到集合级字段或动态条件。一旦需要按用户 ID 过滤文档、或只允许删自己插入的数据，就必须用自定义角色 + 规则表达式。
- 自定义角色只能通过
Atlas CLI、Atlas Administration API或 UI 创建，mongosh执行db.createRole()会失败或被回滚 - 单个用户最多分配 20 个自定义角色；项目默认上限 100 个自定义角色，超限需调用
setProjectLimitAPI 扩容 - 角色权限冲突时，Atlas 不做“求交集”，而是取各权限项的最高值——比如一个角色给
read，另一个给readWrite，最终就是readWrite
权限变更后常见延迟与验证方式
免费层和 Flex 集群上，自定义角色修改最多延迟 30 秒才生效；M10+ 集群通常秒级，但仍有缓存窗口。别靠重连客户端来验证，容易误判。
- 用
mongosh连接后执行db.runCommand({connectionStatus: 1})确认当前认证用户和角色 - 执行
db.runCommand({getPrivileges: 1})查看实际生效的全部权限，而非 UI 上勾选的内容 - 如果报错
not authorized on xxx to execute command，先检查resource字段是否漏写db或collection名——空字符串""不等于通配
最容易被忽略的是：权限模型里没有“继承链”概念，只有“角色叠加 + 最高权胜出”。哪怕你给用户分配了 15 个角色，只要其中任意一个没覆盖某个操作，而其他角色也没补上，那个操作就不可用——不是所有权限加起来就行，得每个必要动作都被至少一个角色显式授权。
