前端无法真正控制权限，所有权限逻辑必须由服务端决定并下发；HTML仅负责渲染服务端已过滤的内容，权限字段需在首屏由后端注入，DOM元素用data-permission标记，菜单/路由/接口均须服务端动态返回并逐请求鉴权。
前端无法真正控制权限，所有「按角色展示」的逻辑必须由服务端决定并下发，HTML 只负责渲染结果；你看到的“动态内容”其实是服务端已过滤后的 HTML 片段或 JSON 数据，不是浏览器自己算出来的。
服务端必须返回结构化权限上下文，而不是靠 JS 猜角色
常见错误是前端读 localStorage.getItem("role") 或解析 URL 路径来判断权限，这完全不可信——用户打开 DevTools 一行代码就能改掉。正确做法是：页面首次加载时，后端模板（如 Jinja2、EJS）或首屏 API 响应中注入明确的权限字段：
{ "permissions": ["document:read", "document:edit", "comment:delete"], "role": "editor" }
之后所有显隐、禁用、跳转逻辑都只查这个对象，不查 DOM、不查 URL、不查本地存储。别用 role === "admin" 这种硬编码判断，角色可能被动态调整，且 JWT 中的 role 字段也可能被篡改。
data-permission 是唯一安全的 DOM 标记方式
给需要受控的元素统一加 data-permission 属性，值为标准权限码（如 document:edit），不要用 class、id 或自定义 role 属性——它们没有语义，也无法被系统性扫描和校验：
张三 - API 密钥管理
然后用 JS 批量处理：
document.querySelectorAll("[data-permission]").forEach(el => {
const perm = el.dataset.permission;
if (!window.USER_PERMS?.permissions?.includes(perm)) {
el.style.display = "none";
el.required = false;
el.tabIndex = -1;
el.setAttribute("aria-hidden", "true");
}
});
注意：display: none 仅用于视觉隐藏，不能替代服务端鉴权；表单字段还需同步控制 required、tabIndex 和 aria-hidden，否则会破坏可访问性和表单提交逻辑。
菜单和表格列必须由后端返回，不能前端拼接再隐藏
菜单项、表格列、操作按钮这些结构性内容，绝不能先全量渲染再用 JS 遍历隐藏——那会导致源码里仍存在无权访问的链接和数据，SEO 污染、爬虫误抓、屏幕阅读器可读，且测试路径遗漏风险极高。
正确流程是：
- 登录后请求
/api/user/menu或/api/user/columns，后端根据角色+部门+数据范围策略，只返回当前用户「真正能看的」菜单数组或列配置 - 前端用该数据驱动渲染，比如 Vue 的
v-if="hasPermission(item.perm)"，或纯 JS 的menuItems.map(renderMenuItem) - 路由跳转前必须走守卫校验，哪怕菜单没显示该入口，用户仍可能手输 URL —— 守卫函数必须调用真实权限检查，不能只依赖路由 path
权限码建议用冒号分隔的层级格式（如 menu:order:detail），方便支持前缀匹配：permissions.some(p => p.startsWith("menu:order"))。
所有敏感操作接口必须逐请求鉴权，前端禁用只是防误点
即使按钮被隐藏、菜单被过滤、输入框被禁用，只要后端接口没做校验，攻击者用 curl 或 Postman 仍能直接调用成功。最常被忽略的一点是：
- 只校验
GET /api/users，却放行POST /api/users/delete - 只校验请求路径，不校验 body 中的
target_id是否属于当前用户 - 把前端传来的
permission_flag=true当作判断依据
真正有效的鉴权必须每次请求都执行类似这样的逻辑：
if (!has_permission(req.user, "user:delete")) { return 403; }
前端的任何控制，都只是体验层的安全降级，不是防线。复杂点在于：权限可能随数据范围动态变化（如“只能删自己创建的文档”），这种场景下，服务端鉴权必须结合资源 owner 字段做二次校验，不能只查用户角色列表。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
