mongodb 7.0 启用rbac必须先启用访问控制（--auth或security.authorization: enabled），否则角色无效；rbac是授权机制，非身份验证；角色作用域限于指定数据库；分片集群用户须在mongos创建；默认且仅支持scram-sha-256认证机制。
MongoDB 7.0 中启用基于角色的访问控制（RBAC）必须先启用访问控制，再创建具有明确角色的用户；不启用 --auth 或配置文件中的 security.authorization: enabled，所有角色和权限设置都无效。
必须先启用访问控制，否则 RBAC 不生效
RBAC 是访问控制的授权机制，它不等于身份验证本身。很多用户误以为只要 db.createUser() 指定了角色，权限就自动生效——其实前提是服务启动时已强制要求认证。
- 独立实例：启动
mongod时必须加--auth参数，或在配置文件中设security.authorization: enabled - 副本集/分片集群：除客户端连接认证外，还必须配置内部身份验证（如密钥文件或 x.509），否则节点间通信失败，集群无法初始化
- 配置文件路径示例：
/etc/mongod.conf（Linux apt/yum）、/usr/local/etc/mongod.conf（macOS Intel）
角色必须绑定到具体数据库，且作用域不可跨库隐式继承
MongoDB 的角色是「数据库级」概念，readWrite 在 admin 库和在 myapp 库是两个完全独立的权限集合。不存在“全局 readWrite”这种角色。
- 内置角色如
root、clusterAdmin只在admin数据库下有效，创建时必须指定db: "admin" - 对业务库授权，必须显式切换到目标库再创建用户，例如：先
use myapp，再db.createUser({user:"appuser", roles:["readWrite"]}) - 一个用户可在多个库拥有不同角色，但需分别调用
db.grantRolesToUser()，不能一次性跨库赋权
分片集群中用户应优先在 mongos 上创建，而非直连分片
在分片集群中，用户元数据默认只存于 config server 的 admin 库，mongos 是唯一能统一解析和路由权限检查的入口。直连某个 mongod 分片创建的用户，其角色仅对该分片本地生效，其他分片不可见，极易导致权限不一致。
- 正确做法：用
mongosh --host mongos-host:27017 -u admin -p --authenticationDatabase admin连接mongos，然后执行用户操作 - 例外场景：仅当执行分片维护（如
moveChunk）时，才需直连特定分片，并以该分片的本地管理员身份认证（即该分片admin库下的用户） - 注意：分片本地用户无法通过
mongos认证，因为mongos不查分片的本地admin用户表
SCRAM-SHA-256 是 MongoDB 7.0 默认且唯一推荐的密码机制
MongoDB 7.0 已彻底弃用 SCRAM-SHA-1 和更早的 MONGODB-CR，新用户只能使用 SCRAM-SHA-256；旧机制用户升级后需重置密码才能启用新机制。
- 创建用户时无需指定机制，
mongosh默认使用SCRAM-SHA-256；若显式指定，必须写mechanisms: ["SCRAM-SHA-256"] - 旧版用户迁移：连接后运行
db.updateUser("olduser", {pwd: "newpass"})即可自动升级凭证存储格式 - 驱动连接字符串中无需加
authMechanism=SCRAM-SHA-256（除非服务端显式禁用了默认机制），但建议显式声明以避免兼容性歧义
最容易被忽略的是：即使所有配置都正确，如果 mongod 启动时未加载配置文件（比如忘了加 --config /etc/mongod.conf），或 systemd 服务 Unit 文件里没写 ExecStart=... --config ...，security.authorization 设置根本不会被读取——此时看起来一切正常，但权限形同虚设。
