WordPress核心数据必须导出wp_users、wp_usermeta、wp_posts、wp_postmeta、wp_options五张表，缺一不可；其他如插件缓存表须跳过，导出前需停用插件、清理wp_options缓存项并勾选DROP TABLE语句。
导出选项配错，导入时大概率报错或还原失败——关键不在“导出成功”，而在“能干净还原”。
选哪几张表才真正算“WordPress核心数据”
wp_users、wp_usermeta、wp_posts、wp_postmeta、wp_options 这五张表承载了用户、内容、设置三类不可替代的数据。其他表基本都属于插件或缓存，比如 wp_wpforms_submissions、wp_cache_object、wp_sg_cachepress_cache，这些必须跳过。
- 务必核对表前缀：不一定是
wp_，可能是myblog_或wp123_，左侧数据库列表里点开看真实名称 - 如果只勾
wp_posts却漏掉wp_postmeta，特色图像、自定义字段全丢；只导wp_users不导wp_usermeta，用户角色和头像设置就失效 - 别信“全选”按钮——它会把所有带前缀的表一并打包，包括你半年没用过的已卸载插件残留表
SQL导出格式里这几个选项不能乱勾
选“自定义”导出模式，不是“快速”。快速模式默认不带 DROP TABLE，导入时遇到同名旧表会卡住或报错 #1050 - Table 'wp_posts' already exists。
- ✅ 勾上
添加 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT 语句：确保还原时先清空旧结构，避免主键冲突或字段错位 - ❌ 别勾
包含创建数据库语句：否则导入时可能触发#1044 - Access denied for user，尤其在共享主机或权限受限环境 - ✅ 格式兼容性设为
MYSQL40：兼容老版本 MySQL（如 5.5），避免utf8mb4相关语法报错；新环境用 5.7+ 可忽略，但保守起见仍建议保留
wp_options 表里的缓存项必须手动清理
wp_options 看着才几百 KB，实际导出文件动辄几 MB，全是 _transient_、wp_rocket_settings、wpseo_options 这类序列化缓存值。它们不影响内容完整性，但会拖慢导入、占用空间、甚至因反序列化失败导致部分 INSERT 报错。
- 先导出完整
wp_options表，再用 VS Code 或 Sublime 打开 SQL 文件 - 搜索并整行删除所有匹配以下
option_name的INSERT INTO `xxx_options` VALUES行：_transient_、_site_transient_、wp_rocket_、wpseo_、autoptimize_ - 必须保留的关键项：
siteurl、home、blogname、permalink_structure、active_plugins—— 删了会导致后台打不开或固定链接全 404
导出前停用插件不能靠后台点击
在 WordPress 后台点“停用插件”，只是把 active_plugins 字段改了个数组标记，插件 PHP 文件仍在执行钩子，wp_options 里的 transient 时间戳、wp_posts 里的自动草稿仍会被写入，导出状态就不一致。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法：通过 FTP 或主机控制面板，把
wp-content/plugins重命名为plugins.off - 此时前台显示“已停用所有插件”，后台仍可登录，且无任何插件代码执行
- 导出完成后立刻改回
plugins，别依赖记忆——忘了启用等于长期裸奔
最易被忽略的是 wp_users 和 wp_usermeta 的关联完整性：两张表靠 user_id 关联，但 phpMyAdmin 导出时不校验外键约束，一旦漏导其中一张，还原后用户系统就残缺——这不是报错问题，而是悄无声息地丢数据。
