架构选型
按任务，决定每一部分如何交付。
公开营销页和内容页，默认采用 Astro 静态生成（SSG）。页面在访问之前生成好，访客从托管网络获取准备好的 HTML。
需要每次请求都更新的内容，或私有的高交互应用，会评估其他交付方式。选择取决于页面任务和访问要求。
私有高交互应用采用独立约定范围的 SPA 与后端；公开内容需要每次请求更新时，可考虑服务端渲染；其余公开内容采用静态生成，需要交互时增加针对性的集成。
已确认的内容与源码生成经过检查的发布版本；边缘网络把 HTML 和资源交给访客与爬虫；读取页面无需实时查询 CMS。
按场景选择架构
选型前先回答四个问题：页面是否需要被搜索引擎收录？以阅读内容为主，还是以应用交互为主？需要被索引的内容是否必须随每次请求更新？是否需要访问受保护的后端？
| 页面场景 | 交付方式 | 选择理由 |
|---|---|---|
| 营销页、文章与服务介绍 | Astro SSG | 可被搜索的内容已经包含在 HTML 中，无需运行页面渲染服务，也无需持有后端凭据。 |
| 带表单、搜索或预约的内容页 | SSG + 按需集成 | 内容保持静态，只为需要交互的部分添加 JavaScript。优先接入专业服务；需要访问受保护资源时，再增加小型服务端 API。 |
| 内容必须随每次请求更新的公开页 | Astro SSR | 当搜索引擎需要直接从 HTML 读取动态变化的内容时，考虑服务端渲染。这会增加需要运维与监控的运行时。 |
| 私有门户与高交互工作台 | SPA + BFF | 客户端导航与数据缓存更适合频繁交互。这类系统作为独立应用项目，单独约定交付与维护范围。 |
SSG 让首屏交付更简单，但普通链接跳转会加载一份新文档。内容网站适合这种取舍；工作台内的频繁导航则需要不同的模型。
- 构建时
- 已确认的文案、图片、源码和可选的 CMS 内容成为构建输入。Astro 在发布之前生成 HTML 与资源。
- 访问时
- 托管服务交付已生成的文件。普通链接加载另一份文档，需要交互的部分再增加脚本。私有工作台有不同的导航与数据需求。
明确保留技术取舍。
静态页面需要重新构建才能发布编辑，普通导航会加载新文档。每次请求更新的公开内容、私有工作台和受保护的定制流程，会增加运行时责任。这些选择，需要自己的范围、成本和恢复方案。
内容默认静态交付，例外来自明确的业务需要。
外部服务
把业务任务，接到合适的系统。
按需要连接表单、预约、邮件订阅与电商服务。公开内容保持可读，选定服务处理其专业任务。
每项连接，都需要负责人、费用、访问模型和故障处理预期。集成脚本与嵌入内容，也要检查对页面的影响。
托管网络向访客交付内容；访客操作调用表单、预约或支付服务；需要受保护访问的定制操作，通过服务端 API 再到达后端。
- 专业系统
- 电商和支付平台管理交易流程。我们连接访客旅程，并明确配置、账户与持续费用由谁负责。
- 受保护的定制操作
- 功能需要访问受保护后端时，使用小型服务端 API 或 BFF（服务于前端的后端层）。私有应用的交付与维护范围单独约定。
- 故障处理
- 检查成功与失败状态。预约服务故障不应阻挡访客读取已发布的信息；提供合适的替代联系路径。
明确动态功能的边界
支付等专业功能交给专门的平台。如果定制功能必须访问受保护的后端，就通过小型 BFF（服务于前端的后端层）仅开放所需操作；凭据留在服务端，不进入公开的 HTML 或 JavaScript。
应用与其 BFF 保持同源，并一起维护。登录、密码找回等流程归属应用侧，避免公开营销站持有后端密钥，或额外维护第二套鉴权层。
表单或预约服务发生故障时，已发布的内容仍可继续访问。静态交付减少了依赖，但托管、DNS 与外部集成仍需要明确负责人和恢复方案。
一次完整的集成，也包含责任与故障处理。
访问与安全
让公开内容与私有系统保持边界。
读取公开静态页面，无需数据库凭据或管理员会话。构建环境、托管账户、CMS 与外部服务，仍需各自的访问控制。
凭据留在服务端。私有应用和 BFF 保持明确的访问边界；搜索控制不能代替授权。
公开文件直接交付访客；私有请求经过身份验证和服务端授权，才能执行受保护的操作；密钥留在服务端环境，不进入公开资源包。
- 公开发布
- 检查生成的 HTML 和客户端资源，避免意外发布私密内容或凭据。管理功能与公开阅读体验分开。
- 受保护访问
- 在服务端授权受保护的操作，只开放必要 API，并由所属应用管理登录。
- 运营责任
- 维护源码仓库、部署系统、域名、CMS 和服务账户的访问权限。检查依赖，明确事件发生时由谁响应。
减少公开运行时依赖，只减少一部分工作；其余系统仍需要照看。