TypeORM migration:generate 报“no changes”主因是实体未被正确识别或比对逻辑忽略细节；需确保 entities 路径配置准确、使用 --strict 参数、显式声明 MySQL 类型，并审阅生成 SQL。
为什么 typeorm migration:generate 总是报错“no changes in database schema”
常见原因是 TypeORM 没法正确比对当前实体（@Entity）和数据库真实结构。它默认只检查 src/entity/ 下的文件，且要求所有实体已通过 entities: ['src/entity/**/*.ts'] 显式注册；如果用了 .js 文件、路径写错、或实体没导出，默认就“看不见”。另外，MySQL 的 utf8mb4 排序规则、JSON 类型字段、自定义 enum 映射都可能被 TypeORM 忽略比对逻辑。
实操建议：
- 确认
tsconfig.json中"outDir"和ormconfig.ts（或package.json中typeOrm配置）里的entities路径指向编译前的.ts文件（开发时），或编译后的.js文件（生产时）——二者必须一致 - 运行生成命令前，先手动执行
npx ts-node -r ts-node/register ./node_modules/typeorm/cli.js migration:generate -n Init，避免ts-node加载失败 - 若仅修改了列注释或默认值，TypeORM 默认不触发变更；需加
--strict参数：npx typeorm migration:generate -n AddUserEmail --strict
MySQL 字段类型映射错位导致 migration:run 失败
TypeORM 对 MySQL 的类型推断有隐式规则：比如 @Column({ type: 'varchar', length: 255 }) 会生成 VARCHAR(255)，但如果你写了 @Column({ type: 'text' }) 却没指定 length，它可能生成 TINYTEXT 而非预期的 TEXT；更隐蔽的是 enum 字段——TypeORM 默认用 varchar 模拟，但若数据库里已是原生 ENUM('a','b')，迁移就会因类型不匹配中断。
实操建议：
- 显式声明 MySQL 原生类型：用
@Column({ type: 'enum', enum: ['draft', 'published'] })替代字符串数组，TypeORM 才会生成ENUM - 避免依赖自动推断：对
datetime/timestamp字段，明确写@Column({ type: 'datetime', default: () => 'CURRENT_TIMESTAMP' })，否则 MySQL 8.0+ 可能拒绝CURRENT_TIMESTAMP作为DATETIME默认值 - 检查生成的迁移文件中
up方法里的 SQL：如果出现MODIFY COLUMN但没带NOT NULL或DEFAULT，很可能丢失约束，需手动补全
如何安全回滚已执行的 MySQL 迁移
TypeORM 的 migration:revert 并不总是可靠——它只执行上一个迁移的 down 方法，且假设 down 是幂等的。但 MySQL 不支持在事务中执行 DROP TABLE 或 ALTER TABLE ... DROP COLUMN（除非引擎为 InnoDB 且 autocommit=off），一旦 down 报错，状态就卡住。
实操建议：
- 永远不要在生产环境直接
migration:revert；应新建反向迁移：npx typeorm migration:generate -n RevertAddUserEmail，然后在up里写删字段逻辑，在down里写恢复逻辑 - 对破坏性操作（如删表、删列），
down方法里必须先检查字段/表是否存在，用 MySQL 的IF EXISTS语法包裹，例如：await queryRunner.query("ALTER TABLE user DROP COLUMN IF EXISTS email") - 在 CI/CD 流程中，把
migration:run和migration:show组合使用：先show确认待执行列表，再run，避免误跑
MigrationInterface 中 queryRunner 的实际行为差异
很多人以为 queryRunner.query() 就是直连 MySQL 执行 SQL，其实它受事务上下文控制：在 up 和 down 中，TypeORM 默认开启事务，但 MySQL 对某些语句（如 CREATE TABLE）会隐式提交，导致后续语句不在同一事务里。这意味着你不能指望整个 up 方法原子性回滚。
实操建议：
- 避免在单个迁移中混用 DDL（
CREATE/ALTER/DROP）和 DML（INSERT/UPDATE）；DDL 语句尽量拆到独立迁移 - 需要数据预填充时，用
queryRunner.manager替代裸 SQL：await queryRunner.manager.insert(User, { name: 'admin' })，它走 ORM 层，能更好处理关系和生命周期 - 调试时别只看终端输出，用
queryRunner.connection.driver.options.host等属性确认当前连接的是测试库还是生产库——本地.env配置漏掉TYPEORM_DATABASE就可能连错库
queryRunner 调用背后的 MySQL 行为边界。最容易被忽略的，是迁移文件本身作为代码，也需要单元测试——至少要验证 up 和 down 能顺序执行而不抛错。 
