内容摘要：去年秋天，我帮一个做独立博客的朋友把整站从共享主机搬到一台VPS上。他那个站跑了三年，文章四百多篇，图片全塞在同一个wp-content/uploads目录里，总共也就2.3个G。听起来不难对吧？结果

去年秋天，网站我帮一个做独立博客的数据朋友把整站从共享主机搬到一台VPS上。他那个站跑了三年，迁移文章四百多篇，网站图片全塞在同一个wp-content/uploads目录里，数据总共也就2.3个G。迁移听起来不难对吧？网站结果我们折腾了整整一个周末。

问题出在他那台老主机的数据phpMyAdmin上。导出数据库时，迁移它默认把SQL文件按2MB分片，网站一共切了十七个碎片。数据朋友当时就懵了——这怎么还原？迁移我让他先别急，用SSH连上去，网站直接mysqldump一把梭。数据命令行跑完，迁移一个完整的.sql文件躺在那里，不到80MB。你看，图形界面有时候反而添乱。

网站数据迁移这件事，最怕的不是数据量大，是环境不一致。我见过太多人把文件一拷、数据库一导，然后打开新站首页一片空白。为什么？PHP版本从7.2跳到8.1，老主题里某个函数被弃用了。或者MySQL从5.6换到8.0，默认字符集从latin1变成了utf8mb4，老数据里的中文全成了问号。这些坑，你不亲自踩一遍根本想不到。

说回我朋友那个站。文件传输我们用了rsync，带压缩和断点续传。命令大概是这样：rsync -avz --progress /local/path/ user@newserver:/remote/path/。第一次跑的时候忘了加--exclude排除缓存目录，结果把wp-content/cache里几千个临时文件也传过去了。后来清掉重来，实际有效传输时间不到二十分钟。数据库导入倒是快，source命令一跑，三分钟完事。

但真正的麻烦在DNS切换之后。旧主机那边TTL设的是86400秒，也就是一天。这意味着有些用户的浏览器还指着旧IP，新站上他们看到的还是旧内容。朋友急得不行，我说你早干嘛去了——迁移前至少提前48小时把TTL降到300秒。这是基本操作，但很多人就是会忘。

还有个细节：邮件。他那博客有评论通知功能，迁移后新服务器没装sendmail，结果用户提交评论后页面卡死。查了半天日志才发现是邮件发送超时。装了个msmtp，配好SMTP，问题消失。这种边角料问题，文档里通常不会写，但你遇到了就是百分百的故障。

我自己的经验是，迁移前一定要在本地或者一台测试机上完整走一遍流程。别直接在生产环境上操作。用Docker起个一样的环境，把备份文件还原进去，看看首页、后台、文章页、评论功能是不是都正常。这一步花两个小时，能省掉你后面二十个小时的救火时间。

另外，别迷信那些“一键迁移”插件。我用过几个，有的把序列化数据里的URL替换搞砸了，有的漏掉了某些自定义表。手动来虽然笨，但每一步你都清楚发生了什么。迁移完成后，用diff对比一下新旧数据库的导出文件，看看表数量、行数对不对。图片目录用find . -type f | wc -l数一下文件总数。这些笨办法，比任何自动化工具都让人安心。

最后说一句：迁移完别急着删旧数据。保留至少一周。我朋友那次，第三天发现某个老文章的附件没传过去，从旧主机上补下来的。要是当时手快格了盘，那就真没辙了。