菜单数据由后端根据用户角色动态生成，需在服务层完成权限校验，通过 permission_code 关联菜单与路由权限，并缓存 menulist 避免重复查询。
菜单数据从哪来：权限校验必须在服务层完成
后台菜单不是前端写死的，也不是靠 JS 拼出来的——它得由后端根据当前用户角色动态生成。关键点在于：getMenuList() 这类方法不能只查数据库，必须嵌入权限判断逻辑，比如检查用户是否拥有 admin:article:list 这类权限标识。
常见错误是把权限过滤放在模板里用 {if $auth->check('...')} 包裹菜单项，这会导致菜单结构暴露、权限绕过风险高，且无法控制子菜单的可见性层级。
- 正确做法：在控制器或服务类中调用
Auth::getInstance()->getAllowedMenus()，返回已过滤的完整菜单树（含 icon、url、children） - 菜单表建议带
permission_code字段，和权限规则表一对一或一对多关联 - 注意缓存：用户菜单可按
user_id + role_id组合缓存，避免每次请求都查库
ThinkPHP 视图里怎么安全渲染菜单：别用 assign + foreach 硬塞
直接 $this->assign('menuList', $menuList) 再在模板里 {volist name="menuList"} 是最常见写法，但容易漏掉递归渲染逻辑，导致二级菜单不显示或无限嵌套报错。
更稳妥的方式是封装一个视图函数或使用 ThinkPHP 的 widget 机制，把菜单渲染逻辑抽离成独立模板片段，例如 menu_tree.html，并在其中做深度限制和空 children 处理。
- 递归模板里必须加
{if $depth lt 3}防止菜单层级失控 - 每个菜单项的
url字段应已通过url()函数生成，避免前端拼接出错 - 不要在模板里调用
Auth::check()，所有权限判定必须前置到 PHP 层
菜单权限与路由权限不一致怎么办：统一用 permission_code 对齐
经常遇到的情况是：菜单显示了「订单管理」，但点击进去提示「无权限」——这是因为菜单的 permission_code 和控制器方法上定义的权限标识不一致，比如菜单写的是 order:list，而控制器用的是 order.view。
根本解法是建立映射规范：每个菜单项的 permission_code 必须和 @Auth('order:list') 注解、或中间件参数中的权限码完全一致。
- 推荐在
config/auth.php中定义菜单权限白名单，用于开发期校验 - 调试时可 dump
Auth::getPermissions($userId)，确认当前用户实际拥有的权限码集合 - 路由分组绑定权限时，避免用通配符如
order/*，ThinkPHP 的Auth类默认不支持路径模糊匹配
性能瓶颈在哪：菜单查询慢、渲染卡顿的典型原因
菜单加载变慢，90% 不是因为 SQL 慢，而是因为没控制好关联查询和重复实例化。比如在循环中反复 new Auth 类、或对每个菜单项都查一次权限状态。
真实项目中，菜单数据量通常不大（
- 禁止在
foreach里调用Auth::check()，改用预加载的权限数组 in_array 判断 - 菜单 SQL 尽量单次查出全部数据，用 PHP 构建树形结构，别依赖多次 JOIN
- 开启模板缓存后，仍需确保菜单变量不包含对象实例（如
$auth实例），否则会触发序列化失败
菜单权限这事，表面是“展示什么”，实际是“谁能在哪看到什么”的边界问题。最容易被忽略的，是菜单结构本身成了权限漏洞的入口——比如隐藏了菜单但没关掉对应接口，或者菜单字段里混进了未脱敏的内部标识。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
