部署与托管工具

这个类别解决什么问题

把你本地的代码变成公网可访问的服务，并且让每次更新都能安全地发布出去。

什么时候需要

在第一次需要让别人访问你的产品时。这一步可以做得非常晚——很多产品在本地或内网就能验证核心假设。

选择时看哪些指标

这些是评估这类服务时通用的判断维度，不针对任何具体厂商。

构建时间与部署频率限制
是否支持你需要的运行时
自定义域名与 HTTPS 的接入难度
回滚方式
带宽与函数调用的计费方式

中国开发者特别需要考虑什么

托管平台的边缘节点分布决定访问速度。面向中国大陆用户时，平台默认的节点策略未必友好，需要实测。

这一层的成本结构

托管成本由三块构成。构建与部署次数，多数平台在免费档设了上限，超了要排队或升级。运行时的函数调用或常驻实例，按调用次数与执行时间计费，常驻实例即使闲置也在计费。出站带宽，静态站点几乎只有这一项，带接口的产品则是两项叠加。最容易失控的是长耗时请求：一次请求等待几十秒，费用按秒累积。访问量上涨时调用量与带宽线性增长，真正的跳跃点是引入常驻服务和数据库连接。

常见误区

只在预览环境配好了环境变量。正式环境漏一项，构建照样成功，运行时才报错。做法是把所需变量列成清单，发布前逐项对照正式与预览两套配置，而不是靠记忆。
在生产环境上直接改配置再部署，没有回滚点。出问题时只能往前修，用户在等着。做法是每次发布都对应一个可回退的版本，先在预览地址上验证一遍，再切到正式环境。
把耗时任务放在请求里同步等待。托管函数一般有执行时间上限，超时后请求失败，用户已经等了几十秒。做法是拆成入队、后台处理、查询结果三步，请求只负责入队。具体上限以平台文档为准。

从零开始的上手顺序

先在本地用一条命令把项目跑起来，并确认构建产物落在哪个目录。托管平台要的就是这个目录，先说清楚再谈发布。
在平台导入仓库，用默认配置先跑一次构建。第一遍不要写自定义配置，先让最小的路径通，出错时才知道是代码问题还是配置问题。
先用平台分配的临时地址访问页面和接口，正常后再绑自定义域名，等证书签发完成，并确认带 www 与不带 www 两个地址都能打开。
配好正式环境变量，密钥在后台填写而不是写进仓库；然后做一次完整发布，随即手动回滚一次，确认回滚路径真的可用。

在不同业务模式中的作用

saas 前端与 API 的托管

ai-saas 应用层托管；长耗时的模型调用需要单独设计

app 后端 API 与静态资源

api 接口托管与版本发布

digital-product 销售页与交付页，静态托管即可

ecommerce 站点与边缘缓存

常见问题

我可以先不绑域名，直接用平台给的临时地址上线吗？

可以，临时地址适合自己验证和给少数人试用。但它不适合对外推广：用户记不住，链接通常绑在某个项目上，换平台就得重新分发。先跑通流程再绑域名，顺序上没有问题，等到要收钱或做站内 SEO 时再绑也不算晚。

静态托管和云服务器，我到底该选哪个？

看有没有常驻进程。定时任务、消息队列、长连接，或者需要固定出口地址的调用，都属于云服务器更直接的场景。只要你的产品是页面加接口，静态托管配函数就够了，不用自己管系统补丁，运维负担小得多。

部署到边缘节点，国内用户访问会明显变快吗？

不一定，取决于平台在用户所在地区有没有节点，以及回源路径怎么走。这个问题没法从配置上推断，只能实测：在国内网络下测首字节时间和完整加载时间，再决定要不要加一层 CDN、换成别的区域，或者把静态资源单独放到覆盖更广的服务上。

部署频率太高会触发限制吗？

免费档通常有每日构建次数或并发构建数的上限，超了会排队甚至当天被拒。做法是把零散的小改动合并成一次发布，需要反复验证时用预览环境，不要拿正式环境当试验场。具体额度以平台定价页为准。

部署与托管