日期: 2026年7月14日
-
在 WordPress、Polylang、W3 Total Cache、Redis 与多域名架构下，后台通过 admin 子域名发布文章或清理缓存后，www 与 en 前台仍可能读取旧的页面缓存和对象缓存。本文通过对比源站、CDN、WP_Query 与 Redis 缓存结果，定位到 W3TC 按 Host 隔离对象缓存的问题，并利用缓存组版本机制，配合自定义 MU Plugin，实现语言首页、文章查询缓存及 WPCode 配置缓存的跨域同步失效，同时保留中英文站必要的缓存隔离。
-
近期博客先后启用了英文子域名、独立后台域名、多 CDN、W3 Total Cache Page Cache 与 Redis Object Cache，并针对 Polylang、W3TC、TMS Extensions for Polylang、SlyTranslate 等兼容问题增加了多项调整。随着缓存失效、语言识别和插件升级风险逐渐显现，本文暂停继续增加补丁，对现有多域名架构进行一次阶段性复盘，明确哪些组件继续保留、哪些第三方插件源码修改需要撤销，以及后续应按照“改动盘点、恢复 W3TC 缓存闭环、实现多语言一键清理、最后接入 EdgeOne 与 Cloudflare 自动刷新”的顺序推进，使整套方案重新变得可控、可维护并具备复用价值。
-
本文记录了在 WordPress 中使用 SlyTranslate 接入智谱 GLM-5.2 翻译技术长文时，从连续 504 超时到最终成功生成英文文章的完整排障过程。经日志分析发现，主要问题分别是模型请求的 `max_tokens` 被限制为 256，导致大量译文以 `finish_reason=length` 被截断，以及 SlyTranslate 使用三倍字符长度判断失控生成，对中文翻译为英文产生误判。通过 MU Plugin 将 GLM-5.2 的最小输出上限调整为 1024、关闭思考模式，并将长文本增长阈值由 3 调整为 6 后，翻译任务在约 9 分钟内完成。最终生成的英文文章保留了全部 Gutenberg 区块顺序、图片、列表和 54 个 Code Block Pro 代码块，普通正文无中文残留，Polylang 关联及英文前台访问均正常。当前方案已经解决长文翻译的稳定性与结构完整性问题，但英文自然度和术语准确性仍有进一步优化空间。