权限菜单控制的核心是数据驱动视图，即根据用户权限动态筛选菜单项并返回树形结构供前端渲染，而非硬编码判断或用@PreAuthorize控制显示。
权限菜单控制的核心是“数据驱动视图”而非硬编码判断
Java 后端本身不直接渲染菜单，所谓“菜单控制”本质是：根据当前用户角色/权限，动态筛选出其可见的菜单项（通常是 Menu 对象列表），再交给前端渲染。关键不在 if-else 套流程，而在权限数据如何建模、如何查询、如何与菜单结构对齐。
常见错误是把菜单配置写死在代码里，或用一堆 if (hasRole("ADMIN")) 拼字符串生成 HTML —— 这无法维护，也不支持运行时调整。
- 菜单数据建议存数据库，字段至少包含：
id、name、path、component、parent_id、permission_code（如"menu:user:list"） - 用户权限应关联到具体资源操作粒度（如
"user:read"），而非仅角色名；角色只是权限的集合容器 - 后端接口（如
GET /api/menus）返回的是已过滤的树形结构，不是全量菜单再让前端筛
Spring Security + RBAC 实现菜单动态加载的关键三步
用 Spring Security 做权限校验，但菜单组装要独立于 SecurityContext 的 HTTP 请求链路 —— 它是数据服务，不是拦截逻辑。
典型实现路径：
立即学习“Java免费学习笔记（深入）”；
- 定义
MenuService，提供findVisibleMenusByUserId(Long userId)方法，内部查用户所有权限码（permission_code），再关联查出匹配的菜单项 - 菜单表加
permission_code字段，与权限表（sys_permission）通过中间表或直接外键关联；避免用角色名做菜单开关，否则改角色就得改菜单 SQL - 返回前用递归或
Stream+Map构建树：先查出所有有效菜单，再按parent_id归组，根节点parent_id = null或0
示例片段（简化）：
List<Menu> allMenus = menuMapper.selectByPermissionCodes(permissionCodes);
Map<Long, List<Menu>> childrenMap = allMenus.stream()
.filter(m -> m.getParentId() != null)
.collect(Collectors.groupingBy(Menu::getParentId));
前端传参不一致导致菜单为空的典型排查点
后端返回空菜单，90% 不是权限逻辑错，而是前后端约定断裂。重点检查：
- 前端请求
/api/menus时是否携带了有效的Authorization头（如Bearer xxx），且后端SecurityConfig中该路径未被permitAll()或误配成anonymous() - 用户权限数据是否真正入库：检查
sys_user_role、sys_role_permission表是否有对应记录，不要只看角色名是否含 “ADMIN” -
permission_code字段值是否带空格或大小写不一致（如后端存"menu:user"，前端比对用"MENU:USER"） - 菜单表中
status字段是否为启用状态（常见坑：新增菜单忘了设status = 1）
为什么不能用 @PreAuthorize 控制菜单显示
@PreAuthorize 是方法级访问控制，作用于控制器方法执行前，它决定“能不能进这个接口”，不决定“菜单要不要显示”。两者语义不同：
- 用户没有
"order:delete"权限 →@PreAuthorize("hasPermission('order:delete')")可拦住删除接口，但不影响“订单管理”菜单项是否出现在侧边栏 - 菜单显示取决于用户是否有对应菜单的
permission_code（如"menu:order"），这是独立的数据查询逻辑 - 混淆二者会导致：有菜单但点不开（@PreAuthorize 拦了），或没菜单但 API 能直连（权限校验漏了）
真正需要的是两层分离：菜单数据服务负责“画什么”，@PreAuthorize 或自定义 Filter 负责“动什么”。菜单结构本身不该参与运行时鉴权决策。
