created_at被重复更新的根本原因是timestampbehavior配置错误、数据库on update机制干扰、beforesave中未判断插入场景或批量操作误写入。应仅在insert时赋值，禁用db层自动更新，并在业务逻辑中区分$insert标志。
Yii框架中 created_at 被重复更新，根本原因在于行为配置不当或数据库层自动机制干扰。它本该只在插入时写入一次，若在更新操作中也被重置，就违背了设计语义，可能影响日志、统计、缓存等依赖创建时间的逻辑。
检查 TimestampBehavior 配置是否误含 created_at 更新
最常见的原因是把 created_at 错误地加入 EVENT_BEFORE_UPDATE 触发列表。正确做法是仅让它响应插入事件：
-
错误写法（会导致每次 update 都刷新 created_at）：
'attributes' => [ActiveRecord::EVENT_BEFORE_INSERT => ['created_at', 'updated_at'],ActiveRecord::EVENT_BEFORE_UPDATE => ['created_at', 'updated_at'], // ❌ 不该包含 created_at] -
正确写法（created_at 仅插入时赋值）：
'attributes' => [ActiveRecord::EVENT_BEFORE_INSERT => ['created_at', 'updated_at'],ActiveRecord::EVENT_BEFORE_UPDATE => ['updated_at'], // ✅ 只更新 updated_at]
确认数据库字段类型与默认行为不冲突
如果数据库表中 created_at 是 TIMESTAMP 类型且定义了 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，那么即使 Yii 没动它，MySQL 也会在 UPDATE 时自动覆盖——这会掩盖 PHP 层的行为逻辑，造成“明明没设却变了”的错觉。
- 查表结构：
SHOW CREATE TABLE your_table;，确认created_at是否带ON UPDATE - 修复建议：将
created_at改为TIMESTAMP DEFAULT CURRENT_TIMESTAMP（无 ON UPDATE），或直接用DATETIME类型，完全交由 Yii 控制
避免手动赋值或 beforeSave 中误覆盖
有些业务逻辑会在 beforeSave() 里统一处理时间字段，若未加判断，容易覆盖已存在的 created_at：
- 错误示例：
public function beforeSave($insert) {$this->created_at = time(); // ❌ 插入/更新都执行，破坏原始值return parent::beforeSave($insert);} - 正确写法（仅插入时设置）：
public function beforeSave($insert) {if ($insert) {$this->created_at = time(); // ✅ 仅首次插入}$this->updated_at = time();return parent::beforeSave($insert);}
批量操作时绕过 ActiveRecord，需显式控制字段
使用 batchInsert() 或 updateAll() 时，AR 的 behaviors 不生效，必须人工确保 created_at 不被写入更新语句：
- 批量插入：构造数据时提供
created_at值，但不要在updateAll()中包含该字段 - 例如更新用户状态：
User::updateAll(['status' => 1], ['id' => $ids]);—— 不要写成['status' => 1, 'created_at' => time()] - 若需兼容旧数据补全缺失的
created_at，应单独用updateAll()加条件，如['created_at' => time()], ['created_at' => null]
