WordPress 7.1 已在 2026-08-19 发布，生产站升级前要把备份、插件、主题、媒体和回滚放在同一份清单里。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
WordPress 7.1 “Mary Lou” 已经在 2026-08-19 正式发布，7.0 系列进入结束支持状态。生产站升级不等于在后台点一下更新，需要先把备份、插件兼容、主题样式、媒体处理和回滚安排成同一条流水线。这份清单按实际操作顺序整理，适合已经把测试站或暂存站验证过一轮、准备在正式站上线的管理员。
适用场景
- 你的站点需要从 7.0 升级到 7.1，且后台有自定义主题、第三方插件或自动化任务。
- 你已经有一份可用备份，并且希望在维护窗口内完成升级和验收。
- 站点使用新媒体格式、图片裁剪、响应式区块或任务协作功能，想在升级后统一验证。
- 你需要给其他同事留下可重复执行的升级文档，而不是依赖个人记忆。
不适用场景
- 你的站点完全没有备份能力，也没有维护窗口，先修复备份和回滚流程，不要直接升级。
- 你只是在沙盒里体验新功能，不涉及生产数据，不需要完整上线清单。
- 你的主题或关键插件明确声明不兼容 7.1，应先等补丁或切换替代方案。
- 你希望在升级同时改域名、换主题、改数据库前缀，风险叠加会很难定位问题。
准备材料
- WordPress 后台管理员账号，以及服务器或主机控制面板的访问权限。
- 完整的数据库备份、站点文件备份，最好包含一份可以直接恢复的测试恢复记录。
- 站点当前 WordPress、PHP、MySQL/MariaDB 和插件版本列表。
- WordPress 7.1 官方发布公告、版本文档和更新指南。
- 一个维护窗口，至少预留备份、升级、验收和回滚四段时间。
步骤一：升级前记录基线
先记录站点可以正常工作的状态，再动文件。用 WordPress 后台的站点健康、插件列表、活动主题、PHP 版本和数据库版本建立一份基线。如果你有监控，同时记录首页响应时间、核心页面、上传页和后台页面能否正常打开。
- 导出当前 WordPress 核心版本、数据库版本和 PHP 版本。
- 列出活动插件名称、版本和是否使用了缓存、安全、表单或页面构建器。
- 记录当前主题名，以及主题设置里是否依赖自定义脚本或额外 CSS。
- 把基线写入升级模板，后续每一步都和这份基线对比。
步骤二：做完整备份并测试恢复
不要只把备份文件下载到本地就算完成。备份的价值在于能否恢复，建议在测试环境或临时目录验证至少一次恢复。
- 备份数据库，并确认导出文件不是空文件、大小正常。
- 备份 wp-content 目录，特别关注 uploads、themes 和 plugins。
- 备份 wp-config.php 和站点根目录的自定义文件。
- 在恢复演练里确认数据库导入、文件权限和 .htaccess 或 Nginx 规则能被还原。
- 把备份文件放到安全位置，避免存在被升级操作的同一个目录。
步骤三：检查版本要求和兼容清单
WordPress 7.1 版本文档记录了该版本的数据库版本号和变更范围。升级前先确认主机 PHP 版本仍然满足要求，再检查插件和主题是否有 7.1 兼容补丁。不要假设所有插件都能自动兼容。
- 确认 PHP 版本没有低于当前主机推荐值。
- 在插件仓库查看每个活动插件的最近更新日期和“兼容至”信息。
- 检查主题更新日志，确认是否支持新增的响应式样式和区块。
- 如果站点使用 Page Builder、缓存插件、优化图片插件或安全插件，优先单独测试。
如果站内有很多历史媒体文件，还要检查插件是否挂钩了 `attachment`, `wp_handle_upload`, 图片缩略图或 `wp_image_editor`。7.1 把部分图片压缩、裁剪和还原工作移到浏览器端，不同插件对图片处理钩子的假设可能不同。升级前在测试站上传一张大图，确认原图、缩略图、EXIF 元数据和裁剪界面都能工作，再进入生产操作。
步骤四：在维护窗口执行升级
升级前把所有需要保存的内容都落盘，然后把站点切成维护模式。对大多数站点，后台 Dashboard 的 Updates 菜单是标准入口，也可以使用 WordPress 官方更新指南里的手动方式。无论哪种方式，只做核心升级，不要把插件、主题、数据库迁移和配置修改放在同一步。
- 开启维护模式，并让团队成员知道当前窗口内不要发布文章或改设置。
- 在后台进入更新页面，确认可供更新的目标是 WordPress 7.1。
- 执行升级，观察是否出现数据库更新步骤或后台要求重新登录。
- 升级完成后关闭维护模式，读取后台欢迎页和站点健康结果。
步骤五：逐项验证生产页面与功能
7.1 的重点变化包括新媒体编辑器、响应式样式、Notes 协作、Tabs 和 Playlist 区块。升级后不能只看首页，还要检查后台和内容编辑链路。
- 打开首页、文章页、分类页和自定义页面，检查布局是否错乱。
- 在后台打开附件或媒体库，确认图片裁剪入口、元数据和缩略图都能工作。
- 分别用手机和桌面宽度检查响应式区块，重点是使用了不同屏幕断点的页面。
- 测试一次文章编辑和保存，确认 Notes、提及和发布按钮正常。
- 检查缓存插件是否重新生成缓存，CDN 是否仍走正确回源。
- 检查站点地图、RSS、登录页和管理员页面是否返回正常。
- 升级前有核心版本、PHP、插件、主题和数据库基线。
- 数据库和文件备份已生成，并且恢复演练通过。
- 活动插件和主题都已检查 7.1 兼容性。
- 维护窗口内没有并发发布或配置变更。
- 升级完成后首页、文章、分类、媒体库和后台均正常。
- 缓存已刷新，站点地图和 RSS 可访问。
- 回滚方案已写好，并且关键步骤未依赖只能登录后台的操作。
- 媒体库的大图上传、裁剪和元数据已测试。
- 对象缓存、页面缓存和 CDN 都已刷新，源站资源版本正确。
- 只备份数据库，忘记 uploads 和主题自定义文件，回滚时页面仍然不完整。
- 升级同时更新所有插件，出问题后无法判断是核心还是插件导致。
- 不清缓存，用户看到旧样式，误以为升级失败。
- 忽略插件在后台产生的数据库表，恢复时只导入默认备份导致数据不一致。
- 在没有维护窗口时直接升级，结果线上正在发布内容，造成并发锁或半保存状态。
- 如果升级后白屏，先打开调试日志或恢复备份，确认是 PHP 错误还是主题错误。
- 如果后台缺少新版媒体编辑器，先清浏览器缓存并确认当前版本号已更新。
- 如果页面样式错乱，逐一切换主题或停用插件，缩小范围后再补丁。
- 如果数据库更新卡住，检查数据库用户权限和主机资源限制，不要重复点击。
- 如果回滚后数据不同步，使用升级前的数据库和文件组合，并重新清缓存。
- 如果后台显示新版本但前端仍加载旧脚本，检查 CDN、对象缓存和浏览器缓存三层。
- 站点维护人：。
- 升级前版本：。
- 升级目标版本：WordPress 7.1。
- PHP/数据库版本：。
- 备份文件路径：。
- 恢复演练结果：通过 / 未通过。
- 活动插件清单：。
- 维护窗口：。
- 验收页面：首页、文章、分类、媒体库、后台。
- 回滚命令或步骤：。
- 更新日期：2026-08-23。
如果站点使用 WordPress 对象缓存或外部 CDN，升级完成后要刷新一次缓存，再检查源站是否已经返回 7.1 的新资源。不要只让 CDN 继续推送旧版本的 JS 或 CSS。对启用了自动更新的站点，还要确认这次升级是否被自动更新流程拦截或延迟，保证维护窗口内的手动判断仍然有效。
检查清单
实际例子
假设一个 WordPress 博客使用 Blocksy 主题、一个缓存插件和一个统计插件。管理员先记录 WordPress 7.0.4、PHP 8.2、数据库版本和五个活动插件，然后导出数据库并打包 wp-content。接着在插件页面确认缓存插件和统计插件都有 7.1 兼容更新，主题发布说明也提到响应式样式支持。维护窗口内开启维护模式，升级到 7.1，重新登录后先看站点健康，再打开首页、一篇长文章和媒体库，随后清缓存并检查手机宽度。整个过程没有同时更换主题，也没有改 wp-config。
常见坑
排错路径
可复制模板：WordPress 7.1 生产升级记录
更新日期与维护建议
本文基于 WordPress 官方发布公告和版本文档整理，更新日期为 2026-08-23。每次准备 7.1 小版本更新时，不要只升级核心，要把插件更新、主题更新和缓存策略一起复查。建议把这份模板放进团队文档，每季度或每次大版本发布前重跑一次。