CDN 要不要上
很多产品上线后都会遇到一个问题：要不要上 CDN？
有些人觉得 CDN 是大站才需要的东西；有些人一开始就把所有请求都丢给 CDN。其实这两种理解都太极端。
CDN 的核心价值，是把适合缓存和加速的内容放到离用户更近的边缘节点，减少源站压力，降低访问延迟，提高稳定性。但它也会带来缓存失效、调试复杂度、成本和配置风险。
本文参考了官方和标准资料：
- Cloudflare Cache docs
- Cloudflare Default Cache Behavior
- Amazon CloudFront Documentation
- How CloudFront delivers content
- MDN Cache-Control
- MDN HTTP caching
CDN 解决的是什么问题
CDN 不是魔法加速器。它主要解决三个问题。
第一，距离问题。用户离你的服务器越远，网络延迟越高。CDN 把资源缓存到全球边缘节点，让用户从更近的节点获取内容。
第二，源站压力。热门图片、JS、CSS、下载文件如果每次都打到源站，服务器和对象存储都会有压力。CDN 命中缓存后，可以减少源站请求。
第三，稳定性。源站波动时，已缓存的静态资源仍然可以从边缘节点返回，用户体验更稳。
但前提是：你的内容适合缓存。
最应该上 CDN 的内容
最适合 CDN 的，是静态资源：
图片
CSS
JavaScript
字体
视频片段
下载文件
公开附件
文档资源
这些内容变化不频繁，访问量可能很高，用户分布可能很广。CDN 对这类资源收益明显。
CloudFront 官方文档也把 .html、.css、.js、图片文件等作为可通过 CloudFront 分发的典型 Web 内容。Cloudflare 的缓存文档也强调静态资源缓存是 CDN 的基础场景。
如果你的产品已经有大量图片、前端资源、公开文件，上 CDN 通常值得。
不要一开始就缓存所有动态接口
动态接口和静态资源不一样。
用户信息、订单、权限、通知、后台数据、团队项目列表，这些数据通常和用户身份相关，不应该随便缓存。
如果把动态接口错误缓存，可能出现非常严重的问题：
用户 A 看到用户 B 的数据
权限变更后仍看到旧权限
订单状态不更新
后台操作结果延迟出现
接口调试变得困难
Cloudflare 默认缓存行为文档也提醒，默认情况下并不会缓存 HTML 或 JSON 这类内容。这个默认策略背后有道理：动态内容需要非常谨慎。
早期 SaaS 最稳妥的做法是：先缓存静态资源，不要急着缓存用户相关接口。
Cache-Control 是核心
CDN 缓存不是只靠平台按钮，而是要靠 HTTP 缓存头。
MDN 对 Cache-Control 的说明是：它通过响应和请求里的指令控制浏览器和共享缓存如何缓存内容。
常见策略：
静态带 hash 文件：
Cache-Control: public, max-age=31536000, immutable
普通图片：
Cache-Control: public, max-age=86400
需要频繁更新的 HTML：
Cache-Control: no-cache
私有用户数据：
Cache-Control: private, no-store
如果缓存头设计错误，CDN 可能缓存不了，也可能缓存太久。
文件名版本化比频繁清缓存更稳
很多人更新资源后，第一反应是清 CDN 缓存。
清缓存可以用，但不应该成为日常依赖。更稳的方式是文件名版本化。
例如：
app.8f3a1c.js
style.92ab4.css
cover_v3.webp
avatar_user123_20260531.webp
资源内容变了，URL 也变。旧资源可以继续缓存，新资源用新 URL 加载。
这也是很多前端构建工具给静态文件加 hash 的原因。
上 CDN 前先看用户分布
如果你的用户都在同一个地区，源站也在附近，CDN 的速度收益可能没那么明显。
如果用户分布在多个国家或地区，CDN 的收益会更大。尤其是图片、视频、前端资源、公开文件这类大体积资源。
判断时可以看：
用户主要来自哪里
资源平均大小
页面加载瓶颈在哪里
源站带宽是否吃紧
对象存储回源成本是否高
静态资源访问量是否高
不要为了“看起来专业”上 CDN，要为明确的性能和成本问题上 CDN。
CDN 也可能带来问题
CDN 会让系统多一层缓存，也就多一层调试复杂度。
常见问题包括：
用户看到旧图片
CSS 更新不生效
接口返回旧数据
地区之间缓存不一致
缓存命中率很低
源站 header 设置错误
清缓存后仍有浏览器缓存
所以 CDN 不是“开了就完事”。你要能看缓存命中率、响应头、回源次数、流量、错误率。
私有内容不要直接公共缓存
如果资源和用户身份有关，就不要直接公共缓存。
比如发票、合同、私有文件、付费内容、内部图片。即使它们是图片或文件，也不能简单当静态资源处理。
私有内容常见做法是：
先经过业务权限校验
生成短期有效的签名 URL
CDN 只缓存可公开或可安全缓存的部分
必要时走受控下载接口
安全优先于加速。不要为了省一点延迟，把私有数据暴露出去。
什么时候应该上 CDN
以下情况，上 CDN 很值得：
静态资源访问量明显
图片、视频、附件较多
用户分布跨地区
源站带宽压力明显
页面加载主要卡在静态资源
需要降低对象存储回源成本
需要提高公开资源可用性
如果你的产品还在内测，用户很少，资源不大，源站响应很好，可以先不急。
一个上线顺序
对独立开发者来说，可以按这个顺序：
第一步：前端构建资源加 hash
第二步：图片和静态文件设置合理 Cache-Control
第三步：公开静态资源接 CDN
第四步：观察缓存命中率和回源流量
第五步：为图片、下载文件、视频单独优化缓存策略
第六步：非常谨慎地评估动态内容缓存
不要第一天就把所有接口放到 CDN 缓存里。
写在最后
CDN 要不要上，不取决于产品看起来大不大，而取决于资源是否适合缓存、用户是否分散、源站是否有压力、缓存策略是否清楚。
早期最稳的选择是：先把静态资源、图片和公开文件走 CDN；用户相关接口和私有文件先不要缓存；用版本化 URL 和清晰的 Cache-Control 控制缓存行为。
下一篇，我们继续聊可观测性：日志系统怎么搭。
正文到此结束
- 本文标签： Cloudflare cache CSS 压力 CDN
- 版权声明： 本文由HARRIES原创发布，转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
Loading...
![[HBLOG]公众号](https://www.harries.blog/img/qrcode_gzh.jpg)
