migrate dev vs db push：什么时候用哪个

先给结论

	migrate dev	db push
原理	生成并保存一条迁移文件（SQL）到 `prisma/migrations/`，然后执行	直接把当前 Schema 同步到数据库，不保存迁移文件
版本控制	✅ 迁移文件可以提交 Git	❌ 没有历史记录
适用阶段	长期维护的正式项目	原型验证、快速迭代、个人玩具项目
数据安全	会检测破坏性变更并提示重置	会静默执行破坏性变更（删列、改类型）
生产可用	✅ `migrate deploy` 应用已有的迁移	❌ 绝对不要在生产用

关键规则：选定一种就坚持到底，不要在同一个项目里混用两者。

migrate dev：版本化迁移

npx prisma migrate dev --name add-user-role

这条命令会：

对比当前 Schema 和上一次迁移快照的差异
生成一条新迁移文件 prisma/migrations/20240101_add-user-role/migration.sql
在开发数据库上执行这条 SQL
更新迁移记录表 _prisma_migrations
自动触发 prisma generate

破坏性变更检测

如果你改了一个会丢数据的东西（比如把 age Int 改成 age String，或者删了一列），migrate dev 会提示：

⚠️  We found changes that cannot be executed:

  • Changed the type of `age` on `User` from `Int` to `String`

? Applying this change would result in data loss.
  Do you want to continue?

你可以选择继续或取消。更危险的变更（删表）会自动要求重置数据库。

迁移文件长什么样

-- prisma/migrations/20240101_add-user-role/migration.sql
-- CreateEnum
CREATE TYPE "Role" AS ENUM ('USER', 'ADMIN');

-- AlterTable
ALTER TABLE "User" ADD COLUMN     "role" "Role" NOT NULL DEFAULT 'USER';

这份文件就是普通 SQL，可以审阅、修改、提交 Git。团队成员 pull 代码后跑 migrate dev 就能自动同步数据库结构。

db push：直接同步

npx prisma db push

这条命令直接把当前 schema.prisma 的状态推到数据库，不生成任何迁移文件。

适用场景

原型阶段——快速试各种数据模型，不想被迁移文件管理分心
个人练习项目——你自己记得数据库长什么样，不需要版本化
刚从原生 SQL/其他 ORM 切过来的过渡期——先跑通再慢慢转成正式迁移

致命问题

db push 不记录历史。 如果你一直用 db push，你的项目里没有 prisma/migrations/ 目录。等你想上生产时会遇到：

生产数据库里当前是什么 Schema？不知道
从哪一版开始部署？没有迁移记录
其他同事的数据库怎么和你同步？他们跑 db pull 能拉到现状，但没有历史

从原型切到正式迁移的正确做法是：原型阶段用 db push，准备转正式时执行 prisma migrate dev，它会提示重置（因为之前没有迁移历史），重置后开始正式版本化。

混用陷阱

如果你在同一个项目里先跑 migrate dev 创建了迁移文件，然后又跑 db push 改了 Schema，会发生：

_prisma_migrations 表记录了已应用的迁移
但 db push 改了数据库结构却没更新迁移表
下次跑 migrate dev 时 Prisma 会认为你当前 Schema 比最后一次迁移快照"更新"了，但实际数据库已经被 db push 改过
Prisma 尝试生成新迁移，但发现某些变更已经在数据库里了 → 报错或生成错误的迁移

如果不小心混用了，用 prisma migrate status 检查状态。最干净的修复是重置数据库，然后只用一种方式。