1. 点击跳转只是三行代码，真正难啃的是“回来之后还认得路”
先说一个我见过很多次的现象：有人在 Nuxt 项目里接了 Ant Design Vue，<a-menu>的点击跳转二十分钟就写完了，然后在群里问“为什么刷新页面菜单就全灭了”。这件事有意思的地方在于，出问题的从来不是点击那一瞬间，而是页面重新加载、用户直接粘贴深链接、或者从别的页面返回时，菜单能不能自己“认出”当前在哪。<a-menu>配合路由使用这件事，真正的技术含量集中在状态由谁持有、由谁推导上，点击跳转反而是最不值钱的部分。
这篇内容讲的就是 Nuxt 环境下a-menu和路由绑定的完整做法，覆盖 Nuxt 3 + ant-design-vue 4 和 Nuxt 2 + ant-design-vue 1.x 两套写法，重点解决三件事：点菜单跳对应路由、刷新或切换页面后自动选中高亮、多级菜单的父级自动展开。适合已经能把菜单渲染出来、但高亮状态总是对不上的朋友，也适合刚开始做后台布局、想一次性把结构设计对的人。前置要求不高，会用 Nuxt 的路由、知道 Vue 的 computed 和 watch 就够，剩下的边看边抄。
有一点必须提前说清楚：菜单高亮看着像样式问题，本质是受控组件的状态同步问题。你把它当 CSS 去调，永远调不明白；你把它当状态去管，代码量反而很少。
1.1 为什么菜单高亮不是 CSS 问题
很多人第一反应是找.ant-menu-item-selected这个类名，想用路由的router-link-active或者自定义 class 去覆盖它。这条路走不通，原因是<a-menu>的选中态不是靠 CSS 类名驱动的，而是靠组件内部维护的selectedKeys数组。你手动加一个 class，视觉上可能变蓝了，但组件内部状态没变，一旦发生重新渲染（比如窗口 resize、菜单折叠、数据更新），高亮立刻被打回原形。更麻烦的是父级子菜单的展开态openKeys，它同样是组件内部状态，纯 CSS 根本控制不到。
所以正确的切入点是把selectedKeys当成一个从路由派生出来的只读数据，把openKeys当成半受控数据（路由决定一部分，用户手动操作决定另一部分）。这个心智模型建立起来之后，后面所有的坑都好解释了。我在带人的时候通常会让对方先回答一个问题：现在菜单高亮的那一项，它的值是从哪里来的？如果答案是“用户点击时我 set 进去的”，那刷新必然丢；如果答案是“从当前路由算出来的”，那刷新天然就对。
1.2 受控组件才是这套东西的核心心智模型
Ant Design Vue 的 Menu 在传入selectedKeys之后就是完全受控的，组件自己不会去改这个值，你给什么它显示什么。它会在点击时 emit 一个update:selectedKeys事件，但你不接，它就当没发生。这一点和很多人对表单组件的直觉不一样——输入框你不接 v-model 它还能自己输入，菜单不行。
这个特性其实帮了大忙。因为完全受控意味着唯一的数据源可以是你指定的任何东西，那我们指定路由就好了，用户点击触发的更新事件直接忽略，让路由变化去驱动选中态。这样就形成了单向数据流：用户点击 → 路由变化 → selectedKeys 重新计算 → 菜单高亮。整个链路上只有路由一个真相来源，刷新、前进后退、程序内跳转，全都自动对齐。后面所有的代码都是围绕这条单向链路展开的。
2. 先定 key 的语义：selectedKeys 里到底该放什么
动手写组件之前，有一个决定比代码本身更重要：菜单项的key到底存什么。这个决定一旦做错，后面每加一个页面都要打补丁。我见过用自增 id 当 key 的、用菜单名称当 key 的、用组件名当 key 的，最后无一例外都在“刷新后怎么根据路由反推出 key”这一步卡住，因为路由里根本没有这些信息，只能再维护一张映射表，越写越重。
最省事的选择是让key直接等于路由的path，这样从路由反推 key 就是一次取值，零成本。但这个方案不是没有代价，遇到动态路由、详情页、带参数的路径时会失效，需要配合兜底策略。下面把三种情况拆开讲，你按自己项目的复杂度选用。
2.1 直接拿 path 当 key 的便利与代价
key等于path的写法，收益非常直接：selectedKeys = [route.path]，一行搞定，不需要任何查找逻辑；菜单配置和路由配置天然一一对应，改一个路径两边同时生效，不会出现“菜单跳 404”的尴尬；新增页面时只要在菜单数组里加一项，不用额外登记。
代价也很明确。第一，route.path在 Nuxt 里可能带尾斜杠，取决于trailingSlash配置，/system/user/和/system/user在字符串比较时是两个值，会漏匹配。第二，动态路由/order/:id实际路径是/order/10086，而菜单项的 key 只可能是/order，永远对不上。第三，如果一个页面被多个入口复用（比如列表页和详情页共用一个高亮父级），单靠 path 无法表达“我属于哪个菜单”。
第一和第三个问题好解决，第二个问题绕不过去，必须引入 meta 或者前缀匹配。我的建议是：项目里没有动态路由的，直接用 path 当 key，别过度设计；有的，从一开始就把 meta 兜底方案一起加上，省得后面返工。
2.2 路由 meta 上挂 activeMenu 的兜底设计
思路很朴素：在页面路由上声明“我这一页应该点亮哪个菜单”，菜单组件优先读这个声明，读不到再回退到 path。Nuxt 3 的definePageMeta可以直接写：
// pages/order/[id].vue definePageMeta({ activeMenu: '/order' })菜单组件里这样取：
const selectedKey = computed(() => { const fromMeta = route.meta.activeMenu as string | undefined return fromMeta || route.path })这样详情页/order/10086打开时，菜单依然高亮在“订单管理”上。这套机制的好处是可扩展——将来做权限菜单时，同一个activeMenu还能用来标识“这一页归属哪个一级模块”，一个字段两用。
需要注意的是，definePageMeta是编译期宏，只能写静态值，不能写表达式或者引用外部变量。如果activeMenu需要动态计算（比如根据用户角色不同挂到不同父级），就只能在运行时通过别的方式注入，这部分超出本文范围，但心里要有数。
2.3 动态参数路由与详情页的最长前缀匹配
activeMenu需要手写，页面一多容易漏。作为兜底，可以再加一层最长前缀匹配：把所有菜单 key 摊平成一个数组，找当前路径能匹配上的最长那个。这样即使忘了写activeMenu，详情页也能自动落到最近的父级菜单上，不至于全灭。
function flattenKeys(items: any[], out: string[] = []): string[] { for (const item of items) { if (item.key) out.push(String(item.key)) if (item.children) flattenKeys(item.children, out) } return out } const selectedKey = computed(() => { const metaKey = route.meta.activeMenu as string | undefined if (metaKey) return metaKey const allKeys = flattenKeys(menuItems) let best = '' for (const k of allKeys) { if (route.path === k || route.path.startsWith(k + '/')) { if (k.length > best.length) best = k } } return best || route.path })这里的k + '/'是关键细节。如果只写startsWith(k)，那么/user-center会被/user匹配到，高亮错位置。加上斜杠之后，/user-center不满足/user/的前缀条件，就被排除了。这种边界情况在小项目里几乎不会遇到，页面一多、命名一随意，立刻就会撞上，而且现象很诡异——某个页面总是高亮在隔壁菜单上，查半天以为是缓存问题。
提示：前缀匹配的顺序会影响结果，
best.length的比较不能省。如果菜单里有/system和/system/log两个 key，访问/system/log/login时两个都能匹配，必须取更长的那个。
3. Nuxt 3 配 ant-design-vue 4 的完整落地
环境这块简单带过，重点在组件写法。先说清楚一个前提：本文的写法基于 Vue 3 组合式 API，Nuxt 3.x 配 ant-design-vue 4.x，如果你还在 Nuxt 2 上，直接跳到第 6 节。
3.1 引入方式与 SSR 下的取舍
ant-design-vue 4 的样式文件路径变了，从dist/reset.css引入，不再是旧版本的dist/antd.css。nuxt.config.ts里至少要配两件事：样式引入和build.transpile，后者不加，SSR 阶段解析组件库的 ESM 产物会报错。
// nuxt.config.ts export default defineNuxtConfig({ css: ['ant-design-vue/dist/reset.css'], build: { transpile: ['ant-design-vue', '@ant-design/icons-vue'] } })组件注册有两种方式。全量注册在plugins里一行use(Antd)就行，开发期最省事，代价是打包体积大、首屏 JS 偏重。按需引入用unplugin-vue-components配AntDesignVueResolver，构建期自动引入用到的组件，体积能砍掉一大半，但 SSR 场景下要额外注意importStyle的配置，否则样式会闪一下才加载出来。
我的实际选择是：后台管理系统这类“用户登录后长期停留”的项目，直接用全量注册，省心；面向公网、首屏性能敏感的项目，老老实实上按需引入，多花半小时配置值得。
3.2 用 items 数据驱动菜单，而不是手写 a-menu-item
ant-design-vue 4 的 Menu 支持items属性，用数据描述整棵菜单树，比手写<a-menu-item>和<a-sub-menu>简洁太多，尤其是菜单需要根据权限动态生成的时候，数据驱动的优势非常明显。
import { h } from 'vue' import { DashboardOutlined, SettingOutlined } from '@ant-design/icons-vue' import type { ItemType } from 'ant-design-vue' export const menuItems: ItemType[] = [ { key: '/dashboard', icon: () => h(DashboardOutlined), label: '工作台' }, { key: '/system', icon: () => h(SettingOutlined), label: '系统配置', children: [ { key: '/system/user', label: '账号管理' }, { key: '/system/role', label: '角色管理' }, { key: '/system/audit', label: '审计', children: [{ key: '/system/audit/login', label: '登录记录' }] } ] } ]这里有个细节值得单独说：icon必须写成函数() => h(DashboardOutlined)，不能直接写h(DashboardOutlined)。直接写的话，同一个 VNode 对象会被复用，多个菜单项引用同一个组件实例，渲染时可能只有一个图标出来，或者控制台报重复 key 的警告。这个坑我在两三个项目里见过，每次都是找半天。
还有一点：items里的label只支持字符串或 VNode，不支持模板语法。想加角标、加自定义小图标，得用h()拼，或者改用labelRender。别指望在里面写<span>标签，它会被当成纯文本渲染出来。
3.3 selectedKeys 与 openKeys 的推导写法
这是全文的核心代码段。思路是：selectedKeys完全由路由推导，openKeys在路由变化时把该展开的父级合并进去，同时保留用户手动展开的其他项。
<template> <a-menu v-model:selected-keys="selectedKeys" v-model:open-keys="openKeys" mode="inline" theme="dark" :items="menuItems" @click="handleMenuClick" /> </template> <script setup lang="ts"> import { ref, watch } from 'vue' import { useRoute, useRouter } from 'vue-router' import { menuItems } from '~/config/menu' const route = useRoute() const router = useRouter() const selectedKeys = ref<string[]>([]) const openKeys = ref<string[]>([]) // 在菜单树里找到目标 key，返回从根到叶的 key 路径 function findKeyPath(items: any[], target: string, trail: string[] = []): string[] { for (const item of items) { const current = [...trail, String(item.key)] if (item.key === target) return current if (item.children) { const found = findKeyPath(item.children, target, current) if (found.length) return found } } return [] } function syncFromRoute() { const key = (route.meta.activeMenu as string | undefined) || matchByPrefix(route.path) selectedKeys.value = key ? [key] : [] const pathKeys = findKeyPath(menuItems, key) const parents = pathKeys.slice(0, -1) openKeys.value = Array.from(new Set([...openKeys.value, ...parents])) } watch(() => route.fullPath, syncFromRoute, { immediate: true }) </script>几个关键点逐条解释。watch的immediate: true不能省，它保证组件初始化时立刻执行一次同步，也就是 SSR 阶段就会算出正确的高亮，服务端返回的 HTML 里已经带上了选中态，不会出现“先渲染成未选中、客户端再改”的闪烁。这一点在实际体验上的差别非常明显，尤其是网络慢的时候。
用v-model:selected-keys而不是:selected-keys，是为了让点击时的高亮即时生效。虽然路由跳转之后 computed 也会更新，但那要等一个 tick，快速连续点击时会有轻微延迟感。双向绑定让点击立刻高亮，路由变化再校正一次，两条路径最终收敛到同一个值，不会有副作用。
openKeys用合并而不是覆盖，是为了尊重用户的手动操作。用户可能点开了三个不相关的父级在看，这时候路由变了，如果你直接覆盖成当前路径需要的父级，其他几个会突然收起来，体验很糟。合并之后，路由需要的父级自动展开，用户手动开着的保持开着，各管各的。
3.4 点击事件里做跳转的正确写法
点击处理看起来简单，但有三个地方容易写错。
const handleMenuClick = ({ key }: { key: string | number }) => { const target = String(key) // 外链单独处理 if (/^https?:\/\//.test(target)) { window.open(target, '_blank', 'noopener') return } // 点击当前页不重复跳转，避免路由堆栈里塞重复记录 if (target === route.path) return router.push(target) }第一个坑：key的类型是string | number。如果你在items里写了数字 key，router.push(10086)会报类型错误，必须先String()转一次。这个错误在开发环境有类型提示，但如果没用 TypeScript，就是运行时报错，且报错信息很难看懂。
第二个坑：不判断“点击当前页”。用户手抖点两下同一项，路由堆栈里会出现两条相同记录，用户按后退键会发现“怎么点了没反应”。加一行if就解决了。
第三个坑：外链。菜单里通常会混几个跳外部系统的入口，这些不能走router.push。判断要放在最前面，且window.open的第三个参数加上noopener，否则新窗口能通过window.opener反向操作原页面，是个安全隐患。
注意：
handleMenuClick在 SSR 阶段不会执行，所以在里面用window是安全的。但不要在<script setup>顶层直接访问window，Nuxt 服务端渲染时会直接抛window is not defined。
4. 折叠态、多级展开和手风琴模式里的三个硬约束
组件能跑起来之后，剩下的都是边界情况。这一节讲的三条限制，官方文档里只有零散的一两句话，不展开讲，但每一条都能让人卡住半天。
4.1 inlineCollapsed 打开时 openKeys 必须让位
Menu 在inlineCollapsed为 true 时，会变成悬浮弹层模式，这个模式下openKeys是无效的。如果你仍然传了一个非空的openKeys，会出现两种反常现象：一是鼠标移上去弹层不出现，二是弹层出现了但关不掉。更隐蔽的是控制台会有一条警告，很多人直接忽略了。
正确的做法是根据折叠状态决定传不传：
<a-menu v-model:selected-keys="selectedKeys" :open-keys="collapsed ? undefined : openKeys" :inline-collapsed="collapsed" mode="inline" :items="menuItems" />传undefined让组件回到非受控模式，由它自己管弹层。同时要监听collapsed的变化，在从折叠恢复展开时重新执行一次syncFromRoute，否则openKeys可能还停留在折叠前的旧值上，当前路由对应的父级没展开。
还有一种更稳的写法：折叠时不渲染open-keys属性，展开时再通过watch(collapsed)一次性把父级塞进去。两种都行，核心是别让openKeys和inlineCollapsed同时生效。
4.2 keyPath 的顺序是从叶子往根，别拼反
Menu 的 click 事件里会带一个keyPath参数，这个数组的顺序是从当前项往上到根，比如点击/system/user，keyPath是['/system/user', '/system']，而不是['/system', '/system/user']。如果你直接把keyPath塞给openKeys，展开会失效，因为openKeys需要的是所有父级，且不包含自己。
正确用法是keyPath.slice(1)，砍掉第一个元素。这个方向问题极其容易搞反，因为人在脑子里想“层级结构”时天然是从上往下。我建议干脆别用事件里的keyPath，统一用自己写的findKeyPath从菜单树里查，返回值是明确的根到叶顺序，用起来不容易出错。
另外提醒一句：keyPath里的元素类型是string，即使你菜单 key 写的是数字，这里也是字符串，比较的时候记得转换。
4.3 刷新后保留用户手动展开的状态
路由能恢复当前路径需要的父级，但恢复不了用户额外展开的那些。有些后台系统的菜单层级很深，用户习惯性地把几个模块都展开着，刷新一下就全收起来了，用起来很烦。
解决办法是把openKeys同步到sessionStorage，初始化时读回来：
const STORAGE_KEY = 'menu-open-keys' const openKeys = ref<string[]>([]) function restoreOpenKeys() { if (typeof window === 'undefined') return [] try { return JSON.parse(sessionStorage.getItem(STORAGE_KEY) || '[]') } catch { return [] } } onMounted(() => { openKeys.value = restoreOpenKeys() syncFromRoute() }) watch(openKeys, (val) => { if (typeof window === 'undefined') return // 折叠态下 val 会被清空，别把空值存进去 if (val.length) sessionStorage.setItem(STORAGE_KEY, JSON.stringify(val)) }, { deep: true })这里有两个细节。一是用sessionStorage而不是localStorage，因为菜单展开状态属于单次会话的临时偏好，关掉标签页就重置更符合直觉。二是折叠态下openKeys可能被清空，如果直接存，用户展开折叠一次就把历史状态覆盖没了，所以要加长度判断。
用onMounted而不是在watch里直接immediate，是因为sessionStorage在服务端不存在，首帧不能依赖它，否则 SSR 和客户端渲染结果不一致，会触发水合警告。
5. 刷新后高亮丢失的完整排查链路
这一节把排查过程完整走一遍，因为“高亮丢失”有至少三种不同的成因，现象看着一样，修法完全不同。直接给答案没意义，下次换个场景还是会卡住。
5.1 先分清是“没选中”还是“选中了又闪回”
打开页面，按 F5 刷新，盯住菜单。如果从头到尾没有任何一项高亮，那selectedKeys一开始就是空的，问题在推导逻辑或者执行时机。如果先高亮了一下，然后突然灭掉，那是渲染后被别的东西覆盖了，通常和水合、或者onMounted里的初始化逻辑有关。
第一种情况，先去console.log(selectedKeys.value)打印一下，看看是不是空数组。空的话往上查selectedKey的计算结果，再看route.meta.activeMenu和route.path的值是否匹配。很多时候是路径里带了尾斜杠，或者activeMenu写错了一个字母。第二种情况，检查是不是在onMounted里把selectedKeys重置成了[]，这个错误很常见——复制粘贴了初始化代码，忘了它会在客户端覆盖掉已经算好的值。
再有一种更隐蔽的：菜单渲染了两次。如果你的布局组件被<ClientOnly>包着，或者用了<Suspense>，可能出现先渲染一个占位版本、再渲染真实版本的情况，中间那一帧的菜单是没数据的。这种就得看 DOM 结构，用开发者工具确认是不是真有两份。
5.2 服务端与客户端首帧不一致
Nuxt 默认开启 SSR，首屏 HTML 由服务端生成。如果服务端算出的selectedKeys和客户端算出的不一样，Vue 会报 hydration mismatch，并且在客户端重新渲染，视觉上就是高亮闪一下。常见的触发原因有三个。
第一，在计算selectedKey时用了只有客户端才有的信息，比如window.location.pathname。服务端没有window，走了兜底分支，算出来的值和客户端不同。换成useRoute().path就好了，Nuxt 的服务端路由是真实存在的，能拿到正确的路径。
第二，读localStorage或sessionStorage初始化状态。服务端读不到，返回空数组，客户端读到值，两边不一致。解决办法是把这类初始化放到onMounted里，首帧统一用路由推导的结果。
第三，用了Date.now()、随机数之类的非确定性值做 key 或判断条件。这类问题最难查，因为每次刷新错的位置都不一样。菜单相关的代码里基本不会出现，但如果菜单项是从接口拉的然后动态生成，接口返回顺序不稳定就会导致两端结构不同，需要排序后再渲染。
5.3 三个我实际踩过的具体坑
第一个坑：route.meta的类型声明缺失。TypeScript 严格模式下，route.meta.activeMenu会被推断成unknown，不做断言直接用在selectedKeys里，运行时会是个对象而不是字符串，菜单高亮静默失效，控制台没有任何报错。修法是给RouteMeta做类型扩展：
// types/router.d.ts declare module 'vue-router' { interface RouteMeta { activeMenu?: string title?: string } }第二个坑：watch的监听源写成了route.path。path变化时确实会触发，但只变化 query 的场景（比如分页参数?page=2）不会触发，导致某些依赖 query 切换的页面高亮不更新。改成route.fullPath就都能覆盖到。反过来，如果你的菜单项 key 里可能包含 query，那用fullPath反而会错，这时候要用path加单独处理 query，具体看菜单怎么设计。
第三个坑：<a-menu>被包在一个v-if里，条件依赖异步数据。异步数据到达前v-if为 false，菜单不渲染，watch里的syncFromRoute已经执行过了，等菜单真正渲染出来时，selectedKeys的值虽然对，但openKeys的推导发生在菜单树还不存在的时候，findKeyPath返回空数组，父级没展开。修法是把syncFromRoute的调用改成依赖菜单数据，或者在菜单数据就绪后手动触发一次。
提示：
findKeyPath返回空数组时，说明菜单树里根本没有这个 key。别急着怀疑路由，先打印一下flattenKeys(menuItems)，看看 key 到底长什么样，很多时候是配置里多写了个斜杠或者少写了个字符。
6. 老项目 Nuxt 2 + ant-design-vue 1.x 的改法
维护老项目的人不少，Vue 2 的写法差异主要在响应式 API 上，思路完全一样。这一节把关键差异列清楚，其余部分对照前面的思路翻译就行。
6.1 Vue 2 里没有 v-model:selectedKeys
Vue 2 没有v-model:xxx这种多参数绑定语法，ant-design-vue 1.x 的 Menu 对openKeys支持.sync修饰符，对selectedKeys则不一定支持（取决于具体小版本），最稳的写法是两者都手动维护，不依赖任何语法糖。
<template> <a-menu :selected-keys="selectedKeys" :open-keys="openKeys" mode="inline" theme="dark" @click="handleMenuClick" > <a-menu-item v-for="item in flatItems" :key="item.key"> {{ item.label }} </a-menu-item> </a-menu> </template> <script> export default { data() { return { selectedKeys: [], openKeys: [] } }, watch: { $route: { handler() { this.syncFromRoute() }, immediate: true } }, methods: { syncFromRoute() { const key = this.$route.meta.activeMenu || this.$route.path this.selectedKeys = [key] const pathKeys = this.findKeyPath(this.menuItems, key) this.openKeys = Array.from( new Set([...this.openKeys, ...pathKeys.slice(0, -1)]) ) }, handleMenuClick({ key }) { if (key === this.$route.path) return this.$router.push(key) } } } </script>注意watch的$route监听。Vue 2 中$route对象被替换时才会触发，所以直接监听$route而不是$route.path，能覆盖所有路由变化。immediate: true保证组件创建时执行一次。Vue 2 的响应式对数组的push有拦截，但Array.from(new Set(...))返回的是新数组，整体替换，不会有响应式丢失问题。
6.2 混用 router-link 会带来两套高亮
老项目里很常见的一种写法是在<a-menu-item>里塞<router-link>，觉得这样“语义更正确”。实际效果是点击时router-link自己跳一次，菜单的@click又跳一次，路由堆栈里两条记录；更别扭的是，router-link会给自己加router-link-active类，菜单又会加ant-menu-item-selected类，两套高亮规则打架，某些情况下会出现两个菜单同时亮着。
要混用也不是不行，但必须做减法：要么只保留router-link且菜单完全不受控（selectedKeys不传，让它走非受控模式，但这样刷新后无法恢复），要么只保留@click跳转并把router-link去掉。我的建议是后者，菜单项的语义是“导航条目”不是“链接”，用@click更贴切，控制权也完整。
还有一个老版本的细节：ant-design-vue 1.x 的 Menu 在非受控模式下，会在点击时自己维护选中态，但只要你在任何一个时机传了selectedKeys，它就切到受控模式，之后再也不自己管。切换过程不报错，行为却是突变的，很容易让人以为“偶尔会失效”。看到这种诡异现象，先检查selectedKeys是不是某个分支里传了、某个分支里没传。
7. 从路由表反推菜单结构，省掉手工维护
菜单配置和路由配置两处维护，页面多了必然不同步。新人加了个页面，路由配了，菜单忘了加，线上就是“这个功能进不去”。更麻烦的是权限系统上线之后，菜单要按角色过滤，手工维护的数组很难和路由的权限声明对齐。
7.1 meta 字段的约定
在路由上约定几个字段，菜单完全由路由生成。常用的四个：title菜单显示名、icon图标组件名、hidden是否在菜单中隐藏、order排序权重。Nuxt 3 的definePageMeta可以直接写，或者如果你用的是自定义 routes，写在router.options.ts里。
definePageMeta({ title: '账号管理', icon: 'UserOutlined', order: 20, activeMenu: '/system' })hidden主要用于详情页、编辑页这类不应该出现在菜单里的路由。这类页面通常有activeMenu指向列表页，两者配合起来，菜单结构干净，高亮也能对上。
7.2 递归建树与过滤隐藏项
拿路由表建树的思路是：先过滤掉hidden的项，再按path的层级关系挂父子。Nuxt 3 里useRouter().getRoutes()能拿到全部已注册路由，服务端也能调用，两端结果一致，不会触发水合问题。
function buildMenu(routes: any[]) { const visible = routes .filter((r) => !r.meta?.hidden && r.meta?.title) .sort((a, b) => (a.meta.order ?? 999) - (b.meta.order ?? 999)) const map = new Map<string, any>() const roots: any[] = [] for (const r of visible) { map.set(r.path, { key: r.path, label: r.meta.title, icon: r.meta.icon ? () => h(iconMap[r.meta.icon]) : undefined, children: [] }) } for (const r of visible) { const node = map.get(r.path) const parentPath = r.path.replace(/\/[^/]+$/, '') || '/' const parent = map.get(parentPath) if (parent) parent.children.push(node) else roots.push(node) } // 清掉空 children，不然子菜单会渲染出一个空展开箭头 const prune = (nodes: any[]) => { for (const n of nodes) { if (n.children.length) prune(n.children) else delete n.children } } prune(roots) return roots }这段代码里最容易忽略的是最后那个prune。如果不删空的children数组，Ant Design Vue 会把它当成一个有子级的sub-menu渲染，界面上多出一个展开箭头，点开是空的，非常显眼。这个 bug 我在两个项目里都见过，第一次查了快一个小时，因为数据结构看着完全正常，只是多了一个空数组。
另外一个注意点：iconMap要预先建好映射表，把字符串映射到实际的图标组件。不要用动态import()按需加载图标，那样icon会变成 Promise，渲染出来是空白。图标数量有限，全部静态引入，打包体积的增量可以接受。
排序这块，父子层级和同级顺序是两套逻辑。order只作用于同级，跨层级的排序由path的层级关系决定。如果你的菜单需要完全自定义顺序（比如某些模块要置顶），纯靠path建树就不够了，得在 meta 里加一个显式的parent字段指定父级，建树时按这个字段挂。这是用复杂度换灵活性，看项目需求决定。
最后提一下权限过滤。菜单按角色过滤最好放在建树的最后一步，用一个hasPermission(path)函数统一过滤，而不是在每个definePageMeta里写一堆判断。原因是权限数据通常在运行时才能拿到，写在 meta 里是编译期的事，两者天然冲突。过滤函数里同时处理“自己没权限”和“所有子级都没权限”两种情况，后者也要从菜单里去掉，否则会留下一个点开空空如也的父级。
这套东西做完之后，回头看最开始那个问题——刷新后菜单不高亮，会发现它已经不是问题了，因为高亮完全由路由推导，而路由在任何时候都是确定的。真正花时间的从来不是写代码，而是想清楚每个状态由谁持有。我自己的经验是，凡是“界面上显示的东西”和“地址栏里的东西”不一致的地方，基本都能归到同一个原因：有一个状态被独立维护了，而没有从真相来源派生出来。菜单高亮只是这个规律最典型的一个例子。
