主题
Next.js 原理与运行时
Next.js Proxy 与鉴权、重写和运行时边界如何设计？
Proxy 适合做请求级的早期决策，但不应承载完整业务鉴权、数据库事务或长耗时逻辑。
面试官想考什么
- Proxy 和页面内鉴权有什么区别？ 考察防护层次。
- 重定向与 rewrite 如何选择？ 考察 URL 和渲染语义。
- Proxy 中能否访问数据库？ 考察运行时限制。
- 如何避免 matcher 误匹配和开放重定向？ 考察安全与边界。
一句话回答
text
Proxy 放在请求很早的入口，适合做轻量路由判断、重写、重定向和粗粒度访问控制；真正资源授权仍要在 Server Component、Route Handler 或数据层复核，Proxy 代码必须按其运行时能力和 matcher 范围设计。面试回答详解
1. Proxy 做什么
text
request -> matcher -> proxy decision
-> redirect / rewrite / continue
-> route handler or page authorization它可以在请求进入页面前读取有限上下文，做 locale、实验分流、登录态初筛和路径重写。它不是把后端中间层搬进前端目录。
2. Redirect 与 rewrite
- redirect：浏览器地址改变，适合登录跳转、规范 URL 和跨域入口。
- rewrite：地址保持不变，适合内部路由映射或 BFF 转发，但要关注缓存和 SEO。
用户提供的 returnTo 必须限制为站内安全路径，避免开放重定向。
3. 鉴权分层
Proxy 可检查 cookie 是否存在，提前阻止明显未登录请求；页面或 API 仍需验证 session、租户、资源和动作权限。不能把“有 token”当作“能读这条数据”。
4. 运行时与性能
Proxy 常处于边缘请求路径，代码要轻、依赖要小、不能依赖 Node-only API 或长连接。matcher 要排除静态资源、内部构建路径和不需要处理的请求，避免每个资源都执行逻辑。
5. 生产治理
记录重写命中、拒绝原因、版本和区域，但不要日志化 cookie/token。变更 matcher 要做路由回归，避免静态资源 404、API 被错误重写或缓存 key 混乱。
可直接背诵的 30 秒回答
text
Proxy 是请求入口的轻量决策层，适合做 matcher、重定向、rewrite、locale、实验分流和登录态初筛；它不替代页面或 API 的资源授权，也不适合数据库事务和长耗时任务。实现时要考虑 Edge/Node 能力、matcher 排除范围、开放重定向、缓存影响和日志脱敏。扩展知识
Proxy、Route Handler、Server Action
- Proxy：请求入口决策。
- Route Handler：HTTP API/流响应边界。
- Server Action：服务端 mutation 调用边界。
- 三者都必须在业务数据层重新鉴权。
面试官追问链
追问一：只在 Proxy 判断登录够不够？
- 考察点：安全边界。
- 回答方向：不够。直接访问 API、缓存命中、内部调用和竞态都可能绕过页面，资源授权要靠服务端数据层。
追问二：为什么 matcher 配错会导致图片加载失败？
- 考察点：请求范围。
- 回答方向：Proxy 可能处理静态资源或内部路径并改变响应；应明确排除静态文件和构建资源，并覆盖真实请求矩阵。
追问三：Proxy 能否做 AB 实验并写 cookie？
- 考察点：缓存一致性。
- 回答方向：可以，但要让实验维度进入缓存 vary/key，避免不同用户拿到同一实验结果，并控制 cookie 体积和隐私。