本文约 3,937 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：它没报错，只是没人管了
插件「已弃用」（abandoned）和插件「出故障」是两回事。出故障你会立刻知道——白屏、报错、功能失效。而已弃用的插件往往表面上完全正常，它继续在你的站点上运行，继续输出内容，只是再也不会有人为它修复新出现的问题。
真正的风险在时间轴上展开：WordPress 主版本升级、PHP 版本升级、浏览器行为变化、第三方 API 下线，这些事件每一个都可能让一个停止维护的插件突然变成严重故障源，或者变成一个无人修补的安全漏洞。而这时你才发现，它已经两年没人碰过，连替代品的数据迁移路径都断了。
幸运的是，WordPress.org 在插件页面上提供了足够多的公开信号来判断一个插件的维护状态，其中有些是官方直接给出的警告文案，有些需要自己拼装数据。本文把这些信号整理成六条，并给出可以一次扫完全站的脚本。
原理分析：WordPress 官方给出的三类弃用提示
WordPress.org 会基于插件的 Tested up to 字段与当前 WP 版本做对比，在插件页顶部展示不同等级的提示。这三类提示的措辞是固定的，看到就能直接下判断：
| 提示文案 | 触发条件 | 严重程度 |
|---|---|---|
| This plugin hasn’t been tested with the latest 3 major releases of WordPress | 落后 3 个主版本 | 高，建议替换 |
| This plugin hasn’t been updated in over 2 years | 两年以上无更新 | 高，事实弃用 |
| This plugin may not be compatible with the latest version | 落后 1–2 个主版本 | 中，观察 |
除了这类官方提示，还有四个需要自己判断的信号：
信号一：支持论坛被关闭。 作者在插件设置里可以关闭支持论坛。关闭论坛不等于弃用（有些作者改为工单制），但结合其他信号看，是强指示。
信号二：Requires PHP 字段缺失或过低。 一个从没声明过 PHP 版本要求的插件，说明作者多年没有更新过 readme，代码里大概率存在 create_function()（PHP 8.0 已移除）、each()（PHP 8.0 已移除）、动态属性（PHP 8.2 弃用）这类与现代 PHP 冲突的写法。
信号三：SVN trunk 长期无提交。 插件页的「Last updated」反映的是 readme 变动，trunk 才反映真实代码改动。
信号四：漏洞库里有未修复条目。 如果 WPScan 或 Patchstack 里该插件存在 Fixed in 为空的漏洞，说明作者已停止响应安全问题，这是最硬的弃用证据。
代码层面还有一类不易察觉的风险：老插件经常在 wp_options 里写入 autoload 数据、或者用 wp_schedule_event 注册了永不清理的定时任务。即使插件被弃用，这些残留仍在拖慢站点，相关内容可以参考 插件数量与性能的关系。
保姆级实操
第一步：先看官方警告
打开插件页，如果有顶部黄框提示，截图记录。同时记录侧栏的 Last updated 与 Tested up to。
第二步：用脚本批量体检已安装插件
下面这段脚本会读取本地已安装插件列表，逐个查询官方 API，输出最后更新时间与兼容声明：
#!/usr/bin/env bash
# check-abandoned.sh —— 批量检查已安装插件的维护状态
cd /path/to/wordpress || exit 1
for slug in $(wp plugin list --field=name); do
# 目录安装的插件可能没有官方 slug，跳过查不到的
json=$(curl -s "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&slug=${slug}&request[fields][sections]=0")
updated=$(echo "$json" | python -c "
import sys, json, datetime
try:
d = json.load(sys.stdin)
if not isinstance(d, dict) or d.get('name') is None:
print('NOT_IN_ORG'); raise SystemExit
print(d.get('last_updated','-')[:10], '| tested:', d.get('tested','-'), '| php:', d.get('requires_php','-'))
except Exception:
print('NOT_IN_ORG')
")
printf "%-30s %s\n" "$slug" "$updated"
done
输出里 NOT_IN_ORG 表示这个插件不在官方目录（可能是商业插件或自研插件），需要走厂商渠道确认。
第三步：查 SVN 真实提交记录
# 查看 trunk 最近提交时间
svn info https://plugins.svn.wordpress.org/contact-form-7/trunk/ | grep "Last Changed Date"
# 看最近几次提交改了哪些文件
svn log -v --limit 5 https://plugins.svn.wordpress.org/contact-form-7/trunk/
如果只有 readme.txt 在动、代码目录一动不动，就是典型的「假更新」。
第四步：交叉查漏洞库
wpscan --update
wpscan --url https://example.com --enumerate vp --api-token YOUR_TOKEN --format cli-no-color
重点看有没有 Fixed in 为空、或者修复版本高于你当前版本的条目。
第五步：评估替换成本
决定替换前先算三件事：数据结构是否可迁移（自定义文章类型 / 自定义表 / 短代码）、短代码在内容里的使用量、以及是否有其他插件依赖它。用下面的命令统计短代码使用量：
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%[your_shortcode%'"
第六步：做弃用插件的隔离处置
如果暂时不能替换，至少做三件事：把它从自动更新白名单外排除（避免更新后崩站）、用 WAF 限制其入口文件的外部访问、以及在预发布站上先验证下次 WordPress 升级是否兼容。
常见踩坑
-
把「最近更新」当成「还在维护」：只改
Tested up to不改代码的插件，实际上没维护。 -
忽略 PHP 升级带来的连锁崩溃：插件在 PHP 7.4 上正常，升级到 8.1 后报
Fatal error: Uncaught Error: Call to undefined function create_function()。升级 PHP 前必须在预发布站全量验证。 -
不检查短代码残留：停用插件后，正文里残留的短代码会以纯文本形式显示给用户，页面很难看。替换前先把短代码清单导出。
-
没备份就删除：删除插件会触发
uninstall.php，可能连带删掉数据表。先做数据库备份。 -
以为插件页显示「兼容 6.x」就是测过的：那是作者自己填的字段。
-
案例： 某资讯站使用一个自定义字段插件，四年前安装，运行一直正常。站点 PHP 从 7.4 升到 8.2 后，后台文章编辑页直接白屏，前台正常。查日志发现该插件在
admin_head钩子里用了动态属性写法，PHP 8.2 起触发Deprecated: Creation of dynamic property并因为该站开启了严格错误级别而中断。该插件最后一次真实代码提交在 30 个月前，支持论坛有 40 多条未解决帖子且作者两年未回复。最终花了一周时间把数据迁移到另一个插件，迁移过程中发现原插件把数据存在自定义表里，导出成本远高于预期。教训是：PHP 版本升级前，必须先跑一遍弃用插件排查。 -
把弃用插件留在自动更新里：老插件的「更新」可能是一次大改，自动装上后直接崩。
总结
六个判断信号按可信度从高到低排列：漏洞库存在未修复条目 > SVN trunk 长期无提交 > 官方弃用提示 > 支持论坛无回复 > 更新时间超半年 > Requires PHP 字段陈旧。
处置策略也分三档：确认弃用且有成熟替代品的，排期迁移；确认弃用但暂无替代品的，隔离加监控（关自动更新、限制入口、列入下次升级前的验证清单）；只是更新慢但作者仍响应的，保留观察。
建议每季度跑一次批量体检脚本，把结果存档对比。长期看，站点上这类插件越少越好——这直接关系到 插件数量与性能的关系，也决定了你做 插件漏洞查询 时的工作量。
