菜单权限系统应以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 过滤，这是典型的安全漏洞。必须在服务端就完成「当前用户可见菜单」的筛选和组装。
