静态托管成本优化：独立产品的「带宽」与「构建」双线控制
一、当账单开始「无声增长」
独立产品的静态托管成本，在产品的早期阶段往往低到可以忽略——Vercel、Netlify、或 Cloudflare Pages 的免费额度，对于每天几百到几千次页面访问，是完全够用的。
但当产品增长，或者当你在产品中加了「用户可上传的图片/文件」功能后，静态托管的成本可能开始「无声增长」。一个典型的场景是：产品设计了一个「用户头像上传」功能，且头像原图被直接存在了静态托管服务上。随着用户增长，这些文件的带宽消耗可能成为账单上的一个「意外项」。
过去一年，在帮助多个独立产品做托管成本优化后，一个值得记录的经验是：静态托管的成本优化，核心不是「选最便宜的服务商」，而是「在架构上减少不必要的带宽和存储消耗」。这篇文章将复盘具体的优化手段。
二、带宽消耗的三个优化方向
带宽消耗是静态托管成本的最大部分。优化它，有三个方向。
方向一：图片和媒体的「多级分发」。不要把用户上传的图片或媒体文件，直接存在静态托管服务上。更可行的方案是：用对象存储（如 R2、S3、或 OSS）来存储原文件，用 CDN 来做分发。这样，带宽成本从「静态托管服务商」转移到了「对象存储 + CDN 服务商」，且通常后者的带宽定价更友好。
方向二：图片的「按需尺寸」服务。很多产品在所有页面上都用同一张高清原图，不管用户的设备宽度是多少。更优的方案是：用图片优化服务（如 Cloudflare Images、或自建的图片处理服务），根据用户的设备宽度，动态返回合适分辨率的图片。这样，移动端用户可能只下载了桌面端 30-50% 的图片流量，带宽成本对应下降。
方向三：静态资源的「长期缓存」策略。如果你的静态资源（JS、CSS、字体）的文件名中包含了内容哈希（如main.ab12cd34.js），那么这些文件是可以被「永久缓存」的——因为文件名变了，才说明内容变了。在部署配置中，给这类文件设置Cache-Control: max-age=31536000（一年），可以大幅提升回访用户的缓存命中率，减少重复下载。
三、构建分钟数的优化
静态托管服务的第二个成本维度，是「构建分钟数」——每次你 push 代码，触发构建，服务商会按构建实际花费的 CPU 分钟数计费。
对于独立产品，构建分钟数的优化手段包括：
第一，用增量构建。很多现代前端构建工具（如 Vite、Turbo、或 Nx）支持增量构建——它们会缓存上一次构建的结果，只重新构建「发生改变的模块」。对于大型项目，增量构建可以把构建时间从几分钟压缩到几十秒。
第二，在 CI 中做构建产物缓存。即使本地用了增量构建，CI 环境中的构建通常是从零开始的。用构建工具的缓存机制（如 Vite 的cacheDir，或 Turbo 的远程缓存），可以让 CI 中的构建也变成增量式的。
第三，评估「是否需要每次都全量构建」。有些产品的部署流程中，后端和前端是一起构建一起部署的。但如果后端的改动不影响前端，可以做成「前端后端独立构建、独立部署」。这样，前端没改时，就不会消耗前端的构建分钟数。
四、存储容量的优化
静态托管服务的第三个成本维度，是「存储容量」——你部署到托管服务上的文件总大小。
对于大多数独立产品，存储容量本身不会成为成本瓶颈——前端构建产物的总大小，通常在几 MB 到几十 MB 之间，远达不到付费阈值。但如果你在产品中加入「用户上传文件」的功能，且把上传的文件直接存在托管服务上，存储容量可能会快速增长。
优化的核心原则是：静态托管服务应该只存「产品自身的静态资源」（HTML、CSS、JS、图片、字体），而不应该存「用户生成的内容」。用户生成的内容，应该存在对象存储服务上，且只把「访问这些内容的 URL」存在你的数据库中。
五、总结
静态托管成本优化的核心原则，是「在架构上减少不必要的消耗」，而不是「选最便宜的服务商」。
带宽消耗的三个优化方向：图片/媒体用对象存储 + CDN 多级分发、按需尺寸的图片服务、以及静态资源的长期缓存策略。构建分钟数的优化手段：增量构建、CI 中的构建产物缓存、以及前后端独立构建部署。存储容量的优化原则：静态托管只存产品自身资源，用户生成内容存对象存储。
对于独立开发者，托管成本优化的建议是：在产品收入能稳定覆盖托管成本之前，先做架构上的优化（如把用户上传的文件从静态托管迁移到对象存储）；在产品收入稳定后，再评估「是否需要换到更便宜的托管服务商」。好的成本优化，是让用户增长时，单位用户的托管成本在下降，而不是在上升。
资料说明
本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论，不应视为行业事实。可参考 0730 资料来源索引，并在发布前将具体来源贴到对应断言之后。
