Java基础权限菜单控制实现方法

权限菜单控制的核心是数据驱动视图，即根据用户权限动态筛选菜单项并返回树形结构供前端渲染，而非硬编码判断或用@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 请求链路 —— 它是数据服务，不是拦截逻辑。

典型实现路径：

• 定义 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 负责“动什么”。菜单结构本身不该参与运行时鉴权决策。