权限控制必须以后端接口返回的实时权限数据为准，前端仅做动态渲染与展示逻辑，所有鉴权判断须基于后端下发的 permissions 数组，且服务端必须对每个敏感接口进行权限校验。
权限数据必须从后端接口获取，不能写死在 HTML 或 JS 里
用户权限不是前端能决定的，哪怕你看到某个按钮“没显示”，也不代表它不存在或不可调用。常见错误是把 role === 'admin' 这类判断硬编码进 JS，或者从 localStorage 读一个 "role: editor" 字符串就渲染菜单——这些值全可被用户手动篡改。
正确做法是：页面加载时发起一次 GET /api/me（或类似接口），后端根据 session/JWT/数据库实时查出该用户拥有的权限列表，例如：
{"permissions": ["user:read", "user:edit", "order:delete"], "menus": [{"path":"/users", "name":"用户管理", "permission":"menu:user"}]}
拿到这个响应后，前端才开始渲染。所有后续的显示逻辑，都基于这个数组做判断，而不是靠 URL、cookie 或本地缓存猜。
用 hasPermission() 做细粒度比对，别只用字符串相等
权限码不是非黑即白的开关，比如 "menu:order:detail" 应该能被 hasPermission('menu:order') 匹配到，否则子菜单永远无法展开。单纯用 permissions.includes('menu:order:detail') 会漏掉层级关系。
立即学习“前端免费学习笔记（深入）”；
推荐实现方式：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 精确匹配：直接
permissions.includes(code) - 前缀匹配：用
permissions.some(p => p.startsWith(prefix))，比如判断是否拥有某模块下全部权限 - 通配支持：允许
"menu:order:*"这类写法，需额外解析，但避免后端返回过长列表
别让这个函数依赖全局变量或闭包状态——每次调用都应基于当前已知的权限数组，确保可测试、可复现。
动态渲染菜单和按钮，而不是先全量再隐藏
很多人用 document.getElementById('deleteBtn').style.display = 'none' 隐藏无权按钮，这有三个问题：DOM 仍存在、屏幕阅读器可读、DevTools 一点就恢复。更糟的是，如果用户手敲 curl -X POST /api/users/delete，后端没校验照样执行。
真正安全的做法是：只创建用户有权访问的元素。
- 菜单：遍历后端返回的
menus数组，逐个生成<a></a>或<router-link></router-link>，不满足hasPermission(item.permission)的项直接跳过 - 按钮：在模板中用
v-if="hasPermission('user:delete')"（Vue）或{hasPermission('user:delete') && <button>删除</button>}（React），纯 JS 则用innerHTML拼接或appendChild()动态插入 - 表单字段：同理，权限不足的
<input>根本不加进 DOM，而非加进去再设disabled
display 和 hidden 都不安全，但影响布局不同
hidden 属性和 style="display: none" 本质一样：只是视觉隐藏，不防请求、不防调试、不防绕过。它们唯一区别是布局行为：
-
display: none：元素脱离文档流，周围内容重排，适合彻底移除一块区域 -
visibility: hidden：元素占位但不可见，适合保留空白防止页面跳动（比如权限切换动画） -
hidden：语义等价于visibility: hidden，但兼容性略差（IE 不支持）
重点在于：无论用哪种，都必须基于后端下发的权限数组来决定是否渲染，而不是反过来靠 DOM 状态反推权限。最容易被忽略的一点是——就算按钮、菜单、字段全隐藏了，只要后端接口没做鉴权，攻击者仍能用 Postman 直接调用成功。权限控制的成败，永远取决于服务端那一行 if !has_permission(req.user, 'user:delete') { return 403 }。
