第十章：Migration —— 档案馆结构改造施工单

很多新手最容易把 Prisma 用歪的地方，不在查询，而在 schema 变更。

#错误心智

我把 schema 改了
= 数据库已经改了

这当然不对。

#正确心智

我改了 schema
= 我提出了新的数据契约
= 接下来要决定如何让数据库结构跟上

这就是 migration 的职责。

#schema 变更到 migration 的标准思路

业务规则变化
   │
   ▼
修改 schema.prisma
   │
   ▼
生成 migration
   │
   ▼
检查生成的 SQL 是否合理
   │
   ▼
应用到数据库
   │
   ▼
重新 generate client
   │
   ▼
修正受影响的业务代码

#开发阶段常见流程

prisma migrate dev
prisma generate

#生产阶段的核心心智

生产环境不是“想到哪改到哪”。

而是：

• 迁移文件进入版本控制
• 团队评审结构变化
• 部署时应用 migration
• 应用代码与数据库结构一起升级

#为什么 Prisma Migrate 很重要

因为它不是单纯“帮你改表”。

它还帮你保留：

• 结构变更历史
• 团队协作可审计性
• 应用代码与数据库结构的一致演化

#一个非常实用的判断标准

当你改 schema 时，先问自己这次变化属于哪一类：

1. 纯结构变化
   例如新增字段、新增表、加索引。

2. 结构变化 + 数据迁移
   例如把 fullName 拆成 firstName 和 lastName。

3. 危险变化
   例如删字段、改字段类型、重命名字段。

第三类最不能偷懒。因为自动生成的 migration 不一定懂你的业务语义。
你必须检查生成的 SQL。

#原型开发时的捷径

如果你还在快速试模型，常见思路是：

prisma db push

它更像“先把现状推过去”，适合原型期。
但进入正式协作后，主线心智仍然应该是 migration 文件化。

#现有数据库接入

如果数据库已经存在，常见思路是：

prisma db pull

也就是先从现有档案馆把结构“反向拉回”事务所章程。