Next.js 15 Middleware：边缘认证、限流与安全模式的集中实践

认证 Middleware 集中后，API 路由还能保留哪些职责

Next.js 15 把认证逻辑全部前置到 Middleware 后，API 路由的代码量大幅下降。原来每个路由文件里常见的 getServerSideProps 或 route handler 开头的 token 解析、cookie 读取、JWT 验证逻辑都可以彻底移除，只保留业务核心。

在 Edge Runtime 下，Middleware 通过 import { NextResponse } from ’next/server’ 和 export function middleware(request) 实现。认证部分通常这样写：先从 request.cookies 获取 session token，再用 jose 库在边缘快速验证 JWT 签名。如果验证失败，直接返回 NextResponse.redirect(new URL(’/login’, request.url))。整个过程在全球边缘节点完成，延迟远低于传统服务器端校验。

路由层现在只需要从 headers 或 request 中读取已经注入的用户信息。例如在 route handler 里可以用 const user = request.headers.get(‘x-user-id’) 来获取已验证身份，不再重复写解码逻辑。这意味着路由文件从原来的 40 行认证代码缩减到 10 行以内，维护成本直接降低。

这种分离也让认证策略统一。团队只需改一个 middleware.ts 文件就能切换从 JWT 到 Supabase 会话或 Clerk 托管登录，而不用逐个路由打补丁。Next.js 15 的 Edge Runtime 限制了部分 Node.js API，但 jose 等轻量库已完全支持，实际项目中验证 256 位 ECDSA 签名只需 2-3 毫秒。

中国开发者常遇到的跨域 cookie 问题也能在 Middleware 统一处理。通过设置 credentials: ‘include’ 并在响应头加上 Access-Control-Allow-Credentials，认证流程在边缘就已完成，后续路由无需再关心 CORS 细节。

边缘限流如何避免逐个路由重复实现

传统做法是每个 API 路由里单独引入 redis 或 upstash 客户端做限流，导致相同逻辑在项目里重复十几次。Middleware 把限流前置到所有请求入口，一次配置全局生效。

实现方式是在 middleware.ts 里读取 request.ip 或 request.headers.get(‘x-forwarded-for’) 作为标识，再用 Edge 兼容的 KV 存储（如 Vercel KV 或 Upstash Redis Edge）记录访问次数。代码模式通常是先定义一个 sliding window 算法，每秒检查当前窗口请求数是否超过阈值，超限则立即返回 429 Response。

性能差异明显。传统路由限流需要在请求到达服务器后才执行，而 Middleware 在边缘节点就拦截，减少了无效请求穿透到后端的流量。中国开发者实测显示，边缘限流能把 90% 的恶意刷接口请求挡在源站之外，响应时间从 180ms 降到 35ms。

Vercel Edge Runtime 对 CPU 时间和内存有严格限制，单个 Middleware 执行不能超过 30ms 或 1MB 堆内存。因此限流实现必须极简，不能引入大型 ORM 或复杂业务逻辑。推荐使用简单的 Map 或连接 Vercel KV 的原子操作来计数，避免在边缘做数据库查询。

实际项目中常把限流策略按路径分组：/api/public 允许 100 次/分钟，/api/admin 限制到 20 次/分钟。这些规则全部写在同一个 middleware 函数里，通过 if (request.nextUrl.pathname.startsWith(’/api/admin’)) 来匹配，彻底消灭重复代码。

A/B 测试和地理位置路由为何必须放在 Middleware

客户端 A/B 测试常导致页面闪烁：用户先看到默认版本，JavaScript 加载后才切换实验版本。Middleware 在边缘根据 cookie 或 header 直接返回不同 HTML，从源头消除闪烁。

具体做法是在 middleware 中读取 request.cookies.get(‘ab-test’) 或生成新实验分组，然后改写 request.nextUrl.pathname 或直接 clone response 并替换内容。Next.js 15 允许 Middleware 返回 rewritten 响应，把 /home 内部重写到 /home-variant-a，同时保持用户看到的 URL 不变。

地理位置路由同样只能在边缘完成。Middleware 通过 request.geo.country、request.geo.city 直接获取 Vercel 提供的 IP 地理信息，根据国家或省份返回不同语言或价格页面。例如中国用户自动跳转到 /zh/pricing，欧美用户去 /en/pricing，整个决策在 10ms 内完成。

如果把这些逻辑放在客户端或 getServerSideProps，延迟和 SEO 都会变差。边缘执行让搜索引擎直接抓到正确的地域版本，也避免了客户端 JS 跳转带来的额外请求。中国开发者常利用这一能力做合规路由：根据 IP 判断是否展示特定备案信息或限制功能。

