本文约 3,178 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：要不要跟着升最新版
WordPress 每年发 3–4 个主版本（6.4、6.5、6.6…），中间还有几十个小版本。站长常见困惑：
- 每个版本都升，怕插件不兼容；
- 不升，又看到”某某版本存在高危漏洞”的新闻；
- 老站点跑着 5.x，还能不能用？
要回答这些，得先理解 WordPress 的版本策略——它和很多软件不一样。
原理分析：WordPress 的版本策略
关键事实一：WordPress 没有 LTS（长期支持）版本。
这和 Ubuntu、Node.js 不同。WordPress 官方明确表示：安全更新只针对最新的主版本，不会给旧分支单独发安全补丁（只有极严重漏洞的历史极少例外）。
- 你跑 6.5，官方发布 6.5.3 修漏洞 → 你能收到；
- 官方发布 6.6 → 之后 6.5 分支不再有安全更新；
- 你还跑 6.5，后来发现的漏洞就永远没补丁。
这意味着长期停在旧主版本是有安全风险的。
关键事实二：小版本自动更新，主版本不是。
| 类型 | 例子 | 默认行为 |
|---|---|---|
| 小版本（安全/维护） | 6.5.1 → 6.5.2 | 默认自动更新 |
| 主版本（功能） | 6.5 → 6.6 | 默认不自动更新 |
| 主题、插件 | — | 默认自动更新 |
在 wp-config.php 里控制：
// 关闭所有自动更新
define( 'AUTOMATIC_UPDATER_DISABLED', true );
// 只允许小版本（安全更新）自动更新 —— 推荐
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// 全部自动更新（含主版本，有兼容风险）
define( 'WP_AUTO_UPDATE_CORE', true );
// 完全不更新核心
define( 'WP_AUTO_UPDATE_CORE', false );
推荐 minor（这也是默认值）：既保证安全补丁及时打上，又不会因主版本自动升级导致站点崩溃。
关键事实三：版本号的含义
6.5.2
│ │ └── 补丁/安全修订（自动更新）
│ └──── 主版本序号（每年 3-4 个，含新功能）
└────── 大系列号
从 6.0 起大致每年 3 个主版本（约 2 月、6 月、10 月），配合每月的维护版本。
关键事实四：PHP 版本要求
- WordPress 6.3+ 推荐 PHP 7.4 及以上，建议 8.0+；
- WordPress 6.6+ 推荐 8.1+；
- 后台「站点健康」会提示 PHP 版本过旧。
用已停止官方安全支持的 PHP（5.6、7.0、7.2）不仅慢，而且是真实风险。升级前参考WordPress PHP 版本兼容性检查。
保姆级实操：制定升级策略
第一步：摸清当前状态
wp core version --allow-root
wp core check-update --allow-root
php -v
后台「工具 – 站点健康」会给出：
WordPress 版本 6.4.3：你的 WordPress 版本已过时
PHP 版本 7.4.33：PHP 版本已不再接收安全更新
第二步：判断要不要升
| 情况 | 建议 |
|---|---|
| 落后 1 个主版本 | 尽快升，风险可控 |
| 落后 2–3 个主版本 | 安排时间升，先备份 + Staging 测试 |
| 落后 4 个以上 / 还在 5.x | 必须升，安全风险高 |
| 最新版发布 2 周内 | 等一等，让插件作者跟进兼容 |
| 用了大量商业插件/主题 | 先看厂商兼容声明 |
经验法则：等 2–4 周再升主版本，等第一轮小版本（如 6.6.1）出来后更稳。
第三步：升级前必做
# 1. 备份
wp db export /backup/mimangfei-pre-upgrade.sql --allow-root
tar czf /backup/mimangfei-files-$(date +%F).tar.gz /var/www/mimangfei
# 2. 记录当前插件列表
wp plugin list --allow-root > /backup/plugin-list.txt
wp theme list --allow-root > /backup/theme-list.txt
# 3. 检查插件最后更新时间（超过 2 年要警惕）
wp plugin list --fields=name,version,update_version --allow-root
第四步：Staging 先测
搭建见WordPress Staging 测试环境。流程：克隆 → 升主版本 → 检查前台后台 → 确认无误再升生产。
第五步：执行升级
wp core update --allow-root
wp core update-db --allow-root # 必须执行
wp plugin update --all --allow-root
wp theme update --all --allow-root
第六步：升级后检查
wp cache flush --allow-root
wp transient delete --all --allow-root
wp core verify-checksums --allow-root
手动检查清单：
- [ ] 首页、文章页、分类页正常
- [ ] 后台各功能页正常
- [ ] 编辑器能正常编辑保存
- [ ] 表单/评论/搜索功能正常
- [ ] 图片上传正常
- [ ] 站点健康无新增严重项
- [ ] 浏览器控制台无 JS 报错
回滚方案
wp db import /backup/mimangfei-pre-upgrade.sql --allow-root
wp core download --version=6.4.3 --force --skip-content --allow-root
tar xzf /backup/mimangfei-files-2025-03-01.tar.gz -C /
详见WordPress 手动升级与安全降级回滚。
常见踩坑
- 主版本自动更新导致白屏：默认
minor不该发生。若发生，检查是否装了管理更新插件或wp-config.php被改过。 - 升级后插件不兼容：升级前查插件目录页的 “Compatible up to” 字段。
- 案例：某站一直停在 WordPress 5.4（2020 年），理由是”老主题不支持新版”。结果被曝出的漏洞无补丁，站点被植入后门。教训：主题兼容问题可以花钱解决，被黑成本更高。
- PHP 版本和 WordPress 不匹配：升了 WP 6.6 但 PHP 还是 7.2，部分功能异常。两个都要升。
- 升级顺序搞反：正确顺序是 PHP 先升 → 插件主题更新 → 最后升核心。
- 数据库没更新：
wp core update后提示”需要更新数据库”若忽略，新功能表结构缺失。用wp core update-db补。 - 缓存没清：升级后前台还是旧 JS/CSS，编辑器报错。清 OPcache、页面缓存、CDN。
总结
WordPress 没有 LTS，安全补丁只给最新版，所以不能长期停在旧主版本。推荐策略：小版本自动更新（默认开启，别关） + 主版本等 2–4 周后手动升 + 升级前备份和 Staging 测试。升级顺序是 PHP → 插件主题 → 核心。长期不维护的”僵尸站”要么定期维护，要么WordPress 临时关闭的正确做法下线。把升级纳入每月巡检，见WordPress 月度安全巡检清单。
