HTML标签的显隐逻辑不构成安全边界，权限决策必须由后端控制并通过结构化数据同步至前端；hidden和display:none仅影响呈现，无法阻止用户绕过；disabled仅对原生表单控件有效且具备语义与无障碍优势；应统一用data-permission标记+集中校验函数实现可维护权限控制。
HTML 标签的显隐逻辑本身不承载权限，hidden、disabled、style="display: none" 都只是前端视觉或交互层的“粉饰”，不能构成任何安全边界。真正的权限决策必须来自后端，并通过结构化数据（如 permissions 数组）同步到前端，再由 JS 驱动 DOM 变更。
为什么 hidden 不等于权限控制
hidden 是 HTML5 原生布尔属性，浏览器会跳过渲染、暂停媒体、卸载 iframe、忽略读屏器朗读——但它依然存在于 DOM 中，用户打开 DevTools 删除该属性，或直接发请求，就能绕过所有限制。
- 它和
style="display: none"一样，只影响呈现，不阻断逻辑执行 - 服务端未校验
POST /api/users/delete的权限，前端隐藏按钮毫无意义 - 若后端返回的权限数据是空数组或过期缓存，
hidden会错误地隐藏本该显示的内容
disabled 在表单控件中的真实行为边界
disabled 是唯一被表单序列化自动排除的原生属性，对 <button></button>、<input>、<select></select> 等有效，但对 <div> 或自定义组件无效。
<ul>
<li>键盘用户按 Enter 触发 <code>disabled 按钮？不会——这是它比 pointer-events: none 更可靠的核心原因
disabled 元素不会获得焦点，也不会响应 click 或 keydown，语义正确且无障碍友好aria-disabled="true" + 手动拦截事件，不能仅靠 CSS 灰色样式模拟data-permission + 权限映射函数才是可维护的关键
把权限判断硬编码在每个按钮里（如 if (user.role === 'admin') {...}），会导致散落、难测试、易漏更新。应统一用 data-permission 标记节点，再集中校验。
立即学习“前端免费学习笔记（深入）”；
- 标记示例：
<button data-permission="user:delete">删除</button> - 校验函数接收权限标识符，遍历角色映射表（如
rolePermissions.editor），返回布尔值 - 权限变更后必须显式调用校验函数，而非依赖组件挂载或定时轮询——异步加载完成才是触发时机
- 避免反复操作 DOM：先收集所有
[data-permission]节点，再批量设hidden或disabled
最容易被忽略的同步陷阱：DOM 状态 ≠ 权限状态
权限数据从 API 加载完成，但 DOM 控制逻辑在 Promise resolve 前就执行了，结果就是初始渲染永远“无权限”。这不是 bug，是数据流断裂。
更隐蔽的是多角色场景下，user.roles = ['editor', 'reviewer'] 更新了，但旧的 allPerms Set 对象没重建，导致新权限不生效。权限映射必须每次调用都基于最新数据计算，不能缓存在闭包里。
