mongodb不支持字段级更新权限控制，其最小权限单位为集合级别，授予update权限即允许修改任意字段；替代方案需依赖应用层校验、聚合管道约束或atlas变更流干预。
MongoDB 不支持字段级更新权限控制
MongoDB 原生不提供“只允许更新 status 字段，禁止修改 created_at”这类字段粒度的权限机制。它的最小权限单位是集合（collection）级别，动作粒度止于 update、find、insert 等——一旦授予 update 权限，用户就能用 $set、$unset、$inc 等任意合法操作符修改该集合中任意字段。
替代方案：靠应用层或聚合管道拦截
真要约束字段更新行为，得绕过权限系统，在业务逻辑或数据库操作链路上设防：
- 应用层校验：在写入前检查
update操作的$set文档，拒绝含敏感字段（如role、balance）的请求 - 使用
db.collection.updateOne()+ 聚合管道（MongoDB 4.2+）：把字段更新逻辑写进 pipeline，避免直接暴露原始 update 操作符。例如只允许将status从"pending"改为"confirmed"，其他变更被 pipeline 过滤掉 - 触发器（仅 Atlas）：MongoDB Atlas 支持变更流 + Functions，可监听
update事件，发现非法字段修改时主动回滚或告警——但这不是权限控制，是事后干预
为什么不能靠 db.createRole() 加 resource 过滤？
因为 resource 字段只接受 { db: "...", collection: "..." } 结构，不支持嵌套字段路径（如 { field: "status" }）。你无法在 privileges.actions 中指定 “仅允许 update 且 $set.status”。尝试在 actions 里写 ["update"] 就是全量更新权限，写 ["find"] 则连读都不让——没有中间态。
常见误操作是以为加了 collation 或 hint 能限制字段，但这些是查询优化参数，和权限无关；也有人想用 authenticationRestrictions 锁 IP，但它管的是连接来源，不是数据字段。
最接近的“软限制”：用部分索引 + 唯一性兜底
对关键字段（如 user_id、tenant_id）建唯一部分索引，并配合应用逻辑强制其不可变：
db.users.createIndex(
{ user_id: 1 },
{ unique: true, partialFilterExpression: { user_id: { $exists: true } } }
)
虽然不能阻止 $set: { user_id: "new" }，但若该值已存在，会因唯一索引冲突报错 E11000 duplicate key。这属于数据一致性防护，不是权限控制，且依赖字段值本身有业务唯一性。
真正需要字段级写保护的场景，说明业务敏感度已超出 MongoDB 的权限模型设计边界——这时候该考虑是否用带行/列级策略的数据库（如 PostgreSQL RLS），或在服务层加强鉴权网关。
