使用Next.js静态生成落地页时是否应将仪表盘拆分至新子域名

关于是否需要新建独立应用托管到子域名 #

推荐拆分为独立应用托管到子域名，核心原因如下：

• 部署逻辑完全解耦：你当前的落地页是纯静态资源，执行next build && next export后托管到S3，更新频率低，可以配置极长的CDN缓存周期提升访问速度；而仪表盘涉及用户鉴权、订阅状态校验、支付流程，迭代频率更高，拆分后两边的构建、发布、缓存策略互不干扰，不会出现修改仪表盘功能导致落地页缓存失效、重新全量构建的问题。
• 安全边界更清晰：子域名可以单独配置WAF规则、内容安全策略，和公开可访问的营销落地页做隔离，Firebase身份凭证、Stripe支付相关的敏感数据不会和主站公开请求混存，能大幅降低XSS、敏感数据泄露的风险。
• 访问体验更好：公开落地页不需要加载任何鉴权、支付相关的冗余JS资源，首屏加载速度可以做到最优；仪表盘单独做资源分包、路由预加载策略，不会被营销页的动画、营销组件拖慢加载速度。

如果团队人力极其有限不想维护多套应用，也可以在现有Next.js项目中通过路由拆分做仪表盘模块，但注意你当前纯静态导出+S3托管的模式无法支撑仪表盘需要的服务端逻辑（比如管理员权限校验用户订阅状态、Stripe支付回调接口），反而拆分应用的成本更低。

关于是否应该用create-react-app代替Next.js开发仪表盘 #

不推荐换用create-react-app，Next.js反而更适配你的仪表盘场景：

• create-react-app目前已经进入官方维护模式，不再新增功能，路由、代码分割、性能优化等能力都需要手动配置，新项目选型本身就不推荐。
• 你的团队已经有Next.js的使用经验，复用现有技术栈没有额外学习成本，之前积累的构建配置、问题排查经验都可以直接复用。
• Next.js的能力对仪表盘场景的适配度远高于纯客户端渲染的create-react-app：
  • Next.js中间件可以在边缘层直接校验Firebase的用户身份令牌，未登录用户直接触发重定向，不会出现CRA项目常见的「进页面先闪一下内容再跳登录页」的体验问题；
  • Next.js自带API路由能力，不需要额外搭建后端服务，就可以直接处理Stripe创建结账会话、支付回调、用户订阅状态校验等服务端逻辑，用CRA的话这些逻辑还得额外找服务部署，反而增加工作量；
  • Next.js同时支持静态导出、服务端渲染、边缘函数等多种渲染模式，你可以根据仪表盘不同页面的需求灵活选择渲染方式，灵活度远高于仅支持客户端渲染的CRA。

最后补充个实操注意点：如果选择子域名托管独立仪表盘应用，记得在Firebase授权域名列表、Stripe支付配置中添加对应的仪表盘子域名，避免出现跨域拦截问题。

内容的提问来源于stack exchange，提问作者Lee Del Rosario