migrate 库更适合云原生 go 服务，因其支持内存驱动、embed.fs 内嵌、与 sql.db 直接对接，满足可重复、幂等、嵌入启动流程且免人工干预的要求。
为什么 migrate 库比手写 SQL 脚本更适合云原生 Go 服务
因为迁移过程必须可重复、幂等、能嵌入启动流程，且不能依赖外部 CLI 或人工干预。migrate（github.com/golang-migrate/migrate/v4）原生支持内存驱动、Go 模块内嵌迁移文件、与 sql.DB 直接对接——这些是云环境自动伸缩和不可变部署的前提。
常见错误现象：migrate.Up() 启动时 panic 报 "no such file or directory"，本质是没把 .sql 文件打包进二进制；或用 file:// 协议在容器里读不到 host 路径。
- 用
embed.FS内嵌迁移文件：声明//go:embed migrations/*.sql，再传给migrate.NewWithFS(embededFS, "migrations", "postgres://...") - 避免硬编码数据库 URL：从环境变量读取，但注意
migrate不自动解析PGPASSWORD，得拼成完整连接串 - 不要在
main()开头就调migrate.Up()：先检查sql.Open是否通，否则迁移失败时你连日志都打不出去
migrate.Up() 和 migrate.Steps() 在滚动更新中怎么选
滚动更新时新旧版本 Pod 可能同时运行，若多个实例并发执行 Up()，可能触发锁冲突或重复执行。这不是 bug，是设计使然：默认 SQLite 锁文件或 PostgreSQL schema_migrations 表只保一个“当前版本”，但不防多客户端同时 Up。
-
Up()适合单实例启动场景，比如 Job 或 initContainer；生产 Deployment 必须加分布式锁（如用 Redis 或 DB advisory lock 封装一层） -
Steps(1)更可控：每次只执行一条，配合 readiness probe 延迟就绪，让迁移真正变成“蓝绿切换前的确定性步骤” - 别信文档里 “
Up()是幂等的” —— 它只保证多次调用不报错，但不会跳过已执行的 migration；如果你改了某条up.sql再重跑，它不会重新执行，也不会报错提醒你内容已变更
PostgreSQL 迁移里 IF NOT EXISTS 不起作用的三个原因
Go 服务上线前常想“安全第一”，所有 DDL 都加 IF NOT EXISTS，结果发现表还是建失败，或者索引重复报错。根本不是语法问题，而是 PostgreSQL 的事务隔离和迁移工具的执行粒度导致的。
立即学习“go语言免费学习笔记（深入）”；
-
migrate默认每条.sql文件在一个事务里执行，但CREATE INDEX CONCURRENTLY不允许在事务块中运行 —— 必须拆成独立文件，并用create_index.down.sql配套 -
IF NOT EXISTS对约束（CHECK、UNIQUE）有效，但对函数、视图无效；PostgreSQL 12+ 才支持CREATE OR REPLACE FUNCTION，旧版得先DROP - 迁移文件名带时间戳（如
202305011200_add_user_status.up.sql），但开发本地改了又重命名，会导致migrate认为这是新迁移而重复执行 —— 文件名一旦写进 DB 的schema_migrations表，就不能改
如何让迁移失败时不卡住整个服务启动
最要命的不是迁移失败，而是失败后服务既不退出也不就绪，Kubernetes 持续重启又持续失败，形成雪崩。核心思路是：迁移是前置检查，不是业务逻辑的一部分。
- 用
context.WithTimeout(ctx, 30*time.Second)包住migrate.Up()，超时直接os.Exit(1)，别 try-catch 吞掉错误 - 在
livenessProbe里避开迁移逻辑，只查SELECT 1；readinessProbe可以加一层“是否完成迁移”的标记（比如写个临时文件或 set redis key） - 别在
init()里做迁移：Go 的init无法传 context，也无法返回 error，失败只能 panic，而 panic 在 main goroutine 外无法被 recover
迁移不是越全自动越好，关键路径上留一两个可人工介入的钩子（比如环境变量 SKIP_MIGRATIONS=1），比所有逻辑都塞进代码里更可靠。
