重点先说
报错：134217728 = PHP 限制 128M，尝试分配 140665380418512 这个数字明显是异常乱数，不是真的要分配这么大内存！ class-wpdb.php 只是报错落脚点，不是根源，WP 核心本身一般不会出这个 bug 常见元凶：采集插件、自动发帖插件、主题自定义查询、数据库损坏、SQL 注入、PHP 版本 bug、无限循环查询（你是导航站，大概率采集 / 自动收录插件）
步骤 1：先开调试，拿到真实堆栈（最关键）
编辑网站根目录 wp-config.php，在 That's all, stop editing! 之前加入：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
刷新报错页面，日志文件：wp-content/debug.log
看日志上面的调用栈，找到是哪个插件 / 主题文件发起的数据库查询，90% 问题在这里
步骤 2：临时急救（先把网站跑起来）
方式 A：wp-config 增加 WP 内存（优先）
define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '1024M');
⚠️ 这个只是 WP 层面，如果服务器 php.ini 限制死 128M，这里修改无效，必须去面板改 PHP 配置
方式 B：宝塔 / 主机面板修改 PHP 配置
找到当前 PHP 版本 → 配置，修改：
memory_limit = 1024M
max_execution_time = 180
保存，重启 PHP。
步骤 3：定位元凶（导航站重点排查）
你是 shturl.c 导航站，这类站点高频踩坑：
- 采集插件、自动收录、wp-autopost-pro、爬虫类插件（最高概率），循环拉取全表、没有 limit、死循环查询
- 主题自带的链接抓取、自动检查死链插件
- 数据库损坏：某张表（wp_posts/wp_options）有坏行、索引损坏，读取时二进制解析错乱，出现超大异常数字
- 恶意 SQL 注入，构造畸形查询
✅ 快速隔离方案：
FTP 进入 wp-content/，把 plugins 重命名为 plugins_bak，此时所有插件全部禁用；
刷新网站，如果恢复正常 → 插件问题，再逐个改回名字启用排查；
如果依然报错 → 主题 / 数据库问题，切换默认 twentytwenty 主题测试WordPress....
步骤 4：数据库修复（出现这种异常大数必查）
进 phpMyAdmin，选中数据库：
- 先完整备份数据库！
- 执行数据表【检查】，有损坏就【修复表】
- 清理超大 autoload 数据（导航站 options 很容易爆）
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';
如果这个值好几 MB，清理垃圾 transient、缓存选项、采集残留数据
步骤 5：特殊情况：PHP 版本 BUG
PHP7.2/7.3 部分版本在解析畸形 MYSQL 返回包时，会出现这种巨大虚假分配字节，升级到 PHP7.4 或 PHP8.1（推荐），很多人升级直接解决，调高内存完全没用。
步骤 6：安全排查（畸形查询有可能注入）
看 Nginx/Apache 访问日志，有没有异常爬虫、带恶意 sql 参数的访问，检查主题 / 采集插件是否没有过滤参数。
排查顺序总结（按优先级）
- 备份网站 + 数据库
- 开启 WP_DEBUG 看堆栈，定位插件
- 全部插件改名禁用测试
- 调高 PHP 内存限制、重启 PHP
- 修复数据库、清理 options 自动加载垃圾
- 切换默认主题、升级 PHP 版本