Yii框架迁移回滚不复原时间戳，仅变更表结构；软删除恢复需手动置deleted_at为null；TimestampBehavior无回退能力，时间字段值须业务层主动重置或备份还原。
Yii框架中数据回滚本身不涉及“时间戳复原”——因为迁移（migrate/down）操作只改表结构或删数据，不会自动还原被修改过的 created_at、updated_at 等时间字段值。所谓“时间戳复原”，实际是两类独立场景的混合表述：一类是迁移回滚后业务数据的时间字段异常；另一类是软删除恢复时时间字段（如 deleted_at）需清空。下面分清楚处理。
迁移回滚后时间字段没变？这本来就不该变
迁移的 down() 方法执行的是结构变更（如 dropColumn、dropTable），它不触碰已有记录的时间字段值。如果你发现某条记录的 updated_at 在回滚后“变回旧值”，那说明：
- 该字段曾在回滚前被业务逻辑或手动 SQL 更新过，回滚并未干涉它；
- 你误以为迁移会“撤销数据修改”，但迁移只管结构，不管业务数据状态；
- 若真需要还原时间字段，得靠业务层主动重置，例如：
$model->updated_at = $originalTime; $model->save(false);（false跳过验证，慎用）。
软删除恢复时 deleted_at 必须设为 NULL
这是最常被当成“时间戳复原”的真实需求。软删除字段（如 deleted_at）本质是 DATETIME 类型，恢复即清空该字段：
- 标准做法：
$user->restore()—— 自动将deleted_at设为null，并触发事件； - 手动补救（Behavior 失效时）：
$user->deleted_at = null; $user->save();—— 注意必须是 PHPnull，不是字符串''或整数0； - 批量清理（无事件，快）：
Yii::$app->db->createCommand()->update('user', ['deleted_at' => null], 'id IN (123, 456)')->execute();
TimestampBehavior 的时间字段不会因迁移回滚而“复原”
TimestampBehavior 只在 beforeInsert 和 beforeUpdate 时写入时间，它不记录历史值，也不提供回退能力。迁移回滚后：
- 如果
created_at字段被迁移删掉了，再加回来也不会自动填旧值——新字段默认为NULL； - 如果只是回滚了某次加字段的迁移（比如删掉
published_at），那该字段及其数据就彻底没了，无法“复原”； - 要保留时间信息，只能在迁移
up()中用$this->insert()补充默认值，或提前导出备份。
真正要防的是回滚破坏时间字段语义
某些危险迁移可能间接导致时间字段失效：
- 在
down()中执行$this->dropColumn('post', 'updated_at')→ 表结构丢失，后续所有更新将跳过该字段； - 把
updated_at类型从DATETIME改成INT再回滚 → 类型错乱，TimestampBehavior写入失败； - MySQL 中设了
ON UPDATE CURRENT_TIMESTAMP，但迁移回滚删了这个属性 → 数据库不再自动更新，但 Yii 不感知，容易造成时间停滞。
