disabled使字段不提交且不可交互，readonly允许聚焦复制并正常提交；二者均不能替代后端权限校验，仅用于前端体验一致性。
HTML属性访问控制不是真正的权限控制
直接在HTML里用disabled、hidden或readonly隐藏/禁用元素，不能替代后端权限校验。浏览器端的DOM操作可被任意绕过——用户删掉disabled属性、用DevTools改style.display、甚至直接发请求，都能触发未授权行为。前端属性控制只服务于体验一致性：让界面状态和用户权限“看起来匹配”，而非“保证安全”。
如何用JavaScript动态控制HTML属性与权限映射
核心是把权限标识（如user.permissions数组）和DOM节点绑定，避免硬编码判断逻辑。常见错误是每个按钮都写一遍if (hasPermission('user:delete')) {...}，导致散落、难维护。
- 统一用
data-permission标记需要受控的元素，例如<button data-permission="post:publish">发布</button> - 初始化时遍历所有带
data-permission的节点，检查当前用户是否拥有该权限，再决定设disabled、hidden或移除节点 - 权限变更（如切换角色）时，不重刷整个页面，而是调用同一套函数重新评估这批节点
- 注意
hidden只是视觉隐藏，仍存在于DOM中；若需彻底移除，用remove()而非仅设style.display = 'none'
为什么disabled比pointer-events: none更可靠
用CSS禁用交互看似简单，但存在兼容性与语义问题：pointer-events: none无法阻止键盘焦点、Enter键触发，也不影响表单提交行为；而disabled原生支持表单控件的禁用语义、自动跳过表单序列化、且被屏幕阅读器正确识别。非表单元素（如<div>）不支持disabled，此时应改用aria-disabled="true" + 监听click/keydown手动拦截，而不是依赖CSS。
权限变更后DOM未同步的典型原因
最常被忽略的是异步时机问题：权限数据从API加载完成，但DOM控制逻辑在数据到达前就执行了。结果就是初始渲染永远显示“无权限”状态，哪怕用户实际有权限。
立即学习“前端免费学习笔记（深入）”；
- 确保权限校验逻辑在
user.permissions真正可用后才运行（比如Promise resolve后，而非组件挂载时） - 避免在React/Vue等框架中直接操作DOM；优先用响应式数据驱动，例如Vue的
v-if="hasPermission('xxx')"或React的{hasPermission('xxx') && <Button />} - 如果必须手动操作DOM（如遗留系统），把权限校验封装成函数，并在权限更新后显式调用它，而不是依赖事件监听或定时轮询