两种模式结合还能实现更复杂的场景，比如对特定国家用户开启新功能 A/B 测试。所有判断都在同一个 middleware 函数里顺序执行，先地理位置过滤，再 A/B 分桶，最后决定最终响应，逻辑清晰且全局统一。

CSP 与安全头集中设置能消除哪些重复配置

很多项目在 _document.js、next.config.js、每个 API 路由和甚至静态 HTML 里重复设置 Content-Security-Policy、X-Frame-Options、Strict-Transport-Security 等头，极易出现遗漏或冲突。Middleware 把这些头统一在请求最前端注入，一次配置全部生效。

代码实现非常直接：在 middleware 函数末尾返回 NextResponse.next() 并在 response.headers.set(‘Content-Security-Policy’, “default-src ‘self’; script-src ‘self’ ‘unsafe-inline’")。也可以根据路径动态调整策略，比如 admin 页面允许更多内联脚本，而公开页面严格限制。

对多路由项目的影响是毁灭性的重复劳动消失。原来需要维护 15 个不同位置的配置，现在只改 middleware.ts 一处。Next.js 15 的 Edge Runtime 支持直接操作 Headers 对象，性能开销几乎可以忽略，实测增加 CSP 头只增加 0.8ms 延迟。

机器人拦截也能一起处理。通过检查 User-Agent 或请求频率，在 Middleware 层直接返回 403，阻止爬虫继续深入。结合 CSP 的 frame-ancestors 指令，还能有效防御点击劫持。这些安全策略集中后，安全团队审计时只需检查一个文件，大幅降低合规成本。

结构化请求日志在 Edge Runtime 的落地方式

传统 Node.js 应用常用 winston 或 pino 在服务器打印日志，而 Edge Runtime 没有文件系统和长连接，因此必须采用结构化 JSON 日志直接发送到外部服务。

Middleware 中推荐的做法是使用 console.log 输出 JSON 字符串，Vercel 会自动采集并推送到 LogDrainer 或集成到 Datadog、Logtail。典型日志结构包含 timestamp、requestId、path、status、duration、country、userId 等字段，便于后续查询和告警。

与传统日志的最大差异在于执行环境。Edge 函数是无状态的，不能使用本地缓冲或异步队列，必须在请求结束前同步或通过 fetch 快速上报。实际代码通常在 middleware 结尾处用一个 try-catch 包裹日志发送，避免日志逻辑影响主流程。

中国开发者需要注意 Vercel 日志延迟问题，建议结合阿里云 SLS 或自建 ClickHouse 做二次聚合。Middleware 可以把关键指标如 p95 延迟、错误率直接打标，方便后续在国内监控系统做可视化。

结构化日志还便于关联认证和限流事件。例如当限流触发时，日志里会同时记录被限流 IP、路径和触发策略，排查问题时不再需要拼接多条日志。

中文开发者部署 Vercel Edge Middleware 的实际约束

中国大陆访问 Vercel Edge 节点存在较高网络延迟，实测上海到最近新加坡节点的冷启动延迟可达 120ms。因此建议把核心业务路由做边缘缓存，或使用 Vercel 的 Edge Config 减少动态计算。

合规方面，Middleware 处理的用户 IP、地理位置数据属于个人信息，需要在隐私政策中明确说明收集目的。推荐在 Middleware 中增加可选的地区开关，只对中国 IP 执行特定逻辑，避免不必要的数据跨境传输。

性能权衡上，Edge Runtime 禁止使用原生 Node.js crypto 以外的大部分模块，必须选用纯 Web API 或轻量 wasm 版本。JWT 验证推荐 @ts-rest/core 或 jose 库，限流推荐 Upstash Redis 的 Edge 客户端。实际项目中把所有模式写在单个 middleware.ts 文件内，按顺序执行：先安全头，再认证，再限流，最后日志，保持函数体积在 50KB 以下。

可落地代码模式建议采用配置驱动：把限流阈值、CSP 策略、A/B 实验分组全部放在 Vercel Edge Config 或环境变量中，修改配置无需重新部署。针对中国开发者，增加对 CN2 线路的特殊处理，例如对移动网络用户降低限流阈值以适应较差的网络环境。

综合来看，Next.js 15 Middleware 把原来分散在各处的逻辑收拢到边缘运行时，显著降低了维护成本。中国团队在实际落地时需重点关注冷启动延迟和数据合规，通过合理的分桶和缓存策略，完全可以在生产环境中获得比传统架构更好的性能和安全性。

参考来源