ThinkPHP后台菜单必须从数据库动态加载并按用户权限过滤；查出带id/pid/title/url/sort/status字段且status=1的数据，用PHP引用方式组装树形结构，高亮依赖路由名匹配而非URL，权限校验须基于用户ID缓存的白名单预过滤。
ThinkPHP后台菜单不是写死的，必须从数据库动态加载并按用户权限过滤；直接 foreach 渲染一维数据、不校验权限就输出、用 $_SERVER['REQUEST_URI'] 匹配高亮，这三类操作必出问题。
菜单数据怎么从数据库查出来并转成树形结构
查菜单不能只用 Db::name('menu')->select() 拿一维数组——那样父子级全混在一起，模板里根本没法递归渲染。必须先组装树，再传给视图。
- 字段至少包含
id、pid、title、url、sort、status，其中pid = 0表示一级菜单 - 查询时加
where('status', 1)，否则禁用菜单也会显示 - 推荐用 PHP 引用方式组装树（避免递归调用和 N+1），关键逻辑类似：
$list = Db::name('menu')->where('status', 1)->order('pid ASC, sort ASC')->select();
$tree = [];
$map = [];
foreach ($list as $item) {
$map[$item['id']] = $item;
if (!$item['pid']) {
$tree[] = &$map[$item['id']];
} else {
$map[$item['pid']]['children'][] = &$map[$item['id']];
}
}
别依赖 MySQL 的 WITH RECURSIVE 做层级查询——深层级菜单下容易超时或触发临时表限制。
当前菜单如何正确高亮（active）
高亮不是比对完整 URL，而是匹配路由名（request()->rule()->getName()）。用 $_SERVER['REQUEST_URI'] 或 request()->url() 匹配，会因查询参数、入口文件、多应用前缀导致误判。
立即学习“PHP免费学习笔记（深入）”；
- 菜单
url字段建议存相对路径，如'admin/user/list'，和路由定义严格一致 - 在模板中用
str_starts_with(request()->rule()->getName(), $menu['url'])判断（TP6.1+），或手动strpos()前缀匹配 - 如果菜单是
admin/user，而当前路由是admin/user/detail，前缀匹配会误亮，此时应统一用路由名做精确匹配，而非路径前缀 - 高亮前必须校验权限：即使 URL 匹配，
in_array($menu['id'], $authMenuIds)为 false 就得跳过，否则有越权风险
菜单权限怎么和 RBAC 绑定才不翻车
菜单显隐不是靠前端 JS 隐藏，也不是靠中间件一个个 Auth::check() 判断——那是接口级鉴权，开销大且无法支撑菜单树渲染。
- 权限绑定核心是「白名单预过滤」：登录后查出该用户所有已授权的
menu_id（通过role_menu关联），缓存为键值数组：array_flip($menuIdList) - 渲染前用
isset($authMenuMap[$menu['id']])快速判断，不是in_array() -
auth_rule表必须加type = 'menu'字段区分菜单和操作节点，否则菜单和按钮权限混在一起，分配时无法解耦 - 缓存 key 必须含用户 ID（如
'user_menus_' . $userId），不能只用角色 ID——多个用户同角色但菜单不同，共用缓存会错乱 - 菜单或权限变更后，必须主动清缓存：
Cache::delete('user_menus_' . $userId)，不能等自然过期
为什么改了菜单结构前端还是旧的
不是前端没刷新，是后端缓存 key 没带版本或时间戳，导致新菜单数据被旧缓存覆盖。
-
buildTree()结果必须缓存，但 key 要包含菜单更新时间戳或版本号，例如：'menu_tree_v2_' . date('YmdHi') - 别把整个菜单树塞进 session——session 容量小、易污染、不同设备登录会互相覆盖
- 如果用了
Auth::getRuleList()加载菜单，确认它读的是你重写的缓存逻辑，而不是原生只认roleId的老实现 - 多应用模式下，
url字段值要和当前应用前缀一致，比如 admin 应用下的菜单 url 是'admin/user/list'，不能漏掉admin/，否则跳转 404
