宝塔面板迁移前必须确认宝塔版本一致、操作系统版本相同、架构类型匹配；仅用备份功能导出业务数据，底层配置需手动同步；推荐rsync+手动重配而非一键迁移。
宝塔面板迁移前必须确认的 3 个前提
直接迁移整站失败，90% 出在没核对这三项。不是所有环境都能无痛迁移：宝塔版本 必须一致（比如都是 8.0.5），操作系统版本 要同为 CentOS 7/8、Ubuntu 20.04 或 Debian 12（跨大版本如 CentOS 7 → CentOS 9 会丢服务）；架构类型 得匹配（x86_64 不能迁到 ARM64）。别信“备份完就能恢复”——宝塔的 backup.sh 脚本不校验目标机环境，硬恢复大概率卡在 Nginx 启动或 MySQL 权限报错。
用宝塔自带备份功能导出全站数据的实际限制
它能导出网站文件、数据库、SSL 证书，但漏掉关键配置：/www/server/panel/vhost/ 下的站点配置（Nginx/Apache）、/www/server/panel/data/ 中的面板用户权限、计划任务、防火墙规则、PHP 扩展启用状态全不会打包。更隐蔽的问题是：如果用了宝塔的“一键部署”安装 PHP/MySQL，其编译参数和模块路径可能和新机器不一致，导致还原后 PHP 报 undefined function curl_init()。建议只用它导出业务层数据（网站目录 + SQL 文件），底层配置手动同步。
真正可落地的迁移操作步骤（含避坑点）
- 先在原服务器执行：
bt backup 导出网站和数据库，再手动压缩以下目录：/www/server/panel/vhost/、/www/server/panel/data/、/www/server/panel/plugin/（插件配置）、/www/server/panel/config/（面板端口、登录页设置）
- 新服务器装完全相同版本的宝塔（不要用最新版），安装时选“不安装任何运行环境”，避免覆盖你将要导入的配置
- 恢复顺序不能乱：先停服务（
bt stop），再覆盖 vhost 和 config 目录，然后用 mysql -u root -p 导入数据库，最后启动（<code>bt start）
- 关键检查项：访问
@#@#@#@#@#@#@#@#@#@0 看面板是否正常；执行 nginx -t 确认配置语法；用 php -m | grep curl 验证扩展是否加载成功
为什么建议放弃“一键迁移”而改用 rsync + 手动重配
bt backup 导出网站和数据库，再手动压缩以下目录：/www/server/panel/vhost/、/www/server/panel/data/、/www/server/panel/plugin/（插件配置）、/www/server/panel/config/（面板端口、登录页设置）bt stop），再覆盖 vhost 和 config 目录，然后用 mysql -u root -p 导入数据库，最后启动（<code>bt start）
@#@#@#@#@#@#@#@#@#@0 看面板是否正常；执行 nginx -t 确认配置语法；用 php -m | grep curl 验证扩展是否加载成功宝塔官方没提供跨服务器的完整环境同步工具，所谓“迁移插件”本质是把 /www 目录打包传过去，但忽略 SELinux 上下文、systemd 服务单元文件、宝塔自建的用户组（如 www 用户 UID/GID 在新旧系统可能不同），结果就是网站 502、FTP 登录失败、定时任务不执行。用 rsync -avz --delete /www/ user@new:/www/ 更可控，配合 bt default 重置面板基础配置，再逐个启用 PHP 版本、重载 Nginx，虽然多花 20 分钟，但故障点清晰、回滚快。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
实际迁移最耗时间的从来不是拷数据，而是查 /var/log/bt/ 里的错误日志定位哪一行配置写死了旧 IP 或绝对路径。别跳过这步。
