Next.js 中间件与权限控制：入口拦截、授权分层与可维护策略
Middleware 在 Next.js 里很强大，因为它能在请求进入页面或路由前先执行逻辑。也正因如此，很多团队会把所有权限逻辑都塞进去，最后得到一个难维护、难调试、难审计的安全层。
中间件真正擅长的是入口拦截，而不是承载全部授权规则。
1. 先定义 Middleware 的职责边界
推荐边界：
- 做登录态校验与路径级别放行/拦截
- 处理基础重定向策略
- 附加轻量上下文信息
不推荐：
- 在中间件中执行复杂业务权限判断
- 依赖外部重查询作为核心判断路径
- 把资源级授权全部前置
边界清楚后，架构才会稳定。
2. 权限分层模型（实战可用）
| 层级 | 目标 | 放置位置 |
|---|---|---|
| 认证层 | 判断是否登录 | Middleware / Server |
| 页面授权层 | 判断能否访问某区域 | Middleware + 页面服务端 |
| 资源授权层 | 判断能否操作具体资源 | API/Server Action 服务层 |
把所有判断堆在第一层，短期省事，长期必乱。
3. 为什么资源权限不能只靠 Middleware
Middleware 面向的是路径和请求上下文，而资源权限通常依赖：
- 组织角色
- 资源归属
- 套餐能力
- 业务状态
这些信息往往只能在业务执行点做精确判断。否则容易出现“页面拦住了，但 API 没拦住”的越权漏洞。
4. 失败案例：中间件规则越来越多，最终无人敢改
典型症状：
- 条件判断链过长
- 同一路径多处重复规则
- 新增一个角色要改 5 处逻辑
- 回归测试覆盖不到边缘路径
这说明权限体系耦合过高，不是功能多了，而是分层失效了。
5. 推荐落地方式
- Middleware 只维护路径级基础访问矩阵。
- 资源级权限统一收敛到服务端权限模块。
- 关键路由做最小自动化回归测试。
- 规则变更时同步更新权限清单文档。
让规则可读、可追踪、可验证，比“写得快”更重要。
6. 与 NextAuth/Auth.js 协同
如果你使用 NextAuth/Auth.js：
- 中间件可做登录态粗拦截
- 具体资源判断仍放在 Route Handler 或 Server Action
- 保持会话读取入口一致，减少逻辑分叉
这种组合能显著降低权限回归风险。
7. Checklist：中间件权限体系是否健康
- Middleware 是否只做入口层判断
- 资源授权是否在服务端执行点复核
- 规则是否有单一来源与文档化
- 关键路径是否有自动化回归
- 新角色接入是否可在有限修改点完成
8. 结论
Next.js Middleware 是权限体系的第一道门，而不是唯一一道门。只有把入口拦截和资源授权分层治理，才能既保持安全性，也保持长期维护效率。
进一步阅读：
