真正的权限控制必须由后端校验，前端仅做条件渲染和降级体验；data-permission应由后端注入，JS据此判断显隐或移除元素；表单提交前须JS校验权限并阻止非法提交；服务端渲染时应直接过滤敏感内容，避免客户端补全。
权限控制不能只靠前端隐藏元素
HTML 本身没有权限概念，display: none 或 disabled 属性只是视觉/交互屏蔽，无法阻止用户通过 DevTools、直接请求或 URL 跳转绕过。真正的权限控制必须由后端校验，前端 HTML 只能做「降级体验」和「条件渲染提示」。
用 data-permission 配合 JS 做最小可行渲染
把权限标识作为属性注入 HTML 元素，避免硬编码逻辑到模板里。服务端在渲染时根据当前用户角色写入 data-permission="admin,editor" 或 data-required-permission="delete-user"，JS 拿到后做判断：
if (!permissions.includes(element.dataset.requiredPermission)) {
element.remove(); // 或 element.classList.add('hidden');
}
-
data-permission应由后端注入，不可由前端拼接字符串伪造 - 不要用
class="admin-only"这类语义模糊的 class 控制显隐——它容易被 CSS 覆盖或误用 - 对表单按钮、操作链接等关键节点，优先用
remove()而非hidden，减少 DOM 干扰
表单提交前必须校验权限，而非仅禁用按钮
禁用按钮（disabled）只是防误点，用户删掉属性就能提交。真正要拦截的是提交动作本身：
<form data-required-permission="update-post"> <button type="submit">保存</button> </form>
监听 submit 事件，检查权限再决定是否 event.preventDefault()：
立即学习“前端免费学习笔记（深入）”；
- 即使按钮是 disabled，也要在 JS 中重复校验——防止用户手动启用后提交
- 错误提示应明确告知“无此操作权限”，而不是静默失败
- 若权限动态变化（如切换角色），需重新绑定事件或使用事件委托
服务端渲染时就该过滤敏感内容，而非留空占位
别在 HTML 里先塞一个 <div id="user-delete-btn"></div>，再靠 JS 插入按钮。这样既增加 JS 依赖，又暴露 DOM 结构。正确做法是：服务端判断无权限，就不输出该元素。
- 模板中用
{% if can_delete_user %}...{% endif %}（Jinja/Twig/Thymeleaf 等） - 如果必须客户端渲染，至少用
<template>包裹备用结构，避免无权限时 DOM 中残留空节点 - 对 SEO 敏感页面（如后台列表页），缺失权限的内容不该出现在初始 HTML 中
权限逻辑分散在模板、JS、CSS 里最容易出错。最稳妥的路径是：后端决定「该不该有」，前端只负责「怎么展示已有的」——其余都是妥协方案。
