AutoMigrate不是真正的自动Schema同步，因其仅安全补缺（建表、加字段、建索引），不删字段、不改类型、不支持版本管理与回滚；而golang-migrate CLI通过成对SQL文件、严格序号、状态记录和可逆操作实现可靠版本化迁移。
用 golang-migrate CLI 做自动 Schema 同步最可靠；AutoMigrate 仅适合开发初期快速建表，不能替代版本化迁移。
为什么 AutoMigrate 不算真正的自动 Schema 同步
AutoMigrate 只做「安全补缺」：建缺失表、加缺失字段、建缺失索引，但不会删字段、不改类型、不删索引、不处理外键约束（除非显式启用），也不感知历史变更。它没有版本号、不记录状态、不支持回滚。
常见失效场景：
- 把
Name string `gorm:"size:50"`改成size:100，MySQL 下大概率不生效，PostgreSQL 直接跳过 - 字段从
Age int改成Age uint，不会触发ALTER COLUMN - 删掉一个 struct 字段后跑
AutoMigrate，原数据库字段还在 - PostgreSQL 使用非
publicschema（如my_schema）但 DSN 没带search_path=my_schema，表建在public，后续查询报relation "xxx" does not exist
migrate CLI 执行 up/down 的硬性要求
文件命名、URL 参数、路径写法稍有偏差就会静默失败或报错，不是“没效果”，而是根本没被识别。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 迁移文件必须成对存在：
000001_create_users.up.sql和000001_create_users.down.sql；漏掉.down.sql会导致migrate down报错 - 序号必须连续、不可跳号（如 000001 → 000002），否则
up会跳过中间缺失编号的文件 - 数据库 URL 必须显式携带驱动所需参数：
postgres://...要加?sslmode=disable，mysql://...要加?parseTime=true&loc=Local - SQLite 迁移路径不能用相对路径：
file://./migrations会解析失败，得用绝对路径如file:///home/user/project/migrations
Go 代码中调用 migrate.Up 的三个关键避坑点
在服务启动时嵌入迁移逻辑（如 FaaS 或短生命周期任务），最容易因事务/连接池配置出问题。
-
migrate.Up()默认为每个.up.sql启一个事务——但 PostgreSQL 的CREATE TABLE等 DDL 在函数内执行会报ERROR: CREATE TABLE cannot be executed from a function - 必须提前设置
db.SetMaxOpenConns(1)：多连接并发操作schema_migrations表会锁冲突，导致迁移卡死或状态错乱 - 别传
-1给Up()：m.Up(-1)是无限执行所有未应用迁移，一旦某条失败，后续无法恢复；应只传0（执行全部）或具体数字
迁移失败后 schema_migrations 表状态卡住怎么办
migrate down 不是“撤销上一条 SQL”，而是按序号倒序执行 .down.sql。只要其中一条成功写了记录，就再也不会重试——哪怕它只删了一半外键就崩了。
典型症状：
- 执行
migrate down 1报错ERROR: cannot drop table "users" because other objects depend on it - 但
schema_migrations表里该版本已标记为已回滚 - 下次
up直接跳过，导致表结构和迁移脚本长期不一致
解法只有手动清理：DELETE FROM schema_migrations WHERE version = 123456;，再重试 down ——但前提是你知道哪条 down 脚本实际没跑完。
真正安全的做法，是在每个 .down.sql 开头加 DO $$ BEGIN ... EXCEPTION WHEN others THEN NULL; END $$;（PostgreSQL）或等效防御块，避免单点失败阻断整个回滚流。
