菜单权限系统应以Menu和Permission对象建模，Menu含permissionCode等字段，Permission仅含code和description；菜单展示与接口鉴权分离，服务端按用户permissionCode筛选并构建树形菜单返回，禁止前端过滤或角色名控制。
菜单数据如何用Java对象建模
菜单权限系统的核心是把「菜单」和「权限」抽象成可操作的实体。不能直接用字符串拼接或硬编码路径，否则后期无法做动态加载和RBAC校验。
典型做法是定义两个基础类：Menu 和 Permission，其中 Menu 持有 permissionCode 字段（如 "sys:user:list"），而不是直接存 SQL 或接口 URL。这个 code 是后端鉴权时比对的唯一依据。
-
Menu应包含：id、name、path、component、icon、sort、parentId、permissionCode、visible（是否在菜单栏显示） -
Permission可简化为仅含code和description，用于权限点注册与校验 - 父子菜单靠
parentId关联，前端渲染时递归组装，Java 层用 Map 构建树形结构更轻量，不必强依赖 Tree 实体类
如何在Spring Security中拦截菜单级访问
Spring Security 默认不关心「菜单是否可见」，只管「能否访问接口」。所以菜单展示逻辑和接口鉴权要分开处理：前者由前端根据用户拥有的 permissionCode 列表过滤，后者由 FilterSecurityInterceptor 或 @PreAuthorize 控制。
关键不是给每个菜单 URL 配 antMatchers，而是统一拦截所有 /api/** 请求，再查用户权限集合是否包含当前请求所需的 permissionCode —— 这个 code 通常从 Controller 方法上的自定义注解（如 @RequiresPermission("sys:role:edit")）提取。
立即学习“Java免费学习笔记（深入）”；
- 避免在
WebSecurityConfigurerAdapter（已过时）里写死 URL 权限映射，改用SecurityExpressionRoot扩展表达式，例如hasPermission('sys:menu:delete') - Controller 方法上必须标注对应权限码，否则鉴权失去语义；不要依赖 request.getRequestURI() 去解析菜单，容易被绕过
- 如果用 JWT，把用户全部
permissionCode放入 token payload，避免每次请求查库；但注意 token 大小和刷新成本
前端菜单列表怎么安全地返回给用户
后端不能把全量菜单吐给前端再靠 JS 过滤，这是典型的安全漏洞。必须在服务端就完成「当前用户可见菜单」的筛选和组装。
流程是：查出该用户所有有效的 permissionCode → 关联出对应的 Menu 记录 → 去重、排序、构建成树 → 过滤掉 visible = false 的项 → 返回 JSON。整个过程不暴露无权限菜单的任何字段（包括 id、path、name）。
- 不要用 MyBatis 的
<foreach></foreach>拼 permissionCode IN 查询，易触发 SQL 注入或性能问题；改用SELECT * FROM menu WHERE permission_code IN (:permissionCodes)+@SelectProvider动态构建 - 菜单树构建建议用两次查询：第一次查平铺列表，第二次用 Java Stream + Map 分组递归组装，比数据库自连接更可控
- 若菜单含外链（如 http://xxx.com）或 iframe 页面，需额外校验 domain 白名单，防止 open redirect
为什么不能用角色名直接控制菜单显示
用 hasRole('ADMIN') 控制菜单，短期快，长期崩。一旦出现「运营专员能看用户列表但不能删」「客服主管能看订单但不能导出」这类细粒度需求，角色模型立刻失灵。
真正可维护的方案是「菜单绑定 permissionCode → 用户拥有若干 permissionCode → 菜单展示/接口访问均基于 code 校验」。角色只是 permissionCode 的聚合容器，中间加一层 RolePermission 关系表，支持运行时调整。
- 禁止在 Thymeleaf 模板里写
sec:authorize="hasRole('SALES')"控制菜单 DOM 渲染，这等于把权限逻辑泄露到前端 - 后台管理界面的「菜单配置页」本身也要受权限控制，即只有拥有
"sys:menu:manage"的人才能修改菜单可见性或权限绑定 - permissionCode 命名要有层级感（模块:资源:操作），比如
"report:sales:export"，方便后续按前缀批量授权或审计
菜单权限不是配几个 URL 就完事，它牵扯数据建模、前后端协作边界、token 设计、甚至审计日志埋点。最容易被跳过的其实是「permissionCode 的全生命周期管理」—— 新增菜单时忘了加 code，上线后发现权限失效，又不敢动老 code，最后只能打补丁。
