标签： W3 Total Cache
-
在将 W3 Total Cache、EdgeOne 与 Cloudflare 的主要 HTML 缓存统一延长到 4 天后，我发现新文章发布后，首页和 Sitemap 可能继续命中 CDN 中的旧缓存。本文记录如何在保留普通页面 4 天长缓存的同时，仅将中英文首页和公开 Yoast Sitemap 的 Edge TTL 缩短到 2 小时，并分别通过 EdgeOne 与 Cloudflare 实测缓存过期、重新回源和 HIT 行为。最终在内容新鲜度、缓存命中率和维护成本之间取得更合适的平衡。
-
在将 WordPress 英文站从 /en/ 迁移到独立子域名后，我发现部分新发布的英文译文虽然已经与中文文章建立 Polylang 关联，但中文详情页仍然缺少语言切换器和 hreflang。排查确认，问题来自 W3 Total Cache Redis Object Cache 在多 Host 环境下缓存了旧的 post_translations_relationships 数据，随后 Page Cache 又继续保存错误 HTML。本文记录了 WP-CLI、真实 HTTP Runtime、精确 Object Cache 删除和 Page Cache 验证过程，并说明为什么最终暂时不引入复杂的跨 Host Redis 清理逻辑，而选择保持现有 TTL，让该低优先级问题自然恢复。
-
将 WordPress 英文站从 /en/ 迁移到独立子域名后，我排查了 Polylang 多域名、独立后台 Host、W3 Total Cache Page Cache 与 Redis Object Cache 之间的缓存失效问题。最终确认并修复了英文文章更新后语言首页 Page Cache 未完整失效，以及 posts 对象缓存跨 Host 失效的问题，并将方案整理为 MIT 许可的独立 MU Plugin。真实后台 Update 验证后，Origin 层已能够正确返回最新内容，剩余问题进一步定位到 EdgeOne、Cloudflare 等 CDN 层。
-
在为 WordPress 中英文归档页增加 Adsterra Native Banner 时，前台始终无法及时显示最新模板内容。经过对 WPCode、PHP Snippet、Shortcode、Language Visibility、Block Template、CDN、W3 Total Cache Page Cache 与 Redis Object Cache 的逐层排查，最终确认 www 与 en 不同 Host 下的 W3TC Object Cache 保留了旧版 wp_template。分别清理两个域名上下文的 Object Cache，并重新生成对应 Page Cache 后，中英文广告均恢复正常。此次问题也暴露出现有多域名缓存同步机制对 wp_template 等结构性内容覆盖不足，下一步将重点完善已有 MU 插件，并继续处理首页最新文章仍停留在 7 月 28 日的问题。
-
在再次出现 CPU 告警后，我暂时停止继续追查瞬时负载根因，转而重新启用 W3 Total Cache 页面预缓存，并从 900 秒 × 5 页 的保守配置逐步优化。通过准确统计中英文 Yoast Sitemap，确认真正需要预缓存的页面为 6270 个，并自动生成 www + en 联合 W3TC 专用 Sitemap，每小时同步更新。最终将 W3TC Page Cache、EdgeOne 中文站和 Cloudflare 英文站的缓存生命周期统一调整为 96 小时，同时采用 300 秒 × 7 页 的低批量持续预热策略，在降低冷缓存回源和 PHP 动态生成压力的同时，避免预缓存本身制造新的 CPU 峰值。
-
一次阿里云 ECS CPU 接近 100% 的告警，最终从 Nginx 499、PHP-FPM max_children、Slowlog、W3 Total Cache Object Cache 和 Redis 一路排查到 Page Cache 冷缓存。实测发现服务器仅有 1 vCPU，而 /page/9/ 在 Cold MISS 时 TTFB 高达 10.6 秒，缓存命中后仅约 0.016 秒。最终没有提高 PHP-FPM 并发、关闭 Redis 或开启缓存预热，而是将 W3TC Page Cache 最长生命周期从 1 小时延长到 12 小时，以降低历史页面反复动态生成带来的 CPU 压力。
-
在通过 EdgeOne 屏蔽异常 Sogou UA 流量、解决 WordPress 502 后，阿里云 ECS 仍然偶发 CPU 95%～100% 告警。进一步结合 PHP-FPM Slow Log、Nginx 请求日志和 W3 Total Cache 实测发现，大量带 Query String 的前台请求会导致 W3TC Disk: Enhanced 页面缓存无法复用，使请求重新进入 PHP-FPM，完整执行 Gutenberg、Polylang、Post Views Counter、Redis Object Cache 和数据库查询。正常 URL 第二次请求 TTFB 仅约 0.1 秒，而带参数 URL 每次仍需约 7～11 秒。最终决定不逐个封禁参数，也暂不升级服务器或修改 W3TC 内部逻辑，而是在 EdgeOne 与 Cloudflare CDN 层进行 Query String 缓存键和回源 URL 规范化，从根源减少动态参数造成的缓存穿透。
-
收到包含 8 个中文文章 URL 的内容整改清单后，我没有直接删除 WordPress 文章，而是通过 MU Plugin 保留文章发布状态和系列标题，同时让指定中文页面真实返回 HTTP 404，并限制 REST API、RSS 与 Sitemap 继续输出正文。随后结合 W3 Total Cache、EdgeOne、Cloudflare 和 Polylang 完成缓存排查，最终仅下线清单中的中文文章，对应英文译文继续正常访问。
-
在重新评估技术博客广告变现方案后，我停用了原有的 AdSense 手动广告位，仅保留全站基础代码，并正式启用自动广告。本文完整记录了旧广告缓存排查、源站与 EdgeOne 验证、自动广告格式配置、代码块兼容性测试，以及将页内广告最小间距从 200px 调整为 530px 的过程。最终采用较积极的广告密度，同时关闭意向驱动广告，保留页内广告、底部锚定广告和低间隔穿插广告，以测试自动广告能否在不插入代码块、不过度破坏阅读体验的前提下，提高技术博客的广告变现效率。
-
一份用于同步 Polylang 中英文标签的批处理脚本，长期存在 WordPress 后台标签总数与脚本读取结果不一致的问题。此前两次排查分别修复了 Polylang 翻译关系缓存残留和动态分页导致的数据集变化，但问题仍会复发。最终通过对比 WP-CLI 与直接 PHP 执行环境，确认根因是 get_terms() 命中了持久化的旧 WP_Term_Query 查询缓存。脚本在源标签查询中加入 ‘cache_results’ => false 后，终于从旧的 8915 个标签恢复为正确的 8928 个。本文记录完整排查过程，并总结多语言数据维护脚本在缓存、运行上下文、统计验证和幂等性方面的实践经验。