Nuxt 项目里的权限问题，很多时候不是认证逻辑本身复杂，而是判断分散得到处都是。
常见现象是：
- 页面里写一次登录判断
- 中间件里再写一次角色判断
- 接口请求失败后组件里再补一次跳转
结果就是权限策略没有形成规则，只是在不同文件里重复判断。
先明确中间件到底解决什么问题
中间件适合处理的是“路由进入前的统一决策”，而不是所有业务分支。
更适合放进 Nuxt 中间件的场景通常包括：
- 是否需要登录
- 是否需要某类角色或租户权限
- 是否需要按环境或实验配置重定向
- 是否需要根据页面元信息做统一校验
如果把组件内局部交互判断也塞进中间件，很快就会让守卫链路过重。
路由守卫要先拆成三层职责
更稳的结构通常是：
- 全局中间件：处理站点级规则，例如登录态恢复、维护模式、实验流量入口
- 命名中间件：处理业务域规则，例如后台权限、会员页访问、租户隔离
- 页面内判断：处理仅与当前视图交互有关的局部权限
把这三层拆开后，团队更容易判断某条逻辑应该放在哪里，而不是一有权限需求就把代码堆进全局守卫。
页面元信息比硬编码路径更适合承载规则
很多团队会直接用路径前缀做判断，比如 /admin、/member、/settings。
这种方式起步很快，但随着站点增长，问题会越来越多：
- 路由重构时容易漏改
- 相似路径不一定代表相同权限
- 权限语义被路径结构绑死
更可维护的方式，是通过页面元信息声明守卫需求。
definePageMeta({
middleware: ['auth', 'role-admin'],
requiresSubscription: true,
})
这样中间件不再依赖路径猜测，而是读取页面显式声明的访问规则。
重定向策略要避免循环和状态丢失
权限守卫最常见的线上故障之一，就是错误重定向链路。
典型问题包括：
- 未登录用户被跳到登录页后，登录成功又回不去原页
- 登录用户访问登录页被反复重定向
- 角色不足时被送回首页，用户完全不知道为什么
因此重定向策略至少要做到：
- 保留来源路径
- 区分“未登录”和“无权限”
- 对公开页、登录页和受保护页使用不同处理方式
服务端与客户端守卫要统一口径
Nuxt 中间件在 SSR 和 CSR 场景下都可能执行，所以权限判断不能只依赖浏览器态信息。
更稳的做法是：
- 登录态来源统一封装
- 角色信息尽量在服务端就拿到
- 客户端只负责补充体验，不负责定义最终权限
如果客户端判断和服务端判断口径不同，就会出现服务端允许、客户端拒绝，或者相反的错乱行为。
常见失败案例：守卫生效了，但维护成本越来越高
这类项目通常不是中间件没写对，而是没有治理规则：
- 业务方随手新增一个守卫文件
- 相同逻辑在不同中间件中重复存在
- 页面元信息没有统一约定
- 出现跳转异常时没人说得清哪一层负责
长期看，问题不在认证复杂，而在守卫体系失去可读性。
一套更可执行的治理方式
推荐团队至少建立四个约定：
- 中间件只处理路由进入前的统一决策
- 页面权限需求优先通过元信息声明
- 重定向结果必须保留来源和失败原因
- 守卫命名按职责分层，禁止重复造近义规则
这样后续新增权限场景时，大家是在扩展体系，而不是继续堆条件分支。
一份可直接复用的检查清单
- 是否区分了全局守卫、命名守卫和页面内局部判断
- 权限需求是否通过页面元信息显式声明
- 重定向是否保留来源路径并区分未登录与无权限
- 服务端与客户端是否使用同一套权限口径
- 守卫文件是否有清晰命名和去重规则
总结
Nuxt 中间件与路由守卫真正要解决的，不是“能不能拦住访问”，而是“能不能让权限策略长期可读、可扩展、可调试”。只要职责分层、规则声明和重定向策略被统一，守卫体系就会稳定很多。
进一步阅读：
