你的 WordPress 站点正在流失内存——教你如何阻止

发布: 1周前 (2026年1月12日 GMT+8 23:04)

6 min read

原文: Dev.to

Source: Dev.to

页面加载的隐藏成本

当访客加载页面时，WordPress 在后台会执行大量操作：

PHP 启动并加载所有 WordPress 核心文件。
每个已激活的插件都会被加载——即使该页面并不需要它们。
加载你的主题。
WordPress 执行一系列数据库查询。
所有挂钩（hooks）和过滤器（filters）被触发。
页面被组装并发送到浏览器。

每一步都会消耗内存和时间。插件越多，开销就越大。

PHP 有内存限制（通常为 128 MB 或 256 MB）。超过限制会触发致命错误，例如：

Fatal error: Allowed memory size of 134217728 bytes exhausted

即使未超过限制，使用 100 MB 内存的页面也会明显比使用 30 MB 内存的页面慢。

什么占用的内存最多？

Page builders（Elementor、Divi、WPBakery）– 每次请求 50–80 MB。
WooCommerce 与大型商品目录一起使用。
加载大型库却很少实际需要的插件。
编写不良的自定义代码。

数据库膨胀

WordPress 几乎把所有内容都存储在数据库中：文章、设置、用户信息、插件数据。一个快速站点每页可能运行 20–30 条查询，而优化不佳的站点在单个请求上可能运行 500+ 条查询。

过多查询的典型来源：

未优化的插件。
主题反复查询相同的数据。
效率不高的自定义代码。
过多插件功能重叠。

为什么数据库会增长

文章修订 – 每次编辑都会创建新行。累计一万条以上的修订。
孤立数据 – 删除文章或插件时，有时会留下引用不存在对象的行。
过期的瞬态 – 某些插件创建的瞬态从不过期或未被清理。
自动草稿和回收站 – 项目会在数据库中保留最长 30 天。
孤立的 cron 任务 – 当插件被移除，其计划任务可能仍然存在，尝试运行已不存在的代码。

孤立的定时任务

WordPress 的调度系统（wp‑cron）会运行后台任务，例如发布预定的文章、发送电子邮件或清理数据。如果注册了定时任务的插件被删除，任务可能会无限期地残留，浪费资源并有时导致错误。已经发现有站点保留了 100 多个来自多年以前已移除插件的孤立定时任务条目。

如何获取可见性

你无法修复看不见的问题。像 Query Monitor 这样的工具非常适合深度调试，但更简洁的一体化解决方案是免费插件 Hungry Resource Monitor。它提供：

顶级资源消耗者的仪表盘。
一键清理修订、瞬态缓存和孤立数据。
所有 cron 任务的列表，并突出显示孤立任务。
检测未使用的插件和主题。
可选的每周电子邮件报告。

完整披露： 该插件由本文作者开发，但它是免费且在本地运行——不会将数据发送到其他地方。

您今天可以采取的实际步骤

限制文章修订

在 wp-config.php 中添加以下行：

define('WP_POST_REVISIONS', 5); // Keep only 5 revisions per post

您也可以使用 WP‑CLI 或专用的清理插件来删除旧的修订。

删除未使用的插件和主题

每个已停用的插件仍会在每次页面请求时加载，除非将其彻底删除。移除未使用的代码可以降低内存占用并降低潜在的安全风险。

审计自动加载的选项

WordPress 会在每次请求时加载所有标记为 autoload = 'yes' 的选项。大量自动加载的条目会显著拖慢站点。运行以下查询以找出占用最大的条目：

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

考虑将不必要的选项设置为 autoload = 'no'，或直接将其清理掉。

安排定期清理

无论是使用插件还是 WP‑CLI，设置一个例行任务（例如每周一次），以执行以下操作：

删除旧的修订。
使过期的瞬态失效或删除。
移除孤立的 postmeta 以及其他未使用的数据。
清理孤立的 cron 任务。

Bottom line

WordPress 性能并不是靠单一的神奇修复。它在于了解资源消耗的所在，并定期清理不可避免的杂乱。首先安装 Hungry Resource Monitor，查看仪表盘，并执行上面的实用步骤。你的站点将不再“泄漏”内存，运行会更加顺畅。