pre-caching：让网站缓存提前就绪
内容提要
pre-caching 是一款开源缓存预热工具，通过读取网站 Sitemap 主动发起 GET 请求，提前触发 CDN 或 Nginx 缓存，减少新页面发布、缓存清理或过期后首次访问的回源延迟。它支持并发与 QPS 限速、压力保护、lastmod 增量筛选和复检，并输出 JSON 报告。文章还介绍了构建部署、参数配置、与 Nginx proxy_cache/fastcgi_cache 结合的方法，以及“清理—预热—复检”的发布流程。
延伸解读
预热效果取决于缓存规则与 URL 一致性
pre-caching 通过主动 GET 请求触发 CDN 或 Nginx 缓存，但页面能否写入缓存仍由 Nginx、CDN 和源站响应决定。实际收益受源站耗时、缓存规则、缓存容量以及访客访问的 URL 与预热 URL 是否一致影响，不能据此承诺固定加速倍数。若 Sitemap 中的 URL 与访客实际访问的 URL 不一致，预热可能无法覆盖真实流量。
默认限速保守，压力保护可能中止任务
工具默认单并发、最高 1 QPS，每次请求后至少休息 1 秒，非 HIT 请求还会按耗时增加休息，因此 RATE=1 是上限而非实际速度。默认压力保护开启时，首次请求超时即可中止后续工作。客户端超时后源站可能仍在处理请求，遇到保护中止应先定位慢页面和源站瓶颈，再决定是否重跑，避免盲目重试加重源站负担。
增量预热依赖 Sitemap 的 lastmod 可靠性
使用 LASTMOD 参数可按 Sitemap 的 lastmod 筛选近期变更页面，但 Sitemap 缺少有效 lastmod 的页面仍会被请求，因此增量预热能否减少工作量取决于 Sitemap 是否提供可靠的修改时间。文章修改后可能同时影响首页、分类页和归档页，若这些页面没有准确更新 lastmod，应纳入独立 Sitemap 或安排全量预热。
发布流程应遵循清理、预热、复检顺序
内容更新后若旧缓存仍有效，直接访问可能命中旧内容，因此建议按清理、预热、复检的顺序组织发布流程。HIT 只能说明命中了缓存，不能证明内容就是刚发布的版本，关键页面需结合页面标识或业务内容抽查。复检命中率仅覆盖首轮待确认页面，不等于全站命中率，退出码 0 也不表示每个页面都已 HIT。
Q&A
pre-caching 是什么？它主要解决什么问题？
pre-caching 是一个开源缓存预热工具，通过读取网站 Sitemap 主动发起 GET 请求，提前触发 CDN 或 Nginx 缓存，从而减少新页面发布、缓存清理或过期后首次访问的回源延迟。
pre-caching 的工作原理是什么？它支持哪些功能？
它基于 Sitemap 发起 GET 请求，支持并发控制、QPS 限速、压力保护、lastmod 增量筛选和复检，并输出 JSON 报告。它不执行 JavaScript，也不自动下载页面引用的资源。
如何构建和部署 pre-caching？
需安装 Go 和 Git，克隆源码后运行 release.sh 选择架构构建二进制，再复制到服务器并配置 precache.env 文件，设置 Sitemap 地址、并发数、超时等参数即可运行。
pre-caching 如何与 Nginx 缓存结合使用？
根据站点架构选择 proxy_cache（反向代理）或 fastcgi_cache（PHP-FPM），配置公共缓存条件（如仅 GET/HEAD、无 Cookie 等），并设置 X-Cache 头供工具读取。无需额外安装缓存插件。
更新内容后，推荐的发布流程是什么？
建议按“清理—预热—复检”顺序：先清理旧缓存，再运行 pre-caching 预热（可结合 lastmod 增量筛选），最后复检确认缓存状态，并输出 JSON 报告用于监控。
pre-caching 的输出报告和退出码如何解读？
报告包含 HIT、MISS、EXPIRED 等状态统计，首轮命中率按 HIT ÷ (HIT+MISS+EXPIRED+STALE+UPDATING+REVALIDATED) 计算。退出码 0 表示正常完成，1 表示配置或获取失败，3 表示服务不可用率超阈值，4 表示压力保护中止，130 表示被信号中断。
