第九章：Migration —— 结构改造施工单，不是“直接动工改楼”

这是 TypeORM 最容易被用歪的地方。

很多人一开始喜欢：

synchronize: true

因为方便，改完实体一运行，表就跟着变。

这在原型期可以理解，但如果你把它当正式施工方式，迟早出事。

#正确心智

text

Entity 改了
≠ 生产数据库就该直接裸改

真正稳定的做法是：
实体变化
  ▼
生成或编写 migration
  ▼
审查结构改造单
  ▼
执行 migration

#为什么 migration 是核心，不是附属功能

因为数据库结构变化不是“小改个字段名”这么简单。

它牵扯的是：

表结构演化历史
线上数据安全
团队协作审查
回滚路径
应用代码和数据库的一致升级

所以 migration 在施工队宇宙里就是：

结构改造施工单。

#一个典型 migration 片段

import { MigrationInterface, QueryRunner } from "typeorm";

export class AddPublishedAt1710000000000 implements MigrationInterface {
  public async up(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`
      ALTER TABLE "posts"
      ADD COLUMN "published_at" TIMESTAMP NULL
    `);
  }

  public async down(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`
      ALTER TABLE "posts"
      DROP COLUMN "published_at"
    `);
  }
}

它的心智特别直白：

text

up   = 怎么施工升级
down = 怎么回退恢复

#开发和生产的边界要分清

原型期你可能会看到这种路线：

text

先快速试模型

但正式环境应该切到：

text

migration 文件进入版本控制
   ▼
团队评审改造风险
   ▼
部署时执行 migration

一条很实用的原则：

synchronize 更像临时自动施工。
migration 才像正式报批后的改造工程。