部署平台横向对比
静态托管、框架托管、边缘平台、容器平台、自有服务器各自的舒适区和边界，以及国内访问怎么处理。
上一页定了"选哪一类"，这一页解决"这一类里选谁"。
先说明这一页不写价格数字。托管平台的免费额度、套餐边界、按量单价改动很频繁，写死在文档里等于给你一个会过期的错误答案。这一页给你判断维度和必须自己核对的清单。
快速版
- 纯静态内容 → 静态托管，几乎零成本零运维。
- Next.js 且用户在海外 → 框架官方托管最省心。
- 要全球低延迟、能接受运行时限制 → 边缘平台。
- 要常驻进程但不想管系统 → 容器平台。
- 要完整控制或有特殊运行时 → 自有服务器。
- 国内用户为主，先解决备案和线路，平台是次要问题。
- 注册前用下面的六项清单去平台官网核对当前规则。
五类平台的定位
| 类别 | 你交出去的 | 你换回来的 | 边界在哪 |
|---|---|---|---|
| 静态托管 | 动态能力 | 极低成本、全球 CDN、几乎零运维 | 不能跑服务端逻辑 |
| 框架托管 | 部分运行时控制 | 零配置部署、预览环境、和框架深度贴合 | 长连接、后台任务受限，按量费用需盯 |
| 边缘平台 | Node.js 完整 API | 全球低延迟、冷启动快、成本低 | 运行时不是完整 Node，部分库不兼容 |
| 容器平台 | 系统层控制 | 能跑任意镜像 + 托管数据库 | 成本高于前三类，可观测性依赖平台 |
| 自有服务器 | 你的时间 | 完整控制、成本可预测 | 安全、备份、故障全自己扛 |
各类的舒适区
静态托管
适合：博客、文档站、落地页、纯前端工具、营销页。
如果你的页面在构建时就能确定内容，这一类是最优解。没有服务器意味着没有服务器故障。
不适合：需要登录、需要读写数据库、内容随用户变化。
框架托管
适合：用框架官方推荐路径的标准全栈应用，尤其是团队需要每个分支自动生成预览链接。
它最大的价值是开发体验：推代码就部署，不用配 nginx、不用管证书、不用想构建缓存。
要注意的：个人免费套餐通常限制非商业用途，产品一旦开始收费就要看清条款；带宽、构建分钟、函数调用、日志保留分别计费，账单是加起来的。
不适合：国内用户为主，以及需要长连接或长时间后台任务的场景。
边缘平台
适合：面向全球用户、以 API 和轻后端为主、希望冷启动快成本低。
最大的坑是运行时兼容性。 边缘运行时不是完整的 Node.js，很多依赖原生模块或 Node 内置 API 的库跑不起来。选它之前先确认你的关键依赖能用——特别是数据库驱动、图片处理、加密相关的库。
不适合：依赖大量 Node 生态原生模块的项目，以及需要长时间运行的任务。
容器平台
适合：已经有 Docker 镜像、需要常驻进程、想要托管数据库但不想自己运维。
这一类是"介于 PaaS 和服务器之间"的位置。给你容器级别的控制，同时帮你处理证书、域名、扩缩容。
要注意的：平台的计费模型差异很大，有的按资源规格月付，有的按实际用量。而且平台自身的产品形态变动比较频繁——早期的免费共享方案可能已经停止接收新项目，网上的旧教程经常已经失效。注册前看官网当前文档，不要照着博客文章操作。
自有服务器
适合：有特殊运行时要求、需要跑定时任务和常驻进程、想要成本完全可预测、或者就是想自己掌握全部环节。
摆摊自己走的是这条路。真实体感是：部署本身不难，难的是备份、监控、安全更新这些没人催你做的事。 具体见自建服务器部署。
不适合：不想学 Linux 基础运维、或者产品还在验证阶段完全不需要这些控制权。
注册前必须核对的六项
平台规则会变，所以核对流程比结论重要。选定候选后，去官网定价页和文档逐项填：
平台名：____________ 核查日期：____________
1. 免费额度具体是什么，超出后怎么计费：____________
2. 免费/个人套餐允许商业用途吗：____________
3. 有哪些独立计费项（带宽/构建/函数/存储/日志/出网流量）：____________
4. 能不能设预算硬上限，不只是告警：____________
5. 运行时限制：单请求超时____秒，能不能跑常驻进程____
6. 我的关键依赖在这个运行时能跑吗：____________第 4 项最容易被跳过。只有告警没有硬上限的平台，一次流量异常就可能产生一笔你没预期的账单。
第 6 项建议直接做验证：把你项目里最"重"的那两三个依赖，在目标平台上跑一个最小 Demo，比读兼容性文档可靠。
国内访问是独立问题
如果你的用户在国内，平台选择只是问题的一半。另一半是线路。
三种情况分别处理：
| 情况 | 做法 |
|---|---|
| 已备案 + 境内服务器 | 正常路径，访问最稳 |
| 未备案 + 境外节点 | 选靠近的境外区域（如香港、新加坡、日本），接受不确定性 |
| 部署在全球平台但国内慢 | 见下面的分流方案 |
境外平台在国内慢，通常慢在两个地方：DNS 解析被指到了对国内线路不友好的入口，以及入口到源站的回程路由绕远。
常见的处理方向，按维护成本从低到高：
| 方向 | 原理 | 代价 |
|---|---|---|
| 换解析入口 | 让国内用户解析到更友好的入口地址 | 依赖第三方维护的服务，稳定性无保证 |
| 国内外分流解析 | 智能解析把境内境外流量分到不同源 | 要维护两套部署，配置复杂 |
| 境内 CDN 回源境外 | 境内节点接流量，回源到境外应用 | 境内 CDN 通常要求域名已备案 |
| 直接部署境内节点 | 从根上解决 | 需要备案 |
注意最后两个方向都绕回备案。境内 CDN 加速通常要求域名已完成备案，所以"用 CDN 绕过备案"这条路一般走不通。如果国内是你的主市场，老实走备案是成本最低的路。
社区维护的免费优选入口适合快速验证效果，但不建议用在生产环境——它可能在任何时候停止服务，而你不会收到通知。
迁移成本怎么估
选平台时顺手问一句：如果三个月后要搬走，最麻烦的是什么？
| 绑定类型 | 迁移难度 | 怎么降低 |
|---|---|---|
| 只用了构建和托管 | 低 | 不用刻意做什么 |
| 用了平台专有的数据库 | 中 | 确认有标准协议的导出方式 |
| 用了平台专有的存储/队列/KV | 中到高 | 在代码里加一层薄封装，别到处直接调 |
| 用了平台专有的运行时 API | 高 | 尽量用标准 Web API 而不是平台扩展 |
不必为了"可迁移"牺牲开发效率，但知道自己被绑在哪里，比事后发现搬不走要好。
常见卡点
| 卡在哪 | 可能原因 | 试试这样 |
|---|---|---|
| 照教程操作发现功能没了 | 平台产品形态变了 | 只看官网当前文档 |
| 项目在边缘运行时跑不起来 | 依赖用了 Node 原生模块 | 先用最小 Demo 验证关键依赖 |
| 收费后被提示违反条款 | 免费套餐限非商业用途 | 开始收费前读一遍当前条款 |
| 账单突然变高 | 只设了告警没设上限 | 设硬上限，或换固定计费方案 |
| 国内访问时快时慢 | 解析入口不稳定 | 用真实国内网络多点测试再决定方案 |
| 想用 CDN 绕过备案 | 境内 CDN 也要求备案 | 主市场是国内就走备案 |
| 换平台发现搬不动 | 深度用了平台专有能力 | 提前给专有能力加一层封装 |
验收标准
- 候选平台不超过三个，每个都填完了六项核对清单
- 核对日期写在了记录里
- 关键依赖在目标运行时跑过最小 Demo
- 按量计费项设了硬上限或换成了固定计费
- 确认了商业用途是否被套餐允许
- 用真实目标网络测过首页、登录、支付回调，而不是只测首页
- 知道自己被绑在哪些平台专有能力上
本章动作
从真实目标网络测一次，不要用你自己的开发网络。
测这四个路径而不只是首页：首页、登录、一个需要读数据库的页面、一个第三方回调地址。首页是静态的话，它快不代表应用快。
下一步
- 选择部署方式——如果还没做完四个判断题
- 自建服务器部署——选了自有服务器
- 域名、DNS 与业务邮箱——域名解析和发信
- 备案怎么办——国内为主的必经环节
来源
- 各平台定价、额度、运行时限制以其官网当前文档为准，本页不复制具体数值
- 境内 CDN 的备案要求以服务商当前接入条件为准（核查日期 2026-08-31）