MongoDB原生不支持字段级更新权限，最小粒度为集合级；可行方案包括：1.应用层校验字段白名单后调用update；2.硬编码排除敏感字段；3.精确拼接$set路径；禁用system.users自定义字段；注意连接池权限缓存需重连生效。
MongoDB 原生不支持字段级更新权限
MongoDB 没有内置机制能直接限制用户“只能 update 字段 A，不能改字段 B”。update 权限粒度最小是集合级——一旦授予 update 动作，用户就能在该集合上执行任意字段修改（只要文档匹配查询条件）。所谓“只改 status 不改 email”，靠数据库权限模型本身无法实现。
真正可行的替代方案只有三种
绕不开权限模型限制，就得在应用层或服务层补位。常见做法：
- 用
db.createRole()定义角色时，**不给update，只给find和insert**，把所有修改逻辑收归后端 API —— 由服务校验字段白名单后再调用db.collection.updateOne() - 在应用代码里硬编码字段过滤：比如 Spring Data MongoDB 中用
Update.update("status", "done").set("updatedBy", null)，显式排除敏感字段；或用@PreUpdate拦截实体变更 - 借助 MongoDB 的
$set+ 字段路径精确控制：写业务逻辑时只拼接允许更新的字段路径（如{"$set": {"status": "closed", "updatedAt": ISODate()}}），绝不用{"$set": doc}全量覆盖
别碰 system.users 直接写权限字段
有人想通过 db.runCommand({update: "system.users", ...}) 在用户文档里塞自定义字段标记“可更新字段”，这是错的。MongoDB 不读取这些字段，也不会据此拦截操作；反而可能因格式错误导致认证失败。权限判定只认 roles 数组里的标准 privilege，其他字段纯属冗余。
最容易被忽略的坑：应用连接复用导致权限失效
即使你改好了用户角色、也验证过 db.orders.updateOne({id:1}, {$set:{status:"ok"}}) 成功而 {$set:{email:"x"}} 被拒，只要应用用的是长连接池（比如 Spring Boot 默认的 MongoTemplate），旧连接仍持有旧权限缓存。必须重启服务、或让连接池主动断连重鉴权，否则新权限根本不起作用。
