object field voter 通过将权限判断下沉至对象实例+字段级别，解决传统 voter 仅支持对象级权限、无法区分“编辑整篇文章”与“仅编辑 title 字段”的粗粒度问题。
权限粒度太粗，本质是把“能操作某类资源”和“能操作某个具体资源的某个字段”混为一谈。Object Field Voter 法不是新模型，而是对 Voter 机制的精准落地——它把权限判断下沉到对象实例 + 字段级别，比如“用户 A 可以编辑文章 title 字段，但不能改 status 字段”，而不是笼统地判“能否编辑这篇文章”。
为什么传统 Voter 还不够细？
标准 Voter（如 Symfony 的 AbstractVoter）通常只接收 object 和 attribute 两个参数。attribute 常被用作操作名（如 "edit", "delete"），object 是整个实体。这就天然缺失字段维度：你无法区分“编辑整篇文章”和“仅编辑其中的 slug 字段”。一旦业务要求字段级隔离（如 HR 系统中普通员工可看姓名、不可看薪资），纯 object-level Voter 就会失效。
Object Field Voter 的核心改造点
关键不在新增框架，而在扩展传参方式和判断逻辑：
- 在调用 is_granted() 时，把字段名作为 attribute 的一部分，例如：
is_granted('EDIT_FIELD', [$post, 'title'])或is_granted('EDIT.title', $post) - Voter 的 supports() 需识别带点号或结构化 attribute，例如匹配
^EDIT\.[a-z_]+$，避免误判其他权限 - voteOnAttribute() 中解构 attribute，提取字段名，并结合 object 实例做字段级校验：当前用户是否拥有该字段的写权限？该字段是否处于可编辑状态（如 status != 'published'）？
- 字段权限规则建议集中管理，例如定义一个
FieldPermissionMap配置数组，按 class + field + role 映射可操作性，避免硬编码散落各处
搭配数据层做字段可见性控制
权限判断只是前半程；后半程要防止越权读取。Object Field Voter 不负责返回数据，但它可与序列化器/查询构建器联动：
- 控制器中调用
is_granted('VIEW_FIELD', [$user, 'salary'])后，再决定是否将 salary 字段加入 API 响应 - DQL 查询中动态 select 字段：若用户无 VIEW.salary 权限，则自动剔除 salary 字段，而非靠应用层过滤
- 前端渲染前也应复用相同规则（通过 API 返回字段白名单或前端权限配置），避免仅靠隐藏 DOM 元素造成信息泄露
别忘了兜底与可观测性
字段级权限逻辑变多，出错风险上升。建议：
- 所有字段权限检查失败时，统一记录 audit 日志，包含 user_id、object_class、field、attribute、拒绝原因
- 开发环境开启权限调试模式，输出每次 Voter 决策路径（谁调了、传了什么、supports 返回 true/false、最终票数）
- 避免在 Voter 中做耗时操作（如查关联表、远程调用），字段权限规则尽量预加载或缓存
