同一 App Router 不等于同一产品边界
一上 Next.js App Router，团队容易把官网、文档、登录后产品塞进同一 repo，三周后发布被鉴权绑死。「Next.js 营销站与产品站架构」核心不是能不能同仓，而是发布节奏、缓存与失败域是否一致。可上线默认用路由与包边界隔离：营销要快发布、可回滚、对 SEO 敏感；产品要会话、权限、实时数据。下文用决策树在探索阶段定架构，而不是上线前夜拆仓。
两种站点的失败模式不同
营销失败是错误 canonical、慢 LCP、编辑发不出稿；产品失败是会话泄漏、权限错误、API 超时。同一发布管道会让 SEO 热修等待产品回归。先列风险再谈文件夹。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
渲染策略：SSG/ISR 对会话页
营销页优先静态或 ISR；仪表盘才动态渲染。整站 dynamic 是性能与成本双杀。在 segment 上声明配置，比事后加 cache 头干净。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
鉴权边界画在哪里
未登录营销树与登录产品树在路由与中间件硬隔离。共享 UI 可以，共享 session 域要谨慎。跨子域写清 SameSite、回调与退出路径。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
CMS 与产品数据源不要混用
营销文案走 headless CMS + 预览；产品实体走业务 API。把案例写进产品库会迫使编辑走发版。内容型业务在探索阶段定内容模型所有者。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
同仓 monorepo 的合理形态
共享设计系统与工具链时 monorepo 很香，但入口应拆 apps/marketing 与 apps/product，CI 按路径过滤。共享 token 流水线，不共享发布按钮。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
SEO 属于营销树的责任
sitemap、hreflang、结构化数据在营销应用生成；产品私有页 noindex。同域用路径约定。技术 SEO 审计以营销树为范围。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。
迁移：先分区再拆仓
已混在一起时先按路由与包分区、独立环境变量与 CI，再决定物理拆仓。先让营销获得独立预发与回滚，产品保持原节奏。结合可上线探索→设计→开发→上线节奏，把该项写入验收与预发检查，避免口头对齐后遗漏。结合可上线（KSX Studio）探索→设计→开发→上线节奏，把该项写成可验收产物：负责人、完成定义、预发验证与回滚策略，避免口头对齐后再次发散。
可执行清单
- 1列出营销 vs 产品失败模式与发布频率
- 2为路由段声明 static/ISR/dynamic
- 3中间件隔离登录树与公开树
- 4CMS 预览与产品 API 分源
- 5CI 按 app 路径过滤部署
核心要点
- 架构服务于发布节奏与失败域。
- 营销偏静态与 SEO，产品偏会话与权限。
- 同仓可以，独立部署与责任边界必须在。
常见问题
- 必须拆两个域名吗？
- 不必。路径分区 + 中间件 + 独立部署通常足够。拆域名多出于品牌、cookie 与合规。
- 文档站放哪边？
- 多数跟营销树；若强依赖登录与版本化 API，再靠产品树并谨慎 index。
- 一套 App Router 能搞定吗？
- 早期可以但要预设分区。营销周更、产品日更时拆部署单元。