yii migrate/down 默认只回滚最后1步，若无可用回滚项（如已退至起点或yii_migration表为空）则静默跳过；需先用php yii migrate/history确认状态，多步回滚须显式指定步数，生产环境禁止使用以防破坏数据完整性。
回滚只在开发/测试阶段安全可用，生产环境禁止执行 yii migrate/down —— 一旦表里有真实数据，dropTable 或 dropColumn 可能直接破坏业务逻辑和外键约束。
为什么 yii migrate/down 什么都没做？
最常见原因是：当前已退到迁移历史起点，或 yii_migration 表为空。Yii 不报错，也不提示，只是静默跳过。
- 先运行
php yii migrate/history，确认输出里有没有带Y（已应用）但没被回滚的记录 - 如果输出是空列表，说明没有可回滚项；如果全是
N，说明还没执行过任何迁移 - 若发现某条记录状态为
Y但对应文件已被删，就得手动清掉yii_migration表里那行 —— 否则后续up会报The migration history is corrupted.
yii migrate/down 默认只退 1 步，多步必须显式传参
它不是“撤销上一条命令”，而是按 yii_migration 表里的版本顺序倒退 N 条记录。
-
php yii migrate/down→ 仅回滚最后 1 次迁移（即最近一次up） -
php yii migrate/down 3→ 倒退最近 3 次已应用的迁移 - 不支持负数或版本号参数；想退到某个具体迁移？得用
yii migrate/to m230510_123456_add_status_to_post
回滚失败时的典型错误和应对
报 No migrations to be reverted，基本等于“没得退了”；报 InvalidConfigException: The migration history is corrupted，大概率是改过已执行的迁移文件但没清理记录。
- 别硬改已执行过的
up()/down()逻辑 —— 迁移文件是快照，不是 SQL 日志 - 如果真要调整，先
yii migrate/down退回，再改文件，再yii migrate/up；但加了--allow-unsafe才允许退已提交迁移 - MySQL 大表上执行
dropColumn会锁表重建，线上执行等于停服 —— 这类操作绝不该出现在down()里
真正难的不是命令怎么敲，而是判断“现在还能不能退”。只要数据库里有业务数据、外键、触发器或视图依赖某个字段，down() 就不再是代码逻辑问题，而是数据完整性问题。
