换个角度想
Migration 像装修的变更单：每次改水电都开一张编号单据，哪套房子（环境）施工到第几号一目了然。口头喊师傅「顺手改一下」，改过什么、别的房子改没改，事后谁都说不清。
术语 · 数据与存储
数据库迁移
Migration
以可追踪的方式修改数据库结构，并让不同环境保持一致。
结构改动，写成带版本的脚本
登上数据库直接改写成 003 号迁移同一个改动，两种下场
其他环境不知情每个环境自动追平有账可查，才敢改结构
- 新需求
功能支持手机号登录前提users 表加 phone 列 打开数据库控制台，手动 ALTER TABLE
敲完就完了，没留任何记录
003_add_phone.sqlup给 users 加 phone 列down删掉 phone 列（回退用）只有你连的那个库变了
本地 ✓ · 测试 ✗ · 同事本地 ✗
部署时按编号执行测试环境✓ 已跑到 003生产环境✓ 已跑到 003- 事故现场线上没这列，接口 500；想回退，全凭回忆改了什么、在哪改的，只有你知道有备无患出问题按 down 脚本撤销，环境永远对得上结构变化有版本，才敢放心改
结构需要变化
什么时候会遇到它
多环境一致
「本地能跑、线上报错」的结构漂移，靠迁移按序执行来杜绝。
团队同步
同事拉取代码后跑一下迁移，数据库就追平了，不用口头交代。
变更可追溯
每次结构改动都有编号、说明和时间，出问题能定位到某一号。
想一想
AI 直接连上数据库，帮你把一个列改了名。功能一切正常，这样做的隐患是什么？
看答案
这次改动没留下任何脚本：测试环境、同事的本地库都不知道这回事，下次部署两边就对不上；出问题也没有回退依据。应该让 AI 把改动写成迁移脚本，再由各环境按序执行。
最容易踩的坑
迁移改的是真实数据的结构，删列、改类型可能造成数据丢失。生产环境执行前要有备份，破坏性改动先在测试环境演练一遍。