根本原因是404路由被提前注册在静态路由表中，刷新时动态路由未加载即被匹配；应初始仅含免权限路由，登录后按序注入基础路由→动态路由→404兜底路由。
根本原因不是 addRoute 失效，而是路由匹配顺序和初始化时机错配：404 路由被提前注册在静态路由表中，刷新后动态路由尚未加载，请求直接被 404 捕获。
404 路由不能写死在静态配置里
很多项目把通配路由（如 /:pathMatch(.*)*）直接放在 const routes = [...] 静态数组末尾。这看似合理，但刷新时 Vue Router 会立即用这个静态路由表做首次匹配——此时动态路由还没通过 addRoute 注入，所有非登录页路径都命中 404。
关键点：
- 静态路由表在应用启动时就固定，
addRoute添加的路由不会自动插入到它的中间或末尾 -
router.options.routes不反映动态添加后的完整路由列表（要用router.getRoutes()查看） - 路由匹配是顺序执行的，先定义的先匹配，404 必须是最后兜底的那一个
刷新时动态路由丢失的本质
Vue Router 的路由实例是内存对象。页面刷新等于进程重启，之前调用 addRoute 注册的所有动态路由全部清空，必须重新拉取权限菜单、解析、再逐条添加。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
常见误操作：
- 只在登录后
beforeEach中添加一次路由，但没判断是否已添加过，导致重复添加或漏加 - 未持久化菜单数据，刷新后无法快速重建路由，只能等接口返回，期间已有请求进入 404
- 把 404 路由和动态路由混在同一个
addRoutes调用里，但没确保它排在最后
正确注入时机：守卫 + 状态驱动
核心原则：让 404 成为「最后注册」且「仅当其他路由都不可用时才生效」的兜底项。
推荐做法：
- 初始路由表只包含登录页、首页重定向等无需权限的路由，不包含 404
- 在
router.beforeEach中检查用户登录态和菜单是否已加载；若未加载，先发请求获取菜单路由配置 - 拿到菜单后，清空当前 matcher（
router.matcher = new Router({...}).matcher），再按顺序添加：基础静态路由 → 用户专属动态路由 → 404 通配路由 - 可选：将菜单缓存到
localStorage，刷新后优先从缓存读取并快速重建，避免白屏等待
额外注意两个隐蔽坑
除了 404 顺序问题，还有两个高频雷区：
- 同名路由覆盖：如果动态添加的路由与静态路由 name 相同，Vue Router 会直接替换原路由，可能导致预期外的跳转失败或权限错乱
-
history 模式服务端缺失：即使前端路由逻辑完全正确，若部署在 history 模式下且 Nginx/Apache 未配置
try_files $uri $uri/ /index.html，浏览器刷新仍会向服务器请求真实路径，直接返回 404（这是 HTTP 层错误，和 Vue Router 无关）
