接手过多个出海项目，发现一个很普遍现象：很多团队上线 CDN 之后，就直接丢一边不管，从来不去看缓存命中率指标。等到用户反馈海外打开慢、源站带宽跑满，排查才发现命中率只有 50% 出头，大部分请求全部跨洋回源。
节点再多，如果缓存策略不合理，等于白搭。缓存命中率不是一个虚的指标，直接对应源站负载、回源带宽、海外终端访问耗时。静态资源业务，正常生产环境建议尽量冲到 88%‑95% 区间。下面结合实际踩坑经历讲整套落地调优手段。
一、命中率低下常见根因
- URL 携带大量无业务意义随机参数，每一个不同参数都被当成全新请求，无法命中缓存；
- 源站返回 Cache‑Control 头不规范，max‑age 设置太短，或者直接设置 no‑cache；
- 静态、动态接口混在一起，统一一套缓存规则，动态接口大量占用缓存空间，挤压静态资源；
- 资源更新频繁，没有使用缓存刷新 / 预热，旧缓存未失效，新资源反复回源；
- 部分海外边缘节点访问频次低，资源被 LRU 淘汰，导致冷启动大量回源。
二、基础配置实操（360CDN 控制台落地要点）
- 过滤 URL 无效参数 很多业务会带跟踪、统计类随机参数，这类参数不改变资源内容，需要配置忽略参数，保证相同资源生成同一个缓存 key，这是提升命中率最高效的一步。不要直接全部忽略参数，避免业务依赖 get 参数区分资源的场景出现业务错乱。
- 按资源类型差异化配置 TTL
- 图片、js、css、字体包：TTL 设置较长，数天级别；
- 经常变更的静态页面：缩短 TTL，配合更新后主动刷新；
- 动态接口、登录鉴权相关接口：关闭缓存，禁止缓存存储。
不建议无脑把 TTL 拉到最大，会引发版本更新之后用户长期读取旧缓存的线上故障。
- 对齐源站响应头 源站返回的 Cache‑Control、ETag、Last‑Modified 会参与 CDN 缓存判断。尽量源站和 CDN 侧策略对齐，避免两边策略冲突，出现缓存不生效。
- 资源预热，解决海外节点冷启动问题 出海业务大版本上线、活动发布前，使用 URL 预热，把核心静态资源推送到海外边缘节点，避免大量用户首次访问全部回源。注意控制预热并发，不要把源站打垮。
Nginx 源站侧配套参考配置
#静态资源缓存头配置示例
location ~* \.(jpg|png|gif|js|css|woff2)$ {
expires 7d;
add_header Cache-Control "public";
}
#动态接口禁止缓存
location ~* ^/api/ {
expires -1;
add_header Cache-Control "no-store,no-cache";
}提示：CDN 控制台配置优先级高于源站响应头，生产调试需要留意，避免两边策略冲突。
三、主流 CDN 缓存相关能力对比（出海视角）
| 对比维度 | 360CDN | Cloudflare | 传统公有云 CDN |
|---|---|---|---|
| 缓存 key 自定义 | 支持指定忽略部分 URL 参数 | 参数过滤高级功能付费 | 基础过滤，自定义能力弱 |
| 分区域命中率统计 | 支持按地区查看命中率，方便定位海外低命中节点 | 免费版无细分区域统计 | 大盘数据为主，细分维度少 |
| URL 预热能力 | 批量预热，支持海外节点预热 | 免费版预热配额有限制 | 配额较少，调用限流严格 |
| 缓存规则粒度 | 支持路径、后缀、请求头多维度配置 | 规则集模式，配置流程复杂 | 主要基于文件后缀配置 |
四、常见踩坑总结
- 只看整体命中率，忽略分区域数据。很多时候国内命中率很高，东南亚、拉美等海外区域命中率很低，整体数据被拉高，问题被掩盖；
- 过度调大 TTL，追求高命中率，线上出现资源版本错乱；
- 动态接口开启缓存，引发用户拿到别人会话数据，造成业务故障；
- 资源更新只改源站，不做缓存刷新，用户持续读取旧缓存。
五、日常运维建议
- 将缓存命中率纳入监控告警，针对海外重点区域设置告警阈值；
- 上线新业务、大版本迭代之后，重点观察 2‑3 天命中率变化；
- 低命中率资源，梳理 URL 特征，针对性调整缓存规则，而不是笼统全局修改；
- 大促、版本发布前，提前预热核心资源，规避突发回源洪峰。
缓存命中率不是越高越好，需要结合业务更新频率做权衡，在访问性能、资源实时性之间找到平衡点。
参考文档：360CDN 缓存策略官方文档