dbOwner 是 readWrite、dbAdmin 和 userAdmin 的并集，可读写数据、管理数据库结构（如建删索引/集合）及用户（如创建/删除用户），但仅限指定数据库；readWrite 仅支持数据操作和简单集合管理，不包含结构或用户管理权限。
readWrite 和 dbOwner 都能对数据库做增删改查，但权限范围和能力完全不同——dbOwner 不只是“读写更强”，而是多了两层关键能力：管理数据库结构（如建索引、删集合）和管理用户（如创建、删除其他用户）。仅用 readWrite 的用户连自己数据库里的索引都删不了。
readWrite 角色只能操作数据，不能碰数据库结构或用户
readWrite 确实允许 insert / update / delete / find / createCollection / renameCollectionSameDB，但它不包含以下任何操作：
-
createIndex、dropIndex、dropCollection（这些属于dbAdmin范畴） -
createUser、dropUser、updateUser（这些属于userAdmin范畴） - 访问
system.profile或执行collStats等统计命令（部分需dbAdmin）
典型场景：应用连接账号、ETL 工具写入账号。它不该也不需要管理权限。
dbOwner 是 readWrite + dbAdmin + userAdmin 的组合体
dbOwner 不是“超级读写”，而是三个角色的并集，意味着它能：
- 读写任意非系统集合（来自
readWrite） - 创建/删除索引、集合、视图；运行
db.stats()、collStats（来自dbAdmin） - 在当前数据库中调用
db.createUser()、db.dropUser()、db.grantRolesToUser()（来自userAdmin）
注意：dbOwner 权限只作用于**指定数据库**，比如 {role: "dbOwner", db: "app"} 对 admin 或 config 库完全无效。
容易踩的坑：误以为 dbOwner 可跨库或等同 root
常见错误包括：
- 给开发人员分配
dbOwner到业务库，结果他顺手在admin库里执行db.createUser()——失败，因为dbOwner不自动授予admin库权限 - 以为
dbOwner能备份或重启服务 ——不能，backup、clusterAdmin是独立角色 - 用
dbOwner创建用户后，没显式赋予该用户对应库的readWrite或其它角色 ——新用户仍无数据访问权，角色必须显式声明
真正需要 dbOwner 的人极少：通常是 DBA 或部署脚本初始化阶段。日常应用账号坚持用 readWrite，管理操作走单独高权账号。
什么时候该选哪个？看操作目标是否超出数据CRUD
判断很简单：
- 只要涉及
createIndex、dropCollection、db.stats()→ 必须dbAdmin或更高（如dbOwner） - 只要涉及
db.createUser()、db.grantRolesToUser()→ 必须userAdmin或更高 - 只做查询、插入、更新、删除、简单建集合 →
readWrite足够，且更安全
别因为“以后可能要加索引”就提前给 dbOwner。权限最小化不是教条，是防止误操作的第一道隔离墙。
