缓存不是开了开关就等于命中。要看二次请求、Cache-Control、参数 URL 和动态接口。
缓存的目标是：让可缓存资源在边缘直接应答，降低回源、提高并发。判断“有没有生效”，不要只看面板文案。
------------------------------------------------
一、最小验证法
------------------------------------------------
1. 确认域名已开启对应缓存模式，并已保存、节点已同步。
2. 选一个稳定 URL（建议静态：/static/app.css 或一张图片）。
3. 连续请求两次：
- 第一次允许 MISS（回源并写入）
- 第二次应 HIT 或命中率上升
4. 修改规则后先“清缓存”，再测，避免旧对象干扰。
------------------------------------------------
二、控制台指标怎么读
------------------------------------------------
- 缓存命中率很低：不一定是故障。若站点以动态接口、带随机参数 URL、已登录 HTML 为主，命中率天然低。
- 静态站/图床/下载站命中率长期 <5%：才需要怀疑规则未生效或源站禁止缓存。
- 清缓存后命中率先跌再升是正常曲线。
------------------------------------------------
三、源站响应头会直接否决缓存
------------------------------------------------
若源站返回：
Cache-Control: no-store / private
Set-Cookie 导致 HTML 被当作用户私有
Pragma: no-cache
则边缘通常不应强缓存 HTML。先改源站策略或只缓存静态扩展名。
------------------------------------------------
四、这些情况最容易“看起来没缓存”
------------------------------------------------
1. URL 带时间戳、token、广告参数，每次都是新 key。
2. 首页是动态 PHP，会话 Cookie 齐全。
3. API 路径被误开缓存，反而造成串数据——这类应禁止缓存。
4. 节点未同步完就测试。
5. 只测了一次请求就下结论。
------------------------------------------------
五、建议策略
------------------------------------------------
- 静态资源（js/css/图片/字体）：长缓存 + 版本号/哈希文件名。
- HTML：短缓存或按业务关闭。
- 支付/用户/API：永不缓存。
- 变更发布：先更新源站，再按目录/URL 精准清缓存，避免全站盲清导致回源雪崩。
命中率是结果，不是开关。用“同一 URL 二次请求 + 响应头 + 日志”三者交叉验证。