缓存命中率低，不一定意味着CDN没有价值。以动态接口为主的网站，本来就有大量请求不适合共享缓存；少数大文件还可能占据多数传输流量。排查前先问清楚报表的分母是全部请求、可缓存请求，还是传输字节，并把静态资源与业务接口分开观察。
先挑出真正值得缓存的对象
按URL路径、资源类型、请求次数和回源流量排序，找到高频但反复回源的公开资源。后台页面、购物车、用户资料与带私有权限的下载，应先确认隔离策略，不应为了改善总命中率而统一强制缓存。
Cloudflare缓存性能文档区分MISS、过期、重新验证和不具备缓存资格等情形。这些状态可以帮助建立排查思路，但各平台名称与统计口径并不完全相同，需对照所用服务的说明。
检查同一内容是否被拆成太多缓存键
假设同一张公开图片存在/hero.webp?campaign=a与/hero.webp?campaign=b两个地址，而源站确实返回相同内容。如果查询参数进入缓存键，访问可能分散到不同副本。反过来，width=400与width=800若影响图片尺寸，就不能随意合并。
| 变化项 | 核对问题 |
|---|---|
| 查询参数 | 它改变内容、权限还是仅用于统计？参数顺序有无影响？ |
| Cookie | 是否因无关Cookie导致绕过缓存？是否确有用户差异？ |
| 请求头 | 语言、设备或编码是否改变响应？变体是否正确区分？ |
| URL版本 | 同一文件是否频繁生成新路径，导致热度被打散？ |
不要先删参数再观察是否“变快”。应先比对内容摘要、响应头和权限，证明可以共用副本。缓存键的作用可参考Cloudflare缓存键文档，具体配置仍按实际平台验收。
源站响应策略与CDN规则是否一致
检查Cache-Control、过期时间、Set-Cookie及平台的覆盖规则。no-cache并非简单等于“绝不存储”，它强调复用前验证；no-store限制存储，private针对共享缓存有不同含义。处理前应按RFC 9111和供应商文档核对，不要只看字段里是否出现cache字样。
Vary用于表达响应取决于哪些请求头。如果业务按语言返回不同正文，却没有正确区分变体，盲目提高缓存时间可能把错误版本保存更久。若配置看似允许缓存但仍不断回源，继续检查对象大小限制、刷新任务、淘汰和访问分布。
用一组小样本验证改动
- 选一类公开资源，记录原始规则与命中、回源、错误基线。
- 每次只调整一项，重复访问同一对象并核对内容版本。
- 同时测试参数变体和不同权限账号，排除错误合并。
- 比较相同窗口的回源字节及响应时间，再决定是否扩展。
缓存优化的目标是减少重复传输且保持正确内容，不是追求一个脱离业务的百分比。涉及登录态时，配合双账号串号风险检查一起验收。
作者：lgd。资料核对：2026-10-08。本文采用AI辅助整理；示例与配图用于说明方法，不代表本站实测数据。具体功能和限制请以所用产品的当前文档及配置为准。
