静态站点的边界
Astro、Next.js static export、docs、landing page 和内容站通常适合静态部署。关键是产物目录可完整打开，deep link 和资源路径正确。
检查项
Output folder
是否有明确的 `dist/`、`out/` 或 build 输出目录？
Server runtime
是否依赖 API routes、SSR、worker、cron 或长进程？
Secrets
是否需要数据库 URL、token、SSH key 或 provider credentials？
Health
是否需要 health endpoint、进程状态和日志？
Rollback
是否需要按服务回滚，而不是只替换静态文件？
VPS 的边界
只要项目需要后台进程、端口、Docker/Compose、数据库连接或任务队列，就不要伪装成静态站点。用 CLI/VPS 路径更容易保留日志和恢复能力。
混合项目怎么选
很多项目可以拆开：静态前端走静态发布，API/worker 走 VPS 或自托管控制面。页面内链应该把用户带到对应部署入口。
落地步骤
1
检查 build output
如果产物可被静态服务器直接提供，先试静态站点路径。
2
检查 runtime
如果需要服务端运行时，走 CLI/VPS 或自托管路径。
3
检查验证方式
静态检查 deep links/assets；服务检查 health/logs/status/rollback。
常见问题
Next.js 应该选哪条？
静态导出可走静态站点；需要 server runtime、API routes 或 SSR 时走服务部署。
Astro 应该选哪条？
默认静态输出适合静态站点；使用 SSR adapter 或服务端逻辑时走服务部署。
VPS 部署一定更复杂吗？
是更完整，但也带来日志、health、进程状态和回滚路径，适合真正需要运行时的项目。
相关主题
继续沿着同一条部署路径看。
Appaloft 的 SEO 页面按真实部署任务组织。每个主题页都应该把用户带到下一步，而不是停在孤立介绍。
Deployment decisions
用检查清单和选择页把搜索用户带到正确部署入口，而不是停在抽象概念。
Static site publishing
从 build 输出、浏览器上传、CLI 部署到一键部署按钮，覆盖静态站点的主要入口。
Own server deployment
把控制面、CLI、服务器、回滚和 Cloud 协作边界连在同一个自部署主题里。
GitHub deployment
用 GitHub Actions 把仓库事件接到 Appaloft 部署路径，并保留显式 workflow。
AI deployment
让 agent 先识别项目形态，再选择 skill、CLI、静态发布或 Cloud 控制台路径。