260 个迁移项目里，我们踩过的坑

六个印象深刻的坑

1. 坑 1

   月度定时任务在采集窗口外

   依赖采集跑了两周，覆盖了所有日常调用。切换后第一个月末，一个月结批处理任务失败——它依赖的一个内部服务没被识别出来，没有一起迁。教训：依赖采集必须覆盖完整的一个月，包含月初月末。

2. 坑 2

   第三方 IP 白名单

   客户和一家支付渠道对接，对方按出口 IP 放通。迁移后出口 IP 变了，支付接口全部失败。而对方修改白名单需要走流程，走了三天。教训：所有外部对接都要提前确认是否依赖固定 IP，并把对方的变更周期算进排期。

3. 坑 3

   字符集不一致

   源库是 utf8（MySQL 的 3 字节版本），目标库建成 utf8mb4。看起来是升级，但应用里有按字节长度截断的逻辑，导致部分含 emoji 的用户昵称被截坏。教训：字符集与排序规则要显式对齐并做数据校验。

4. 坑 4

   时区配置

   源服务器是 CST，云上默认 UTC。有个报表按「当天」聚合，切换后数据统计口径整体偏移 8 小时，财务对账对不上。教训：时区必须在迁移清单里显式检查，包括操作系统、数据库和应用配置三层。

5. 坑 5

   演练用的是缩水环境

   为省成本，演练环境规格比生产小。演练时数据量小，切换脚本 20 分钟跑完。正式切换时全量数据校验跑了 1 小时 50 分，直接吃掉大半个停机窗口。教训：涉及数据量的环节，演练必须用等量数据。

6. 坑 6

   回滚决策没人敢做

   切换出问题，团队在「再试试」和「回滚」之间纠结了 40 分钟，最后还是回滚了，但停机时间翻倍。原因是没有事先约定谁有权决定回滚。教训：回滚触发条件和决策人必须写在 Runbook 里，切换前全员确认。