本文约 2,744 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：点完”更新”，首页变回出厂设置
最让人心慌的一次操作是：后台提示主题有新版本，顺手点了更新，刷新前台——导航没了、首页区块顺序乱了、页脚文案变成主题默认的”Proudly powered by WordPress”。翻遍后台设置，发现自定义器里的配置还在，但前台就是不读。
另一种情况是升级中断：zip 包下了一半，wp-content/themes/lumen-mimangfei/ 里新旧文件混在一起，前台直接白屏。主题升级本质上是一次”覆盖写入 + 数据库不动”的操作，理解这一点，就能提前把风险拆开控制。
原理分析：升级动了什么、不动什么
主题升级通过 Theme_Upgrader 把新版本的压缩包直接覆盖到 wp-content/themes/{slug}/ 目录。也就是说，任何你在这个目录里手动改过的文件，都会被同名新文件替换掉——这正是”必须建子主题”的原因。
数据库侧则基本不动，关键是要知道三类设置分别存在哪里：
| 内容 | 存储位置 | 升级是否受影响 |
|---|---|---|
| 自定义器（Customizer）设置 | wp_options 的 theme_mods_{stylesheet} |
不受影响，但键名随子主题 slug 变化 |
| 小工具内容 | wp_options 的 widget_* 与 sidebars_widgets |
一般不丢，但区域 id 变化会”消失” |
| 额外 CSS（自定义器里写的） | wp_posts 的 custom_css 类型 |
不丢，与具体主题绑定 |
| 主题文件里的手工改动 | 文件系统 | 会被覆盖 |
| 主题版本号 | wp_options 与各处缓存 |
影响静态资源缓存 |
最容易踩的坑是 theme_mods_{stylesheet} 这个键名——它跟的是子主题的目录名。如果你从”直接改父主题”切换到”建子主题”，或者改了子主题目录名，自定义器里看着有数据，前台读的却是另一份空配置，于是”设置还在但页面回到默认”。
保姆级实操
- 先做全量备份：数据库用
wp db export导出 SQL，主题目录打包成 tar；有条件的话连同wp-content/uploads一起备。 - 记录自定义项：把自定义器里的设置截图，同时用 SQL 看一眼
theme_mods有多少条，心里有数。 - 确认改动都在子主题：升级前搜索父主题目录里是否有非官方文件（对比 md5 或看文件修改时间）。
- 先在预发布环境升级：有 staging 就先在 staging 升，前台逐页走查后再上线。
- 执行升级：后台”外观 → 主题”或用
wp theme update；升级过程中不要关闭页面。 - 升级后立刻验证：首页、文章页、归档页、移动端各看一遍，重点看自定义器设置是否仍生效。
- 准备回滚方案：保留上一版本的安装包（WP Rollback 之类的回滚插件或直接覆盖回旧包），出问题能在几分钟内恢复。
# 1) 备份数据库与主题目录
wp db export backup-$(date +%F).sql --add-drop-table
tar -czf themes-$(date +%F).tar.gz wp-content/themes/
# 2) 确认当前版本与可更新状态
wp theme list
wp theme status lumen-mimangfei
# 3) 执行升级（可指定版本）
wp theme update lumen-mimangfei
wp theme update lumen-mimangfei --version=1.8.3
# 4) 升级后刷新重写规则与缓存
wp rewrite flush
wp cache flush
-- 查看自定义器设置存放在哪些键里
SELECT option_name, LENGTH(option_value) AS len
FROM wp_options
WHERE option_name LIKE 'theme_mods_%';
-- 导出前确认小工具数据条数
SELECT option_name FROM wp_options WHERE option_name LIKE 'widget_%' OR option_name = 'sidebars_widgets';
-- 查看与主题绑定的额外 CSS
SELECT ID, post_title, post_status
FROM wp_posts
WHERE post_type = 'custom_css';
# 5) 快速回滚：保留旧版本包，直接覆盖目录后再清缓存
mkdir -p /tmp/theme-old && tar -xzf lumen-1.8.2.tar.gz -C /tmp/theme-old
cp -a /tmp/theme-old/lumen-mimangfei/. wp-content/themes/lumen-mimangfei/
wp cache flush && wp rewrite flush
常见踩坑
- 只备份了数据库没备份主题文件，回滚时只能靠重新下载旧版本。
- 升级完前台回到默认样式，实际是子主题目录名改过，
theme_mods_键对不上。 - 直接在父主题里改过文件，升级后改动被覆盖，且没有任何提示。
- 升级过程中网络中断，新旧文件混合导致致命错误。
- 案例：某站升级后首页区块全部消失，排查发现开发人员早期在父主题
functions.php里加过一段自定义区块注册代码，升级时被覆盖，而theme_mods里的开关记录还在、却找不到对应的输出函数。把这段代码迁到子主题并重新启用开关后恢复；此后该站把”父主题目录零改动”写进了上线规范。 - 升级后清了页面缓存但没清 CDN，用户看到的仍是旧静态资源。
- 没有预发布环境，直接线上升级，出问题期间整站不可用。
总结
升级流程的固定顺序：备份（数据库 + 文件）→ 确认改动都在子主题 → 预发布验证 → 执行升级 → 逐页走查 → 清各级缓存。判断标准是”升级后自定义器设置仍然生效，且父主题目录里没有任何手工改动”。行动清单：① wp db export 与目录打包都要做；② 记住 theme_mods_ 跟的是子主题 slug；③ 保留上一版安装包；④ 升级后同时清 WordPress 缓存与 CDN；⑤ 有条件的站点务必准备 staging。延伸阅读 WordPress 子主题制作、WordPress 站点备份方案 与 lumen-mimangfei 主题缓存兼容。
