选择部署方式

部署平台没有绝对排名。有人告诉你"XX 平台最好"，基本可以确定他没问你的用户在哪。

真正的问题只有四个：你的用户在哪里、应用需要什么运行时、数据放在哪里、出故障时谁来处理。 四个答案定下来，可选方案通常只剩一两个。

这一页解决"选哪一类方式"。具体平台的横向对比在部署平台横向对比。

快速版

1. 先回答四个判断题：用户位置、运行时、数据位置、运维意愿。
2. 内容站和静态工具 → 静态托管，别上服务器。
3. 标准全栈应用、用户在海外 → 框架托管或边缘平台。
4. 长连接、后台任务、特殊二进制、自建数据库 → 容器平台或自有服务器。
5. 国内用户为主 → 先看备案，备案决定服务器位置，不是反过来。
6. 选完必须做一次生产环境演练，再对外。
7. 不要为"以后可能需要"提前养一套复杂基础设施。

四个判断题

1. 用户主要在哪里

境内用户更在意访问稳定和本地生态（微信分享、国内邮件送达、支付通道）；海外用户更容易直接用全球托管服务。

两边都要的话，第一版仍然要选一个主市场。 否则域名、备案、支付、数据合规四件事会同时压过来，每一件都会拖住上线。

境内为主的路径是被备案锁定的：备案必须挂在境内接入商的服务器名下，所以是"备案要求 → 服务器位置 → 平台选择"，不是先挑个喜欢的平台再想办法备案。见备案怎么办。

2. 应用是静态页面还是长期运行的服务

这一条决定了下限成本。

• 静态：文档、落地页、纯前端工具。选静态托管，全球 CDN、免费额度通常够用、几乎零运维。
• 标准全栈：有登录、有数据库、请求-响应模型。框架托管或 Serverless 都行。
• 需要常驻进程：WebSocket 长连接、定时任务、队列消费、要跑特定二进制（ffmpeg、headless 浏览器）、自建数据库。这类要容器平台或自有服务器。

判断方法：你的应用有没有"必须一直活着"的部分？ 没有就别买服务器。

3. 数据在哪里

应用和数据库跨地区，每一次请求都要承担一次跨境往返。几百毫秒的延迟，用户能明显感觉到卡，而且失败概率也会上升。

优先让计算、数据库、对象存储处在相近区域，再讨论单个服务的理论性能。一个同区域的普通数据库，通常比一个跨洋的"高性能"数据库快得多。

4. 你愿意承担多少运维

没有对错，只有你有没有那个时间。如果一个人做产品，运维时间是从开发时间里扣的。

三种常见路线

摆摊自己走的是第三条：.dev 域名、香港节点、Docker Compose、nginx 反向代理，不做 ICP 备案。

这个选择省掉了境内备案的等待，代价是必须接受境内网络表现的不确定性和部分微信分享场景的限制。它不是通用答案，只是和当前阶段匹配的取舍。 具体怎么搭见自建服务器部署。

选型打分表

给每个候选方案按 1—5 分打分，加起来比较：

候选方案：____________________

目标用户访问稳定性        ___/5
对现有技术栈的支持        ___/5
数据库与文件存储的距离    ___/5
日志、备份、回滚能力      ___/5
一个月的完整成本          ___/5
你自己排障的熟悉程度      ___/5
                        ------
总分                     ___/30

最后一项经常被忽略，但它在凌晨两点出故障时权重最高。你熟悉的方案比理论上更好的方案更可靠。

构建时和运行时的区别

这一条会影响你的平台选择，但很多人上线后才发现。

有些配置是构建时被写进产物的，改了环境变量不重新构建就不生效。典型的是前端可见的站点地址、公开的 API 端点、埋点 ID 这类。摆摊的 NEXT_PUBLIC_SITE_URL 就是构建参数，在镜像构建阶段传入，改域名必须重新构建镜像。

有些配置是运行时读取的，改完重启就生效，比如数据库连接串、第三方密钥。

为什么这影响选型：如果你的配置大量属于构建时类型，那么"在平台后台改个环境变量就能生效"的期待会落空，每次都要触发一次完整构建。选平台时要看它重新构建的速度和便利程度，不只看它能不能存环境变量。

详见环境变量与密钥管理。

上线前必须做一次生产演练

在本地开发服务器上一切正常，不代表生产能跑。开发模式和生产构建是两套不同的行为。

1. 用生产命令构建，不是只跑 dev。
2. 用和线上相同的反向代理、相同的环境变量启动。
3. 从公网域名测试登录、第三方回调、受保护页面。
4. 重启服务，确认数据和会话没有意外丢失。
5. 演练一次回滚，演练一次数据库备份恢复。

第 3 步最容易暴露问题。OAuth 回调、支付回调、邮件里的链接都依赖真实的公网地址，用 localhost 测不出来。

我们自己踩过的一个例子：i18n 路由原本用 middleware 的 rewrite 实现，开发模式下完全正常，打成独立产物之后退化成 308 自跳转死循环，整站打不开。这个问题只有做了生产构建演练才会暴露。

常见卡点

验收标准

• 四个判断题都有明确书面答案，不是"都要"
• 候选方案打过分，选的是总分最高而不是最有名的
• 算过一个月完整成本，包含所有分散账单项
• 按量计费项设了预算告警或硬上限
• 分清了哪些配置是构建时、哪些是运行时
• 做过一次完整生产演练，包含公网域名下的登录和回调
• 演练过回滚和备份恢复，不只是"理论上可以"

本章动作

写下四句话：我的主市场是____，运行时需要____，数据放在____，我每周能给运维____小时。

然后选能同时满足这四项的最简单方案。不是功能最多的，是最简单的那个。

下一步

1. 部署平台横向对比——具体平台各自适合什么
2. 自建服务器部署——选了自有服务器怎么落地
3. 环境变量与密钥管理——构建时和运行时的分界
4. 生产环境验收——对外前逐项检查