搬家完兴冲冲地去访问新站，发现文章少了几篇、用户头像加载不出来、后台订单数对不上——这种冷汗瞬间就下来了。数据不一致是网站迁移后最高频的问题，关键不是慌，而是有一套靠谱的排查方法。
第一步：文件数量比对
先确认文件层面有没有丢。用rsync自带的dry-run模式做一次模拟同步，看看有没有差异文件：
rsync -avzn --delete /旧站目录/ root@新IP:/新站目录/
参数里的-n是dry-run，只比较不实际传输。输出结果里如果出现文件名，说明那些文件在新服务器上缺失或内容不同。把缺失文件补上去，这一步能排除80%的静态资源问题。
第二步：数据库行数校验
文件没问题就看数据库。别去逐行对比数据，先做粗粒度检查：在旧库和新库分别执行 SELECT COUNT(*) FROM 表名;，把核心业务表的行数拉出来比对。如果行数一致，数据大概率没问题；如果行数差了，说明迁移过程中有写入操作没同步上。
行数对不上的常见原因：迁移期间旧站还在接收新数据，但新库没同步到这部分增量。解决办法是迁移前先停写入（比如维护模式），迁移完再开放。如果已经搬完了才发现，需要用binlog或时间戳字段把增量数据补过去。
第三步：检查字符集和排序规则
数据看起来“差不多“但有些内容显示乱码或排序错乱，八成是字符集问题。在新库执行 SHOW VARIABLES LIKE 'character%'; 和 SHOW VARIABLES LIKE 'collation%';，跟旧库对比。常见情况是旧库utf8、新库utf8mb4，或者排序规则一个是utf8_general_ci另一个是utf8mb4_unicode_ci，查询结果排序顺序就会不同。
第四步：清理缓存层
有时候数据其实是对的，但页面显示的还是旧内容。检查三层缓存：CDN缓存（刷新或等TTL过期）、服务器端缓存（Redis/Memcached里的数据需要清空）、浏览器缓存（Ctrl+F5强制刷新）。很多人栽在Redis没清，新数据写进去了但程序读到的是缓存里的旧值。
第五步：验证关键业务链路
前面四步都过了，最后走一遍核心业务流程：注册账号、提交订单、发表评论、上传文件。每个环节走通了才算迁移成功。别只看首页能打开就觉得完事了，真正的数据问题往往藏在交互链路里，用户不投诉你都不知道。