预热是做什么的
预热（Push 预取）把指定 URL 提前拉取并缓存到边缘节点，常用于版本发布、活动开始前削峰：用户第一次访问时就直接命中边缘缓存，不必等待回源。代价是预热会立即产生回源流量并占用源站带宽，如果文件较多还可能对源站形成冲击。它与刷新是方向相反的动作——刷新删除缓存，预热灌入缓存，两者经常配合使用。
基本信息
| 作用 | 把热点文件提前拉到边缘，减少首访回源 |
|---|---|
| 对象 | URL 列表，需可被 CDN 正常回源访问 |
| 代价 | 产生回源流量，源站带宽压力前移 |
| 与刷新 | 刷新等于删缓存，预热等于灌缓存，方向相反 |
典型使用场景
- 大促或活动开始前，把首页与主图提前预热避免首访回源
- 版本发布后先刷新再预热，确保边缘拿到的是新版本
- 直播开场前预热播放页与静态资源，降低瞬时回源压力
- 新版本上线前的灰度验证：先预热部分节点观察效果
提交预热
提交预热
aliyun cdn PushObjectCache --ObjectPath 'https://cdn.example.com/static/app.js'
tccli cdn PushUrlsCache --Urls 'https://cdn.example.com/static/app.js'
# 提交后查进度，并用 curl 检查边缘是否已有缓存预热与刷新对比
| 维度 | 预热 | 刷新 |
|---|---|---|
| 作用 | 把内容写入边缘缓存 | 让边缘缓存失效 |
| 流量影响 | 立即产生回源流量 | 随后回源量上升 |
| 典型时机 | 活动与发布前 | 内容更新后 |
| 顺序 | 先刷新再预热 | 与预热配合 |
预热不绕过源站错误：源站 404 或 403 时预热同样失败，先直连源站验证可访问性。
怎么预热才有效
预热最容易失效的原因有两个：一是源站本身不可访问或返回错误状态，边缘拉取到的就是错误响应，预热完成后用户照样看不到内容；二是预热的 URL 与用户实际访问的 URL 不一致，例如带有查询串或大小写差异，导致预热了却没能命中。因此提交前先用直连请求确认所有 URL 返回正常，再对照访问日志统计真实请求的 URL 形态，按实际形态提交；预热完成后再抽样请求一次，确认命中缓存的响应头状态。