这个坑值得记一笔。发布后自动预热脚本把 sitemap 里所有地址推给 CDN 其中 300 条是已删除文章 预热请求把 404 响应也缓存了 12 小时 用户和蜘蛛访问这些地址拿到的是边缘的 404 源站其实已经 301
刚开始盯着「预热列表来自旧 sitemap 没有做状态过滤」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。预热脚本不校验源站返回码 一律推送；CDN 缓存了 404 并按默认 TTL 保留；404 页面没有设置 no-store。
上来先看 404 是否被缓存
curl -sI https://www.example.com/p/999 | grep -i -E 'HTTP/|age|cache'预热前过滤非 200 地址
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/p/999给 404 加短缓存或不缓存
add_header Cache-Control 'no-store' always;剩下的就是清理已缓存的 404 并重跑预热
curl -X PURGE https://www.example.com/p/999隔了一天再看，现象没变，说明不是偶发。
别只看报错消失，验证要多做一步。已删地址返回源站的 301 或 404 且不被边缘缓存 预热日志里只剩 200 地址。
预热是为了让好页面更快 未加校验的预热等于批量把错误页钉在边缘。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。