![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24-1024x664.png)
![[图3：执行核心升级时返回 524 No Reason Phrase]](https://media.shuijingwanwq.com/2026/07/3-28-1024x500.png)
最近几天，我对博客的多语言、后台入口和 CDN 架构进行了多项调整：
- 将英文站从
/en/迁移到en.shuijingwanwq.com - 将 WordPress 后台迁移到
admin.shuijingwanwq.com - 中文主站继续使用 EdgeOne
- 英文站和媒体子域名使用 Cloudflare
- 保留 W3 Total Cache 的 Page Cache 与 Object Cache
- 针对 Polylang、W3TC、SlyTranslate 等兼容问题增加了若干修复代码
这些调整单独来看都有明确目的：
- 英文站独立域名有利于多语言站点管理
- 后台独立域名可以绕过前台 CDN，降低后台操作受到 CDN 超时和缓存规则影响的概率
- 不同 CDN 分别承载中文站、英文站和媒体资源，可以兼顾访问速度与流量成本
- Page Cache 与 Object Cache 能明显降低 WordPress 动态生成页面的开销
但随着调整不断增加，我开始发现一个更值得重视的问题：
当前架构虽然能够运行，但正在逐渐依赖多个补丁、MU Plugin 和插件源码修改维持兼容。
如果继续遇到一个问题就增加一段代码，短期可能可以解决故障，长期却会增加 WordPress、插件和 PHP 升级后的兼容风险。
因此，我决定暂时停止继续增加修复代码，先对整套架构进行一次重新评估。
一、触发本次架构复盘的问题
最初发现的问题，是英文文章页面底部原本正常显示的 CTA 插入逻辑突然失效。
检查代码后发现，原来的语言判断仍然依赖：
strpos($_SERVER['REQUEST_URI'], '/en/')
英文站迁移到独立子域名以后，英文文章地址已经变成：
https://en.shuijingwanwq.com/2026/...
请求路径中不再包含 /en/，因此英文页面被错误识别成中文页面。
这个问题本身并不复杂，改为优先使用 Polylang 的语言接口，并以当前域名作为兜底即可。
但随后又发现了一个影响更大的现象：
在
admin.shuijingwanwq.com后台发布新文章后，www.shuijingwanwq.com首页仍然显示旧内容。
即使在 W3 Total Cache 后台点击“清除所有缓存”，中文首页和英文页面的缓存也不一定被正确清除。
这说明问题已经不只是某一段 CTA 代码没有适配新域名，而是：
后台操作域名
↓
WordPress 当前运行上下文
↓
Polylang 语言域名
↓
W3TC Page Cache
↓
Redis Object Cache
↓
EdgeOne / Cloudflare
整条缓存失效链路都需要重新确认。
二、当前架构到底有没有走错
经过这一轮分析，我认为目前的架构并没有整体走错，但部分实现方式需要收敛。
当前结构大致如下：
WordPress 单站点
│
├── admin.shuijingwanwq.com
│ └── 登录、编辑、发布和后台管理
│
├── www.shuijingwanwq.com
│ ├── 中文前台
│ └── EdgeOne
│
├── en.shuijingwanwq.com
│ ├── 英文前台
│ └── Cloudflare
│
└── media.shuijingwanwq.com
├── WordPress 上传文件
└── Cloudflare
其中，Polylang 官方支持使用子目录、子域名或独立域名区分语言，因此将英文站迁移到 en.shuijingwanwq.com 本身属于正常的多语言 URL 方案。
真正增加复杂度的是：
admin.shuijingwanwq.com
它不是任何一种内容语言，却承担所有文章保存、插件更新和缓存清理操作。
这意味着，从后台触发的操作不能再简单地把当前请求域名当作前台缓存目标。
不过，即使后台继续使用 www，未来新增日语、德语等语言以后，也仍然需要处理多个语言域名的 Page Cache。因此，独立 admin 域名并没有创造一个完全不存在的问题，而是让中文默认语言也进入了跨域缓存协调范围。
从长期目标来看，独立后台域名仍然可以保留，但必须建立清晰的边界：
admin只负责后台管理，不属于任何语言，也不应成为 Page Cache 的最终目标域名。
三、Polylang 为什么也会涉及“缓存”
在分析过程中，我一度对“Polylang 会缓存各语言首页 URL”这件事产生疑问。
Polylang 是多语言插件，为什么也要参与缓存？
后来重新区分后发现，这里的缓存并不是完整网页 HTML 缓存。
Polylang需要反复计算：
zh → https://www.shuijingwanwq.com/
en → https://en.shuijingwanwq.com/
主题、语言切换器、导航菜单、SEO 插件以及其他组件，都可能在一次请求中多次获取某种语言的首页地址。
Polylang 提供的 pll_home_url()，就是用来返回指定语言首页地址的接口。
因此，Polylang 所缓存的是语言 URL、语言配置等计算结果，而不是最终页面。
目前站点中的缓存可以分为四层：
| 缓存层 | 主要内容 | 负责组件 |
|---|---|---|
| 多语言 URL 计算 | 语言对应的首页和内容 URL | Polylang |
| Object Cache | 文章、选项、术语和查询对象 | WordPress、W3TC、Redis |
| Page Cache | 最终生成的完整 HTML | W3 Total Cache |
| CDN Cache | 边缘节点上的 HTML 和静态资源 | EdgeOne、Cloudflare |
这四层缓存的职责并不相同。
真正的问题不是缓存层数太多，而是内容更新后，各层缓存是否能够形成完整、可靠的失效闭环。
四、W3TC Page Cache 与 Object Cache 都需要保留
在这次架构复盘中，我没有打算通过关闭 W3TC Object Cache 来简化问题。
此前已经做过实际性能测试。测试结果表明，性能明显下降的根本原因并不是 CDN 本身，而是 W3 Total Cache Page Cache 被关闭。
重新开启 Page Cache 后，TTFB、FCP 和 LCP 等指标均明显改善。此前的实测结论是：
CDN + Page Cache + Object Cache
三者共同构成完整的缓存体系。
其中：
Page Cache
负责保存完整 HTML 页面，例如：
首页
文章页
分类页
标签页
系列归档
Feed
分页页面
Page Cache 与域名关系非常密切。
同一个 WordPress 安装下：
www.shuijingwanwq.com
en.shuijingwanwq.com
会分别生成自己的页面缓存。
未来增加新的语言域名后，也会继续增加相应的页面缓存目录。
Object Cache
负责缓存：
文章对象
分类和标签对象
WordPress 配置项
数据库查询结果
Polylang 配置
主题和全局样式相关对象
Object Cache 可以减少 PHP 和 MySQL 重复读取与计算，对文章数量较多的 WordPress 站点依然具有实际价值。
所以后续的正确方向不是关闭缓存，而是修复缓存失效机制：
保留 Page Cache 与 Object Cache，确保后台操作可以正确更新对应语言域名的缓存。
五、TMS Extensions for Polylang 仍然需要保留
本次评估中，也检查了现有插件是否可以被 Polylang 原生功能替代。
TMS Extensions for Polylang 提供了多个适用于区块主题的多语言区块，包括：
- Language Switcher Advanced
- Language Visibility
- Menu by Language
- HTML Sitemap for Polylang
其中，Menu by Language 可以为不同 Polylang 语言映射不同的 WordPress Navigation 菜单。
我的网站目前实际使用了这个菜单区块。
因此，即使 Polylang 自身已经提供语言切换相关区块，仍然不能完整替代当前使用的 Menu by Language 功能。
最终结论是：
TMS Extensions for Polylang 需要继续保留。
但此前为了处理兼容问题，曾直接修改过该插件文件。后续需要把这部分修改恢复为官方版本，并通过以下方式之一解决：
- 使用插件提供的 Hook 或 Filter
- 在独立兼容插件中增加防护
- 向插件作者提交问题或补丁
- 等待上游版本正式修复
不能继续把直接修改插件源码当作长期方案。
六、已经直接修改的两个第三方插件需要处理
最近一轮调整中，已经有两个第三方插件被直接修改：
TMS Extensions for Polylang
SlyTranslate
这些修改短期解决了具体问题，但也带来了明显风险：
- 插件升级后，本地修改会被覆盖
- 无法直接判断当前文件是否仍与官方版本一致
- 出现问题时，很难区分是插件自身故障还是本地修改导致
- 后续迁移到客户网站时，无法依赖手工修改插件文件
- 服务器重装或插件重新安装后，修复可能丢失
因此后续需要建立一个明确原则：
第三方插件目录中的文件必须尽量保持官方原始状态。
可以接受的扩展方式包括：
WordPress Hook / Filter
独立普通插件
MU Plugin
wp-config.php 常量
插件官方提供的 Provider 或扩展接口
但 MU Plugin 也不能无限增加。
真正需要控制的不是“是否存在自定义代码”，而是：
代码是否集中
职责是否单一
是否依赖公开接口
停用后能否恢复
升级后是否会被覆盖
七、现成、开源、免费的方案能解决多少问题
在继续自己编写代码之前，需要优先确认是否已经存在成熟的开源方案。
经过初步梳理，目前可以分为几类。
1. Cloudflare 自动清理
Cloudflare 官方 WordPress 插件提供 Automatic Cache Management。
文章、页面、附件或评论被新增、修改或删除时，它可以清理相关 Cloudflare 缓存 URL；主题切换和主题自定义也会触发缓存更新。
因此，英文站的 Cloudflare 缓存清理不一定需要自行调用 Cloudflare API。
不过当前后台运行于 admin 域名，启用前仍需要确认插件生成的清理 URL 是否会正确指向：
en.shuijingwanwq.com
而不是：
admin.shuijingwanwq.com
所以目前 Cloudflare 插件继续保持禁用，等源站 W3TC 缓存链路稳定后再评估。
2. EdgeOne 自动清理
WordPress 插件目录中已经存在面向腾讯云 EdgeOne 的自动缓存清理插件。
例如 Naibabiji Cache Purger for EdgeOne 宣称支持：
- 文章发布、更新和删除后自动清理
- 首页缓存清理
- 分类和标签归档清理
- 作者和日期归档清理
- 评论批准后清理相关文章
- 与 W3 Total Cache 等缓存插件联动
这说明 EdgeOne API 签名、缓存清理和错误处理不一定需要全部自行实现。
不过，这类插件仍需要先审查以下问题：
是否支持独立 admin 后台域名
是否根据 Polylang 文章语言生成 URL
是否会错误清理 en 域名
是否支持未来增加的语言域名
是否会与 W3TC 重复触发
API 凭据如何保存
因此，它可以作为第三阶段的优先候选，但目前不直接在生产站点启用。
3. W3TC 多语言 Page Cache
这一层暂时没有发现能够完全满足当前结构的即插即用插件。
标准插件通常可以处理：
一个 WordPress
一个前台域名
一个 CDN
而当前实际需求是：
一个 WordPress
一个独立后台域名
多个 Polylang 语言域名
不同语言域名使用不同 CDN
这部分可能仍然需要少量自定义协调代码。
不过，自定义代码的职责必须严格限定为：
根据文章所属的 Polylang 语言，找到正确前台域名，并调用 W3TC 已有的缓存清理接口。
不能重新实现 W3TC，也不能顺便承担 CDN、翻译、后台 URL 和其他不相关功能。
4. SlyTranslate 平替
目前可以找到其他 Polylang AI 翻译插件，但还没有确认存在一个可以完整替代当前需求的方案。
当前需求不仅是普通短文本翻译，还包括：
智谱 GLM-5.2
长篇 WordPress 文章
Gutenberg 区块结构
复杂 HTML
代码块原样保留
超长输出
中英文文章关联
因此，不能仅因为存在其他 AI 翻译插件，就立即替换现有方案。
更现实的目标是：
- 恢复 SlyTranslate 官方文件
- 尽量通过 Provider、Hook 或独立 MU Plugin 调整请求
- 不再直接修改插件内部文件
- 后续再单独测试其他开源插件是否能够达到当前翻译质量与结构保留要求
八、独立 admin 域名是否继续保留
经过重新评估，我决定暂时保留：
admin.shuijingwanwq.com
原因有三点。
1. 后台可以绕过前台 CDN
WordPress 登录、插件升级、文章保存和媒体操作，不再直接经过 EdgeOne 的前台缓存和加速链路。
2. 后台地址更清晰
对于自己维护的网站和未来客户网站：
admin.example.com
比把后台入口混在普通前台域名中更容易解释和管理。
3. 多语言缓存问题本身仍然存在
即使后台恢复到：
www.shuijingwanwq.com/wp-admin/
英文站和未来其他语言域名的 Page Cache 仍然需要单独清理。
独立 admin 域名只是让中文域名也进入跨域协调范围，而不是创造了整个多语言缓存问题。
不过，保留 admin 有一个前提：
后续不能继续通过零散代码，让每一个插件分别适配 admin。
正确做法应该是建立稳定边界：
admin
→ 只负责后台管理
Polylang
→ 负责识别文章语言和语言域名
W3TC
→ 负责源站 Page Cache 与 Object Cache
EdgeOne / Cloudflare
→ 负责各自边缘缓存
九、重新确定后的实施顺序
经过这次暂停和分析，后续计划调整为以下几个阶段。
第一阶段：盘点并冻结当前改动
先不继续增加新插件和新代码。
需要完成：
列出所有 MU Plugin
列出所有 WPCode 代码片段
确认两个被修改插件的文件差异
保存官方版本与当前版本对比
记录每段兼容代码的作用
目标是先明确当前站点到底有哪些自定义行为。
第二阶段：修复 W3TC 源站缓存闭环
这一阶段只处理：
admin 后台发布或更新文章
↓
读取文章所属 Polylang 语言
↓
取得该语言正式前台域名
↓
清理对应文章、首页和相关归档的 W3TC Page Cache
需要支持未来新增的语言域名，不能写死：
www
en
而应动态读取 Polylang 语言配置。
Object Cache继续保留，并尽量依赖 WordPress 和 W3TC 原生失效机制。
第三阶段：恢复后台一键清理所有语言缓存
后台点击一次“清除所有缓存”后，应当可以清理：
www
en
未来新增语言域名
共享 Object Cache
admin 本身不是内容站点，不应被当作语言页面缓存目标。
第四阶段：接入 CDN 自动清理
在源站缓存稳定之后，再分别评估：
Cloudflare 官方插件
EdgeOne 自动清理插件
优先使用现成、开源、免费的插件。
只有现成插件不能正确处理 Polylang 和独立后台域名时，才增加最小范围的适配代码。
第五阶段：取消第三方插件源码修改
最终目标是：
TMS Extensions for Polylang
→ 恢复官方版本
SlyTranslate
→ 恢复官方版本
自定义需求
→ 通过公开 Hook、Provider 或独立兼容插件完成
十、本次复盘后的最终结论
经过这一轮分析，目前可以比较明确地得出以下结论。
继续保留
Polylang 多语言域名
en.shuijingwanwq.com
admin.shuijingwanwq.com
media.shuijingwanwq.com
W3 Total Cache Page Cache
W3 Total Cache Object Cache
Redis
EdgeOne
Cloudflare
TMS Extensions for Polylang
暂时停止
继续增加零散 MU Plugin
继续直接修改第三方插件
立即启用 Cloudflare 插件
立即安装 EdgeOne 自动清理插件
同时调试源站缓存和 CDN 缓存
后续重点
先盘点
再恢复 W3TC 缓存闭环
然后处理一键清理
最后接入 EdgeOne 和 Cloudflare
十一、阶段性总结
这次最重要的收获，并不是立即找到了一段可以解决所有问题的 PHP 代码。
真正有价值的是，在继续增加补丁之前停了下来，重新明确了各个组件的职责：
Polylang 负责语言
W3TC 负责源站缓存
Redis 负责对象缓存
EdgeOne 与 Cloudflare 负责边缘缓存
admin 负责后台入口
现在的架构并不是完全不可用，也没有必要推倒重建。
真正需要避免的是：
每出现一个新问题，就直接修改插件或增加一段只针对当前域名的代码。
经过这次重新评估，至少已经明确：
- 哪些组件必须保留
- 哪些源码修改需要撤销
- 哪些需求可以优先寻找开源插件
- 哪些部分确实需要少量自定义适配
- 后续应该按照什么顺序继续
这次暂停并不是停止优化，而是为了让接下来的调整重新变得可控、可验证，也更适合作为以后客户网站的可复用实践。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复