WordPress 必备插件清单：什么必须有，什么可以省
一个正常的企业站，启用中的插件控制在 8 到 12 个是合理的；超过 20 个，你付的就不是授权费，而是首屏时间、数据库查询数和半夜排障的时间。这份清单不列品牌，只按功能分类给判断标准：每一类达到标准就收手，达不到就换一个，而不是再叠一个。
先算代价：插件不是白装的
WordPress 每次请求都会把启用中的插件主文件 include 进来。规范的插件会用 is_admin() 判断只在后台加载，但相当多的插件不做这个判断——一个只在后台用的备份或 SEO 插件，前台每次访问仍然要执行它的初始化代码、注册它的 hook。
我们在一台 2 核 4G 的云服务器上做过对照：默认主题、零插件时首页是 18 条 SQL 查询、TTFB 约 130ms；装到 12 个常见插件之后，查询数涨到 60 至 90 条，TTFB 到 400ms 以上。再关掉页面缓存插件测一次，查询数还要再加 20 条左右。这个量级在带宽充足时看不出来，一旦并发上来，CPU 先满。
| 启用插件数 | 首页 SQL 查询数 | TTFB 参考值 | 隐性成本 |
|---|---|---|---|
| 0 至 5 个 | 15 至 30 条 | 100 至 200ms | 功能缺失，需要主题补 |
| 8 至 12 个 | 40 至 80 条 | 250 至 450ms | 可控，需要缓存兜底 |
| 20 个以上 | 90 至 200 条 | 600ms 以上 | 冲突概率高，升级易白屏 |
| 30 个以上 | 无法预估 | 1s 以上 | 几乎无法定位问题来源 |
冲突概率是另一半成本。插件两两组合的数量随个数平方增长，20 个插件是 190 对组合，其中任何一对在同一个 hook 上抢执行顺序，表现出来的就是白屏、表单提交跳到 404、结账页空白。真要排查只能二分法停用，一轮下来半小时起步。这也是为什么「插件大全」这种清单本身没意义——别人的 25 个插件里，有 15 个在解决他自己主题的缺陷。
缓存：只看两件事
第一，是否生成静态 HTML 文件，而不只是做对象缓存。对象缓存减少的是数据库查询，页面仍然要跑一遍 PHP；页面缓存直接把结果落成文件，Nginx 能直接返回。第二，清理是否精确——发布文章时能不能只清首页、分类页和这一篇，而不是整站清空。
判断标准之外还有一条排除项：不要同时开两个页面缓存。两套规则各自往 advanced-cache.php 和 .htaccess 里写东西，症状是后台改了内容前台不更新，或者登录用户看到缓存页。选一个，卸载另一个的规则残留。
如果你的站点已经有 Redis 或者主机自带的对象缓存，缓存插件只需要管页面层，别再让它接管对象层。具体怎么配可以看 缓存插件 那一篇。
安全：登录防护加文件完整性
第一，是否管登录：限制尝试次数、改登录入口、强制两步验证，这三件里至少做到两件。第二，是否做文件完整性比对，能把 wp-admin、wp-includes 里被改过的核心文件标出来——这是被挂马之后能不能快速定位的关键。
要注意插件防火墙的作用有限。它在 PHP 层拦截，攻击流量已经进了 PHP-FPM，占用了连接和内存。真正挡量的是服务器层的 Nginx 规则或者 WAF，插件防火墙是第二道。两条一起上容易重复拦截，把正常后台请求也挡掉，表现为保存文章时 403。参考 安全插件 与站点层的加固方案配合使用。
SEO：一个就够，两个必打架
判断标准只有两条：是否同时接管 title、meta description、canonical、sitemap 这四件事；是否与主题自带的 schema 输出不冲突。
两个 SEO 插件同时启用，最典型的症状是页面源码里 <title> 出现两遍，或者 canonical 指向了错误地址。搜索引擎看到两个 title 时的处理方式不可控，收录标题会来回跳。这类问题在后台完全看不出来，必须看源码。SEO 插件 的正确用法是装一个、关掉主题里的 SEO 模块，别反过来。
备份：看恢复，不看备份
判断标准：备份文件是否落在站外，以及能不能一键还原。只把备份写进 wp-content/backup 的等于没备份——主机磁盘挂了、被黑了、被勒索了，这份文件一起没。
第二个标准是恢复时能不能改域名。很多站点的真实需求不是「回到昨天」，而是「把去年的库恢复到测试域名上」。插件如果只能原地恢复，这个场景就得手工来。备份策略和恢复演练的细节在 备份恢复 里展开。
表单：能收信，也要能查到
第一，是否有服务端校验和反垃圾机制。纯前端校验的验证码等于没有，爬虫直接 POST 就过了；honeypot 字段加提交频率限制是成本最低的组合。第二，提交是否落库。只发邮件不存库的表单，一旦 SMTP 出问题或者进了垃圾箱，客户询盘就永久丢了，事后无法追查。
表单插件还是和缓存插件最容易打架的一类。页面被缓存之后，表单里的 nonce 会过期，提交时报「链接已失效」。遇到这种情况，把表单所在页面排除出缓存，比换插件省事。
图片优化：压缩加 WebP
判断标准：上传时是否自动生成 WebP 或 AVIF 并按浏览器能力回退，以及是否清理原图派生出的多余尺寸。一张 4000px 的原图在 WordPress 里默认会生成 4 到 7 个尺寸，加上主题注册的自定义尺寸，单图占用几十 MB 很常见。
要留意的是部分图片优化插件会把图片上传到第三方 CDN 再回源。国内访问这类域名经常绕路，首屏反而变慢，同时图片资源脱离了自己的服务器，迁移时不好处理。能用服务器本地的转换方案（比如 Nginx 的 WebP 模块或 cwebp）就不必上第三方。
统计与电商：什么时候该破例
统计插件属于典型的「可有可无但常被装」。如果只关心 PV、UV 和来源，服务器日志加自建统计就够了。判断标准是脚本体积和加载方式：单文件超过 50KB、同步阻塞加载的统计脚本，会实打实拉高 LCP。GA4 在国内的加载成功率不稳定，很多时候首屏白等三秒就是在等这个脚本超时。
电商是唯一需要放宽插件数量标准的情形。WooCommerce 一装就是十几张新表，商品列表、购物车、结账各是一套查询。此时上限可以放到 20 至 25 个，但必须配对象缓存，并且把商品页和分类页单独做缓存规则。插件冲突 的排查在电商站上更频繁，因为结账流程涉及的插件最多。
五类之外基本可以不加
缓存、安全、SEO、备份、表单，加上图片优化，这六类之外的需求，先用三个问题过一遍：这个功能主题能不能做？能不能用二十行 functions.php 解决？不加会不会影响询盘或下单？三个都是否，就不装。
| 需求 | 插件方案 | 轻量替代 |
|---|---|---|
| 代码高亮 | 语法高亮插件 | 主题自带 pre code 样式，或前台引入一个 30KB 的 JS |
| 面包屑 | SEO 插件里的模块 | 主题模板里手写，或复用 SEO 插件的函数 |
| 相关文章 | 相关文章插件 | 按分类取 4 篇，一次 WP_Query |
| 禁用评论 | 评论管理插件 | 设置 → 讨论里关闭，或 functions.php 里移除支持 |
| 允许上传 SVG | SVG 支持插件 | 过滤 upload_mimes，但要做内容校验 |
比如「禁用区块编辑器前端样式」这件事，装插件纯属浪费，两行代码即可，还能省掉两个 HTTP 请求：
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'global-styles' );
}, 100 );精简的执行顺序
- 导出当前插件清单，标出「不知道为什么要装」的那些。
- 停用并删除确定不用的，注意删除前确认没有其他插件依赖它的函数。
- 装 Query Monitor，看首页查询数、慢查询、以及每个插件贡献的查询条数。
- 按贡献从高到低处理，优先换掉查询最多的那个，而不是装缓存去掩盖。
- 改动后连续观察三天，重点看表单提交和订单流程有没有静默失败。
插件数量本身不是罪，无主和重复才是。一个站如果每半年没人回头看一遍插件列表，通常已经积累了五六个装完就忘的。信科网络在淄博做 WordPress 十一年，接手过的站里，速度问题有一半以上不是服务器不够，而是插件清单没人管。如果不想自己逐个试，可以打 13280692153 让我们先做一次插件体检。