WordPress 性能优化手记系列归档 - 永夜

为什么 English 子站文章浏览量一直是 0：一次 Post Views Counter 与页面缓存兼容问题排查记录

永夜 — Fri, 18 Sep 2026 04:02:12 +0000

排查 English 子站近期文章浏览量长期为 0 的问题，最终确认 Post Views Counter 在 REST API 模式下将 wp_rest nonce 写入长期缓存页面，导致 nonce 失效后计数请求返回 403 rest_cookie_invalid_nonce。通过 MU-plugin 在 WordPress REST 认证前仅针对 PVC view-post 请求刷新失效 nonce，在保留 W3 Total Cache 页面缓存、现有计数模式和 Cloudflare 配置的情况下恢复正常计数。排查过程中还发现 Gutenberg 保存文章时可能使用旧浏览量覆盖 total 的低频边界问题。

为什么 English 子站文章浏览量一直是 0：一次 Post Views Counter 与页面缓存兼容问题排查记录最先出现在永夜。

WordPress 自定义 taxonomy 更新导致 W3TC 全量缓存失效：series 的真实生产修复

永夜 — Thu, 10 Sep 2026 09:59:56 +0000

在 WordPress 多语言生产环境中，修改自定义 taxonomy series 的系列描述后，W3 Total Cache 再次出现整站 Page Cache 全量失效。通过 Page Cache 快照、Full Flush Tracer 与 Nginx 后台日志，最终确认 series 的 edited_term 进入现有兼容插件的 fallback，并调用 w3tc_flush_posts()。本文记录如何仅将 series 加入允许最终一致性的 taxonomy，完成 Git 提交、生产部署与连续两次真实编辑验证，同时区分这一问题与此前已经存在的 Object Cache / Redis 旧对象问题。

WordPress 自定义 taxonomy 更新导致 W3TC 全量缓存失效：series 的真实生产修复最先出现在永夜。

W3 Total Cache 明明设置了 4 天缓存，为什么每天都会失效？一次 Polylang 与 Yoast SEO 联合排查记录

永夜 — Tue, 08 Sep 2026 13:29:28 +0000

W3 Total Cache 的 Page Cache 明明设置了 4 天生命周期，实际缓存却长期活不过一天。经过对缓存文件、*_old ctime、WordPress Hook 和调用栈的持续追踪，最终确认了两条提前触发全量缓存失效的真实路径：Polylang 标签与翻译关系更新触发 edited_term / delete_term，以及 Yoast SEO 的 wpseo_detect_default_seo_data 每日 Cron 通过 WPSEO_Utils::clear_cache() 调用 w3tc_flush_posts()。本文记录两条根因的定位、独立 MU Plugin 修复、真实双语文章发布流程验证，以及修复后 Page Cache 首次存活超过 24 小时的结果，同时保留 Yoast option 实际变化场景尚待进一步验证的部分。

W3 Total Cache 明明设置了 4 天缓存，为什么每天都会失效？一次 Polylang 与 Yoast SEO 联合排查记录最先出现在永夜。

W3TC 定时任务为何创建后又消失？排查 WP-Cron 与 Redis alloptions 陈旧缓存

永夜 — Tue, 01 Sep 2026 11:19:19 +0000

在修复 Yoast Sitemap 500 和 W3 Total Cache 联合预热 Sitemap 之后，继续检查发现 W3TC 的 w3_pgcache_prime 与 w3_pgcache_cleanup 定时任务仍然异常。通过创建随机 Cron Probe 复现问题，最终确认数据库中的 cron option 已更新，但普通 PHP 环境通过 get_option("cron") 读取到的仍是 Redis Object Cache 中陈旧的 alloptions。精准删除 options/alloptions 后，Cron 数据重新与数据库一致，Prime、Cleanup 以及 Linux crond 的生产执行链路均恢复正常。

W3TC 定时任务为何创建后又消失？排查 WP-Cron 与 Redis alloptions 陈旧缓存最先出现在永夜。

WordPress CPU 告警继续排查：Yoast Sitemap 500、PHP 256M OOM 与 W3TC 预热失效

永夜 — Tue, 01 Sep 2026 10:46:44 +0000

此前已经发现 W3 Total Cache 页面缓存长期很难看到超过 2 天的文件，但当时正在批量处理历史文章，不适合立即判断。等历史处理结束后，借这次 CPU 告警继续排查，最终发现联合预热 Sitemap 长期生成失败，根因是 Yoast SEO 生成 post-sitemap.xml 时触发 PHP 256M 内存耗尽并返回 HTTP 500。将 PHP-FPM memory_limit 提升到 512M 后，中英文 Sitemap 恢复 200，联合预热 Sitemap 也恢复自动更新。

WordPress CPU 告警继续排查：Yoast Sitemap 500、PHP 256M OOM 与 W3TC 预热失效最先出现在永夜。

WordPress 再次出现 CPU 告警：从 EdgeOne 异常流量到自适应频控与 JavaScript 挑战

永夜 — Tue, 01 Sep 2026 10:21:09 +0000

