created_at自动填充不生效，是因为未同时满足字段名/类型匹配、模型显式开启$autoWriteTimestamp=true、且调用模型方法（非Db原生操作）；默认只识别create_time/update_time，需手动配置$createTime='created_at'等。
ThinkPHP模型的 created_at 自动填充不会生效，除非你同时满足三个硬性条件：字段名/类型匹配、模型显式开启、且调用的是模型方法而非原生Db操作。
为什么 created_at 字段没写入数据库
最常见原因是字段名不被识别——ThinkPHP 5.1+ 默认只认 create_time 和 update_time，哪怕你数据库里建的是 created_at，不配模型属性就直接跳过自动写入。
- 检查模型中是否声明了
protected $createTime = 'created_at'; - 确认数据库字段类型是
DATETIME、TIMESTAMP或INT；若为INT，还需在模型中加protected $type = ['created_at' => 'integer'];，否则会尝试转字符串导致入库失败 - 确保没误设
protected $readonly = ['created_at'];——这个设置会让字段彻底“失能”，连手动赋值都无效 - 验证是否用了
Db::table()->insert()这类绕过模型的操作，自动时间戳只在$model->save()、create()、update()中触发
$autoWriteTimestamp 开关必须显式设为 true 或具体类型
全局配置 'auto_timestamp' => true 在 database.php 里只是“允许”，不是“启用”；真正起效靠模型自身的 $autoWriteTimestamp 属性。
- 设为
true：按字段类型自动选格式（INT存时间戳，DATETIME存'Y-m-d H:i:s'） - 设为
'datetime'：强制用字符串格式，即使字段是INT类型也会转成字符串（大概率存成0000-00-00 00:00:00） - 设为
'timestamp'：强制用整数时间戳，即使字段是DATETIME也会转成数字再入库（MySQL 可能报错或截断） - 漏写这行声明，整个自动写入链路完全不启动，连错误提示都不会有
更新时 updated_at 不变，不是 bug 是设计
ThinkPHP 的 updateTime 默认只在“检测到数据实际变更”时才刷新，不是每次 save() 都覆盖。比如 $user->name = 'a'; $user->save();，但数据库当前值已经是 'a'，那 updated_at 就不动。
立即学习“PHP免费学习笔记（深入）”；
- 想强制更新，用
$user->isAutoWriteTimestamp(true)->save();（注意参数是true，不是false） - 如果字段名是
updated_at，记得同步配protected $updateTime = 'updated_at'; - MySQL 严格模式下，若字段不允许 NULL 且没设默认值，而自动写入又因条件未满足没触发，会导致该字段插入
''报错——建议设字段默认值为CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP作兜底
字段白名单和 beforeWrite 钩子容易被忽略
自动时间戳逻辑发生在 beforeWrite 钩子里，一旦你在模型里重写了这个方法，又没调用 parent::beforeWrite($data, $type);，整个自动填充就断了。
- 检查模型是否定义了
protected $field = [...]，漏掉created_at会导致它被过滤掉，哪怕自动写入逻辑跑通了也进不了 SQL - 调试时可用
allowField(true)临时放开白名单，但上线前必须收口，否则可能引发越权写入 - 如果用了自定义填充（比如通过
creating事件），要确保没和自动时间戳逻辑冲突——两个地方同时写同一个字段，后执行的会覆盖前一个
