HTML标签属性无法实现真正权限校验，前端disabled、readonly、hidden等仅是UI提示，data-permission等自定义属性不参与提交且可被篡改，服务端必须基于用户身份与上下文逐字段校验权限。
HTML标签属性本身不能实现真正的权限校验，任何基于disabled、readonly、hidden或style="display:none"的前端控制都可被绕过，服务器端必须重新验证所有字段的可写性与上下文条件。
为什么data-permission这类自定义属性不构成权限控制
开发者常在表单字段上加data-permission="can_edit_title"，再用JS控制显隐或禁用状态。这仅是UI同步手段，不是安全机制。
- 攻击者可直接在DevTools中删除
disabled属性或修改data-permission值，然后提交任意字段 -
data-属性不参与表单提交，无法作为后端决策依据；它只是前端逻辑的“便签”，不是凭证 - 浏览器原生验证（如
required）可被JS覆盖，且不校验业务语义（例如“编辑者不能改发布时间”）
disabled和hidden字段在提交时的行为差异
二者视觉效果相似，但对表单数据流的影响完全不同，误用会导致后端收不到关键字段或收到非法字段。
-
disabled字段：不会出现在FormData中，也不会被form.elements枚举，提交时自动被忽略 -
type="hidden"字段：始终提交，无论是否被JS修改、是否在DOM中可见，只要在<form>内且有name就会上送 -
style="display:none"的普通输入框：仍会提交，且能被JS读写、被无障碍工具识别，但缺乏语义——它既不是禁用，也不是隐藏域
服务端如何校验前端传来的字段权限
后端不能信任任何前端传来的“权限标识”，而应根据当前用户身份+原始请求上下文，逐字段比对权限策略。
立即学习“前端免费学习笔记（深入）”；
- 检查字段是否在用户角色允许的可写字段白名单中，例如：
if (!allowed_fields.includes(field_name)) { reject() } - 对条件字段（如
invoice_tax_id），必须回溯前置字段（如is_invoice_required === "true"）再判断是否允许提交 - 禁止仅靠
isset($_POST['admin_note'])做判断，而要验证user.role === 'admin'且该操作在当前流程中被授权 - 敏感字段（如
user_role、is_active）应从不接受客户端输入，只由后端根据策略生成
真正起作用的权限校验永远发生在服务端，前端的所有属性操作只是降低误操作概率的辅助手段；一旦把data-属性、disabled或CSS隐藏当成防线，就等于把门锁换成了贴纸。