一次 WordPress 服务器 CPU 接近 100% 的异常告警，引出了 EdgeOne 短时间内 2 万多次 L7 请求。通过分析缓存状态、客户端 IP 和 URL 分布，确认流量具有明显的分散特征。最终在 EdgeOne 个人版能力范围内，为 www 域名启用独立防护策略，将自适应频控调整为“适中”，并配合 JavaScript 挑战和流量防盗刷，降低异常自动化流量对源站的影响。

WordPress 再次出现 CPU 告警：从 EdgeOne 异常流量到自适应频控与 JavaScript 挑战最先出现在永夜。

PublishPress Series 3.1.3 升级实录：PHP 8.5 Issue 已修复，却又遇到 Gutenberg 系列编号回归

永夜 — Thu, 20 Aug 2026 03:36:56 +0000

2026 年 8 月 6 日，我曾在 PHP 8.5 环境中排查 WordPress 插件兼容性问题，并向 PublishPress Series 官方 GitHub 仓库提交 Issue #1163，报告 SplObjectStorage::attach() 与 contains() 在 PHP 8.5 下产生 Deprecated 警告。升级至 PublishPress Series Free 3.1.3 后，我重新检查了这个问题：Issue 已由上游关闭，生产环境源码中的旧调用也已经全部替换为 offsetSet() 与 offsetExists()，实际运行测试得到 DEPRECATIONS: 0，确认旧问题已经解决。不过，这次升级又带来了一个新的 Gutenberg 保存异常：新发布的中文文章虽然仍然属于正确的系列，却不再自动获得 Series Part 编号，而对应 English 文章仍然正常。全站扫描最终发现 6 篇受影响中文文章。恢复正确编号后，全站缺失 Series Part 的文章重新归零。为了避免修改插件源码或降级版本，我增加了一个最小 MU Plugin，在 Gutenberg REST 保存完成后调用 PublishPress Series 自己的排序函数自动补齐编号。本文随后作为修复后的第一篇真实中文文章发布，并成功自动成为「WordPress 性能优化手记」第 21 部分，完成最终生产验收。

PublishPress Series 3.1.3 升级实录：PHP 8.5 Issue 已修复，却又遇到 Gutenberg 系列编号回归最先出现在永夜。

WordPress 7.0 + PHP 8.5 服务器配置全面审计：PHP-FPM、OPcache、Redis、RDS 与 WordPress 调优实战

永夜 — Fri, 07 Aug 2026 12:26:35 +0000

在解决 WordPress 首页性能问题后，对当前服务器进行了完整配置审计，重点检查 Nginx、PHP-FPM、OPcache、Redis、W3 Total Cache、阿里云 RDS/MySQL 以及 WordPress 应用层。最终将 PHP-FPM 最大工作进程从 10 提高到 14，调整 OPcache 内存与 Interned Strings 配置，关闭 Gutenberg 实时协作，并为 SlyTranslate 调试日志增加日志轮转；同时保留大量已经运行健康的参数不变，形成一套更适合当前网站长期运行的服务器配置基线。

WordPress 7.0 + PHP 8.5 服务器配置全面审计：PHP-FPM、OPcache、Redis、RDS 与 WordPress 调优实战最先出现在永夜。

WordPress 动态首页从 19 秒降到 1 秒以内：Post Views Counter 热门文章查询性能问题排查与 MU Plugin 优化实战

永夜 — Fri, 07 Aug 2026 03:30:25 +0000

本文记录一次 WordPress 动态首页性能问题的完整排查与优化过程。绕过 EdgeOne、Cloudflare 和 W3 Total Cache 后，发现中文首页真实动态生成时间接近 19 秒。通过 PHP-FPM slowlog、MySQL EXPLAIN 与实际 SQL 基准测试，最终定位到 Post Views Counter 的热门文章排行榜查询：完整 wp_posts.* 参与 SUM、GROUP BY 和 ORDER BY，导致 MySQL 5.7 创建磁盘临时表。通过 MU Plugin 将查询改造成“轻量排名 + Top N 完整文章加载”的两阶段结构后，中文动态首页降至约 0.83～0.89 秒，英文首页稳定在约 0.87～0.96 秒，同时保持排行榜顺序、浏览量和 Polylang 语言过滤正确。

WordPress 动态首页从 19 秒降到 1 秒以内：Post Views Counter 热门文章查询性能问题排查与 MU Plugin 优化实战最先出现在永夜。

WordPress 升级 PHP 8.5 后的插件兼容性排查：该修的修，该停的停，该等上游的等

永夜 — Thu, 06 Aug 2026 12:32:53 +0000

将 WordPress 生产环境升级到 PHP 8.5 后，PHP-FPM 日志中出现了多项插件兼容性警告。本文记录对 TMS Extensions for Polylang、Nimble Page Builder、SyntaxHighlighter、Yoast SEO 和 PublishPress Series 的逐项排查：停用已经失去实际用途的 Nimble Page Builder，为 SyntaxHighlighter 实施三处最小兼容性补丁，对无法稳定复现的 Yoast SEO 问题暂不修改，并将 PublishPress Series 的问题提交给上游。整个过程以正常生产环境是否受影响为判断依据，而不是盲目追求清除所有 Deprecated 和 Notice 日志。

WordPress 升级 PHP 8.5 后的插件兼容性排查：该修的修，该停的停，该等上游的等最先出现在永夜。

WordPress 性能优化手记 系列归档 - 永夜