改版里最让人心里没底的环节就是数据迁移。页面做错了能改，数据弄丢了找不回来。

先画一张映射表

迁移前必须明确：旧库的每个字段，在新库里对应什么。

旧字段 | 新字段 | 处理方式product_name | title | 直接对应product_pic | images | 拆分为多图add_time | created_at | 格式转换price | price_range | 需人工拆分ext_info | specs(JSON) | 解析后重组

画完你会发现三类情况：直接对应的、需要转换的、对不上的。真正麻烦的是第三类，要提前决定是丢弃、合并还是新增字段。

趁迁移清洗脏数据

老库里通常积累了这些问题：

格式不统一：有的电话带区号，有的不带；有的日期是文本
空值和默认值混用：用 0、空字符串、-1 表示"没有"
重复记录：同一个产品录了两遍，ID 不同内容一样
废弃内容：早就下架的产品还留在库里
编码问题：乱码、特殊字符、表情符号

改版是清理这些的唯一好时机。带着脏数据迁移，新系统上线后会一直脏下去。

迁移的三种做法

脚本一次性导入：适合结构相近、数据量大的情况，快但风险集中
分批导入加校验：按栏目或时间段分批，每批导入后核对，稳但慢
人工录入：数据量小或者转换规则复杂时，慢但可控

无论哪种，都要先在测试环境完整跑一遍，确认无误再对生产库操作。

必须保留的信息

这些丢了会很麻烦：

原始 ID：在新表留一个旧 ID 字段，做跳转和排查时非常有用
发布时间：别全部变成迁移当天，历史内容的时间戳是有效信息
分类与标签关系：最容易在迁移中错乱
正文里的图片路径：要批量替换成新地址
附件与下载文件：常常被整个漏掉

验证怎么做

导入完成后按这个顺序检查：

数量对账：新库条数 = 旧库应迁移条数，差一条都要查清楚
抽样比对：随机抽二十条，逐字段对比新旧内容
重点查富文本：图片、表格、链接是否完整
检查关联关系：产品是否还在正确的分类下，案例是否关联到正确客户
跑一次死链扫描：正文里的旧链接要批量替换

回滚准备

迁移前必做的三件事：

1. 完整备份旧数据库，导出文件单独保存2. 旧系统保持可运行状态，不要立刻下线3. 记录迁移脚本和参数，便于重跑或回退

旧库至少保留三个月。上线后如果发现有数据遗漏，还能补救；一旦删掉，就只能靠备份了。

上线后继续观察

头两周要留意这些异常：

用户反馈找不到某个内容：可能是漏迁
页面显示乱码或字段错位：编码或映射问题
搜索搜不到老内容：索引没重建
404 增多：正文里的旧链接没替换干净

数据迁移没有捷径，只有笨功夫：先备份、先映射、先试跑、再核对。省掉任何一步都可能付出代价。
—— 一位做过多次大型迁移的后端工程师