宝塔5.9及更早备份包不兼容8.x+版本，表现为校验通过但跳过所有项目；需用tar -tzf检查路径是否含panel_backup/site/等结构，否则须用新版面板重新备份。
迁移失败时先确认宝塔版本是否兼容
宝塔 5.9 及更早备份包无法被 8.x+ 版本识别，表现是“校验通过但跳过所有项目”。这不是网络或权限问题，而是结构解析失败。
执行 tar -tzf your_backup.tar.gz | head -n 5 查看前几行路径：正常应含 panel_backup/site/、panel_backup/database/；若直接看到 wwwroot/ 或 default.conf，说明备份包被手动重打包过，结构已破坏。
- 老版本面板（≤5.9）必须先升级到 9.0.0 再执行备份，不能靠“本地解压再 tar -czf”补救
- 新版宝塔（≥8.0）不兼容老备份中的
GTID和JSON默认值语法，强行恢复会静默跳过数据库 - 若无法升级源端面板，只能人工还原：用
mysqldump --set-gtid-purged=OFF --skip-triggers重新导出 SQL
MySQL 跨版本导入报错 utf8mb4_unicode_520_ci 怎么办
这是典型的 MySQL 5.7 ←→ 8.0 字符集校对规则不匹配。8.0 引入了 utf8mb4_unicode_520_ci，而 5.7 只认 utf8mb4_unicode_ci 或 utf8_general_ci。
别直接全局替换为 utf8_general_ci——它不支持 utf8mb4 字符集，会触发 COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4' 新错误。
- 正确做法：把
utf8mb4_unicode_520_ci替换为utf8mb4_unicode_ci - 用
sed -i 's/utf8mb4_unicode_520_ci/utf8mb4_unicode_ci/g' backup.sql批量处理 - 若目标库是 5.7 且已存在，导入前先执行
SET NAMES utf8mb4;，避免客户端连接层乱码
迁移后 MySQL 启动失败，卡在 Can't change dir to
这基本不是配置写错，而是 datadir 目录归属或 SELinux 上下文没同步过去。MySQL 进程以 mysql 用户身份运行，但迁移常保留原属主（如 root:root）。
先验证权限：运行 sudo -u mysql ls -l /path/to/new/datadir，如果返回 Permission denied，就坐实了权限问题。
- 修复归属：
chown -R mysql:mysql /path/to/new/datadir（注意：不要对/www/server/mysql整体递归，里面 bin、etc 子目录必须是 root） - 检查 SELinux：
sestatus若为enabled，需加chcon -R -t mysqld_db_t /path/to/new/datadir - 别忽略 socket 路径：
my.cnf中的socket值若指向新目录，要确保该路径父目录可写，且文件不存在（MySQL 启动时自动创建）
一键迁移插件显示连接失败，但 SSH 和面板都能通
这不是网络连通性问题，而是 API 白名单没配对。宝塔迁移插件的白名单和面板登录白名单完全独立，很多人在这里栽跟头。
在目标服务器插件设置页填入的必须是源服务器的**公网出口 IP**，不是内网 IP，也不是云厂商 SNAT 后的共享 IP。
- 在源服务器执行
curl ifconfig.me确认真实出口 IP - 填入白名单后，等约 30 秒缓存刷新，再试；别信面板 UI 的“测试连接”按钮，它可能因前端异常静默失败
- 用 curl 直连验证：
curl -X POST "https://目标IP:8888/api/panel/move?access_key=xxx" -d '{"action":"test"}'，返回{"status":true}才算真正通
跨版本迁移最易被忽略的是备份包结构与字符集校对规则的隐式耦合——它们不报错，只沉默跳过或启动失败。动手前先 tar -tzf 看一眼路径，比反复重启服务有用得多。
