html标签不承载权限逻辑，权限控制必须由后端在每次请求中校验并过滤数据；hidden和display: none仅隐藏视觉呈现，无法阻止用户通过devtools或脚本绕过，真正安全需后端资源级校验与前端data-permission集中管理。
HTML标签本身不承载权限逻辑，显隐控制只是前端对后端权限决策的被动呈现；任何靠hidden、disabled或CSS隐藏实现的“权限”都可被绕过，结构安全的核心在于后端是否在每次请求中校验权限并过滤数据。
为什么hidden和display: none不能用于权限隔离
二者本质相同：仅移除视觉呈现，DOM节点仍在内存中，用户可通过DevTools直接删除hidden属性、修改style.display，或用document.querySelector取到元素并调用.click()触发行为。更危险的是，这类操作常伴随错误假设——“按钮没了，功能就不可用了”，而真实接口如POST /api/users/delete仍可能被curl直连成功。
-
hidden语义上等价于aria-hidden="true"，但不阻止键盘焦点或脚本访问 -
visibility: hidden保留布局空间，适合避免页面跳动，但同样不安全 - 若需彻底移除权限无关节点，应调用
element.remove()，而非仅设样式
data-permission属性如何避免硬编码权限判断
把权限标识从JS逻辑里抽出来，统一挂载到DOM上，能减少散落的if (user.role === 'admin')判断。例如：<button data-permission="order:refund">退款</button>，再用一个集中函数遍历所有[data-permission]节点，比对后端返回的user.permissions数组决定是否保留或禁用。
- 权限变更时（如切换角色），只需重跑该函数，无需重载页面
- 避免用
data-role="admin"这类模糊字段，优先用细粒度动作码，如"user:edit"而非"role: admin" - 非表单元素（如
<div>）不支持<code>disabled，此时应设aria-disabled="true"并手动拦截click和keydown菜单与按钮显隐背后的结构风险
前端渲染菜单或按钮前，必须确认权限数据来自后端响应，而非localStorage或URL参数。常见错误是先渲染UI，再异步拉权限——导致初始状态永远“无权限”，哪怕用户实际有。
- React/Vue中优先用响应式数据驱动，如
{hasPermission('post:publish') && <button></button>}，而非document.getElementById().style.display = 'none' - 若用原生JS操作DOM，确保权限校验逻辑在
fetch('/api/me').then(...)resolve后才执行 - 后端返回的权限字段应为布尔值或动作数组，如
{"editable": false, "actions": ["view", "print"]}，前端据此决定是否插入delete按钮
最易被忽略的点不是按钮要不要显示，而是后端是否在每个接口里做了资源级校验——比如
GET /api/orders/123返回了订单详情，不代表用户有权查看其中的customer_phone字段，这个字段必须由后端从响应JSON中剔除，而不是靠前端v-if="showPhone"控制。结构安全从来不是HTML的事，是每次HTTP响应是否干净的事。 - React/Vue中优先用响应式数据驱动，如
