bee migrate 不是自动同步结构的魔法命令，仅执行 Up()/Down() 中硬编码的 SQL；迁移文件必须用 bee generate migration 创建，依赖文件名时间戳排序，不可手动修改；Up/Down 必须成对可逆，DDL 相对安全，DML 需谨慎；执行前需验证数据库连接与配置，生产环境禁用直接 migrate 和 rollback，迁移文件须纳入 Git。

bee migrate 不是“自动同步结构”的魔法命令，它只执行你写死在 Up() 和 Down() 里的 SQL。想靠它替代手动建表或绕过版本控制，迟早会丢字段、错顺序、漏约束。

迁移文件必须用 bee generate migration 创建

手动新建 .go 文件、复制粘贴结构、改包名或时间戳，大概率导致 bee migrate 完全不识别该文件。

• bee generate migration add_status_to_orders 会在 database/migrations/ 下生成带唯一时间戳的文件（如 20260821_121533_add_status_to_orders.go）
• 文件名中的时间戳是 Beego 追踪执行顺序的唯一依据，不能删、不能重命名、不能手动生成重复时间戳
• Beego 不依赖数据库中任何状态表，全靠文件名排序 + 已执行记录缓存在本地 .bee_migrate 文件里

Up() 和 Down() 必须成对可逆

不是所有 SQL 都能安全回滚。Down() 写错，bee migrate rollback 就会失败甚至破坏数据。

Beego框架 2.3.5

Beego框架 2.3.5 版本源码包下载，适合关注表单空值、函数注释名和 nil 返回值修复的 Go Web 开发者。

下载

• Up() 里加字段 → Down() 必须 DROP COLUMN，不能写成 ALTER TABLE ... MODIFY
• 添加唯一索引的 Up()，Down() 要用 DROP INDEX，不能只删约束名（MySQL 索引名和约束名可能不同）
• 如果 Up() 插入了默认数据（比如初始化配置行），Down() 应该用 DELETE WHERE 精确删除，而不是 TRUNCATE
• DDL 操作（CREATE TABLE, ALTER TABLE）通常可逆；DML（INSERT, UPDATE）务必谨慎，避免回滚时丢失业务数据

执行迁移前必须确认数据库连接配置

bee migrate 默认读取 conf/app.conf 中的 db 段，但不会校验连接是否真实可用 —— 它只在真正执行 SQL 时才报错。

• 确保 app.conf 里有类似配置：
  db.driver = mysql
db.conn = root:pass@tcp(127.0.0.1:3306)/myapp?charset=utf8mb4&parseTime=True
• 连接串中 parseTime=True 是必须的，否则 time.Time 字段解析会出错
• 如果项目用了多环境（dev.conf, prod.conf），bee migrate 不会自动加载对应环境配置，需显式指定：bee migrate -config=conf/prod.conf
• 执行前建议先用 mysql -u root -p -h 127.0.0.1 -P 3306 myapp 手动连一次，验证账号、库名、网络、权限

线上环境严禁直接 bee migrate up

本地开发可以试错，生产库一旦执行就不可撤回 —— 即使 Down() 正确，也可能因并发写入导致数据不一致。

• 每次上线前，把迁移脚本导出为纯 SQL：bee migrate sqlup > 20260821_add_status.sql，交给 DBA 审核
• 禁止在生产环境运行 bee migrate rollback：Beego 的 rollback 是按时间戳倒序执行最后一个 Down()，无法指定某次迁移回退
• 如果迁移失败卡住（比如某个 Up() 报错），bee migrate 不会自动清理已执行部分，需人工检查数据库当前状态，再决定是修复还是手动补救

实际迁移中最容易被忽略的，是 database/migrations/ 目录没纳入 Git 版本控制 —— 这会导致协作者拉代码后，bee migrate 完全看不到你写的变更，还误以为结构是最新的。