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 就会失败甚至破坏数据。
-
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 = mysqldb.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 完全看不到你写的变更，还误以为结构是最新的。
