ent迁移命令不生效的主因是未正确指定--driver和--url参数，或ent/schema下的schema未被entc.new显式引用；ent不自动扫描go文件，且需确保url含完整协议与参数（如mysql需?parsetime=true&loc=local），同时检查schema_version表状态、migrate.withdir路径指向正确目录，并在gin初始化阶段用diff模式安全触发迁移。
Ent迁移命令不生效，表没创建
直接运行 ent migrate status 或 ent migrate up 却没建表？大概率是没指定正确的 --driver 和 --url，或者 ent/schema 下的 schema 没被正确引用。Ent 不会自动扫描所有 Go 文件，它只认你显式传给 entc.New 的 schema 列表。
- 确认迁移命令中 URL 包含完整协议和参数，例如 MySQL 要带
?parseTime=true&loc=Local，否则可能连接成功但时区/类型处理出错 -
ent migrate up默认只执行未应用的 migration 文件，如果之前失败过，残留的schema_version表记录可能卡住流程，可先用ent migrate reset（慎用，会删库）或手动清理该表 - 确保
ent/migrate/migrate.go里调用migrate.WithDir指向的是生成的 migration 目录（通常是ent/migrate），不是 schema 目录
Gin 启动时自动执行 Ent 迁移
别在 main() 里裸写 client.Schema.Create(context.Background()) —— 这会每次启动都尝试建表，而生产环境通常只需要跑一次 migration。更稳妥的做法是在 Gin 的初始化阶段检查并触发 ent migrate up 的等效逻辑。
- 用
ent.Driver封装数据库连接，再传给migrate.NewWithConfig，避免重复解析 DSN - 推荐在 Gin 的
router.Use()前，用ent.Migrate的Diff模式检测是否需要迁移：若migrate.Status().Pending > 0，才调用Up() - 开发环境可加
if os.Getenv("GIN_MODE") == "debug"控制是否自动迁移，避免线上误触发
字段变更后 Ent 迁移报错 “cannot modify column type”
MySQL 中修改列类型（比如 string 改成 text）默认被 Ent 拒绝，因为涉及数据兼容性风险。Ent 的 migrate.Up() 默认启用严格模式，不会执行可能丢失数据的操作。
- 临时绕过：加
migrate.WithAllowDirty(true)，但仅限本地开发；上线前必须人工核对 SQL - 长期方案：改用
migrate.WithDropColumn(true)+migrate.WithDropIndex(true)，让 Ent 生成 DROP+ADD 语句（注意这会清空原列数据） - 更安全的做法是手写 migration 文件：用
ent migrate add -f "add_fullname_to_user"生成空文件，再填入ALTER TABLE user ADD COLUMN fullname TEXT;
Gin 日志里看不到 Ent 迁移 SQL
Ent 默认不输出执行的 SQL，调试迁移问题时容易抓瞎。虽然 ent.Logger 可设为 log.New(os.Stdout, "[ent] ", 0)，但这只打 schema 构建日志，不包括 migration 执行语句。
- 真正要看到 SQL，得在创建
migrate.Driver时包装底层 driver：用sql.Open获取*sql.DB后，传给migrate.WithDriver前，先套一层logsql.Open（需引入entgo.io/ent/dialect/sql/logsql） - 注意
logsql会打印所有 SQL，包括心跳、事务控制语句，关键看CREATE TABLE和ALTER TABLE行 - 线上禁用该日志，因含敏感表结构和可能的参数值
