通常情况下，WordPress 核心升级不会直接删除数据库中的文章或用户数据，但升级过程中断或插件冲突可能导致网站无法访问，间接造成数据无法读取或丢失风险，因此跨大版本升级前必须完整备份。
先说结论：直接升级本身不删库，但环境不兼容会导致网站崩溃，备份是唯一止损手段。
- 适合：希望获取新功能和安全补丁，且能接受短暂维护窗口的站点
- 先准备：完整备份文件和数据库，确认 PHP 版本满足新要求（最低 7.4，推荐 8.0+）
- 验收：升级后检查前台页面、后台登录及关键功能插件是否正常
快速处理思路
如果你现在正面临升级决策，不要直接点按钮，按这个顺序操作：
- 停止所有自动缓存插件，防止缓存旧文件。
- 使用插件、主机面板或命令行导出完整数据库和 wp-content 目录。
- 在本地或 staging 环境先试升级，确认无报错再操作生产环境。
- 若必须直接升级，确保网络稳定，避免更新过程中断。
为什么会这样
WordPress 的数据主要存储在数据库中，而核心程序升级主要替换的是 PHP 文件。理论上，升级脚本会自动迁移数据库结构，不会触碰用户内容。但在实际场景中，数据丢失风险主要来自三个方面：一是升级过程中网络中断或超时，导致文件写入不完整，网站无法启动；二是新版本废弃了旧插件使用的函数，导致插件报错甚至删除数据表；三是主题或页面构建器与新核心不兼容，导致页面布局错乱或内容无法显示。有社区反馈显示，部分页面构建器用户在跨大版本升级后遇到了布局崩溃的问题，这往往被误认为是数据丢失。
分步处理
以下是安全升级的标准流程，每一步都有检查点：
1. 备份全站数据
不要只备份数据库。完整的备份应包括 WordPress 核心文件、wp-content 目录（含主题、插件、上传文件）和数据库。
命令行备份方案（推荐）：
如果你有服务器 SSH 权限，建议使用以下命令确保备份一致性：
mysqldump -u 数据库用户名 -p 数据库名 > backup.sql
zip -r backup-files.zip wp-content/或使用 WP-CLI 导出数据库：
wp db export backup.sql检查点：确认备份文件可下载，且大小正常。
2. 检查运行环境
WordPress 版本对 PHP 版本有明确要求。例如 WordPress 6.4 及以上版本要求 PHP 7.4 以上，推荐使用 PHP 8.0 或更高版本以获得最佳性能。
登录后台“工具”->“站点健康”查看当前 PHP 版本。如果版本过低，先联系主机商升级 PHP，再升级 WordPress。
3. 暂停非必要插件
特别是缓存插件、安全插件和页面构建器。暂时停用它们可以减少升级过程中的冲突概率。升级完成后再逐一启用。
4. 执行升级
在后台“仪表盘”->“更新”中点击“立即更新”。期间网站会进入维护模式，不要关闭浏览器或断开网络。
命令行升级方案（适合服务器管理员）：
使用 WP-CLI 可以更可控地执行升级：
wp core update
wp core update-db回滚提醒：如果升级后网站白屏，立即通过 FTP 将备份的核心文件覆盖回去。若需恢复数据库，请注意：恢复数据库意味着回滚到备份时间点，此后产生的新数据（如订单、评论、用户注册）将永久丢失。仅在数据损坏严重时才执行数据库回滚。
怎么验证是否生效
升级完成后，不要只看后台能登录，需验证以下项目：
- 前台访问：首页、文章页、分类页是否能正常加载，无 CSS 错乱。
- 关键功能：联系表单是否能提交，购物车是否能结算（如果是电商站）。
- 后台健康：检查“站点健康”状态，确认没有严重的 PHP 错误或数据库警告。
- 日志检查：查看 wp-content/debug.log（如果开启了调试模式），确认没有持续的 Fatal Error。
常见坑
- 跨版本过大：如果从非常旧的版本直接升到最新版，建议先升级到中间版本过渡，避免数据库迁移脚本失败。
- 序列化数据损坏：如果在迁移过程中手动替换了数据库中的域名，错误的序列化数据替换会导致配置丢失。
- 自动更新陷阱：自动更新若因网络问题中断，可能导致核心文件缺失，建议网络不稳定时手动上传文件升级。
- 构建器兼容：使用 Elementor 等构建器的站点，需确保构建器插件本身也是最新版，否则容易出现布局代码解析错误。
- 回滚数据代价：务必告知 stakeholders，故障回滚数据库会导致升级期间产生的新业务数据丢失。