主题
Next.js 高级架构
Next.js Multi-Zones 如何支持大型组织的渐进式拆分？
Multi-Zones 解决的是多个 Next.js 应用共享一个域名的路由协作，不等于自动解决跨应用状态、设计系统和发布一致性。
面试官想考什么
- 为什么不直接做一个超大 Next.js 应用？ 考察组织和边界。
- 请求如何路由到不同 Zone？ 考察代理和路径归属。
- 跨 Zone 跳转为什么可能是完整刷新？ 考察客户端导航边界。
- 版本不一致和回滚如何处理？ 考察发布治理。
一句话回答
text
Multi-Zones 通过反向代理把不同路径交给不同 Next.js 应用，适合团队和技术栈渐进拆分；要明确路由唯一归属、跨 Zone 导航降级、共享 UI 版本、cookie/鉴权和独立回滚策略。面试回答详解
1. 请求拓扑
text
shared domain -> edge/reverse proxy -> zone A/B
-> independent Next.js app -> its own build/runtime每条路径只能有一个权威 Zone，代理规则要版本化并可回滚。
2. 导航边界
同一 Zone 内可以使用客户端导航；跨 Zone 通常需要完整页面导航，不能假设 Router Cache 和 RSC payload 可以跨应用复用。公共导航组件应正确识别内部与跨 Zone 链接。
3. 共享能力
设计系统、鉴权 cookie、埋点协议和错误页可通过独立包或契约共享，但不要让 Zone 直接依赖另一个 Zone 的内部模块。共享包要有兼容版本和发布策略。
4. 数据和安全
各 Zone 可以共享身份，但每个服务端仍需验证 session、租户和资源权限。不同应用的 rewrite、缓存 key、CSP、静态资源前缀和 cookie Path 不能互相覆盖。
5. 发布与回滚
先部署新 Zone，再切代理流量；跨 Zone 契约要向后兼容。回滚时同时考虑代理规则、静态资源、cookie、API schema 和监控告警，不能只回滚单个应用镜像。
可直接背诵的 30 秒回答
text
Multi-Zones 是通过边缘代理按路径把请求分发给多个独立 Next.js 应用，适合大型组织渐进拆分。设计时要保证路径唯一归属，知道跨 Zone 导航通常是完整刷新，统一鉴权和设计系统契约，并把代理规则、资源版本、API 兼容和回滚纳入发布治理。扩展知识
Multi-Zones 与微前端
Multi-Zones 更接近按路径拆分的多应用部署，不等于浏览器运行时组件拼装。它的隔离更强，跨应用交互也更少。
面试官追问链
追问一：跨 Zone 能否保留客户端状态？
- 考察点：导航边界。
- 回答方向：内存状态通常会丢失，可用 URL、服务端 session 或受控持久化传递；敏感数据不放 localStorage。
追问二：两个 Zone 如何共享登录？
- 考察点：身份体系。
- 回答方向：共享受保护 cookie 或统一认证服务，但各 Zone 必须独立验证和授权。
追问三：如何避免路径冲突？
- 考察点：路由治理。
- 回答方向：建立路径 ownership 清单、代理配置测试和变更审批，构建阶段检查重复归属。