最安全的方式是在模型中配置 $casts 控制单字段序列化格式，如 'published_at' => 'datetime:Y-m-d H:i'，或统一覆盖基类的 serializeDate() 方法；务必确保数据库字段类型匹配，避免 VARCHAR 导致 format() 报错。
直接改模型里的 $casts 或重写 serializeDate() 就行，不用动数据库字段类型、也不用全局替换字符串——改错地方反而会让 API 返回空值或 0000-00-00。
模型里用 $casts 控制单个字段序列化格式
这是最常用也最安全的方式，只影响该字段在 toArray() 和 JSON 响应里的输出，不改变数据库存储或 Carbon 实例行为。
-
'published_at' => 'datetime'：转为 Carbon 实例，toArray()默认输出Y-m-d H:i:s -
'published_at' => 'datetime:Y-m-d H:i'：强制序列化时只输出到分钟，但实例本身仍可调format('H:i:s') -
'expires_on' => 'date'：字段类型必须是DATE，序列化结果固定为Y-m-d字符串，不是 Carbon 实例（不能链式调用） - 如果字段是
VARCHAR或TEXT类型，$casts会静默失败，format()直接报错——先确认数据库列类型
全局改所有模型的 JSON 时间格式，用 serializeDate()
所有模型继承自同一个基类时，覆盖 serializeDate() 是最干净的方案。它只影响 toArray()、toJson() 和 API 响应，不影响查询、赋值或 Carbon 方法调用。
- 在
app/Models/BaseModel.php中定义：protected function serializeDate(DateTimeInterface $date) { return $date->format('Y-m-d H:i:s'); } - 别在
boot()里用Model::serializeUsing()——它对中间表、软删除时间戳等边缘场景支持不稳定 - 如果用了
Carbon::serializeUsing()，记得同时调Carbon::setToStringFormat()，否则echo $model->created_at还是默认格式 - 这个方法不处理
date类型字段（如'birth_date' => 'date'），它们走的是另一套逻辑，得单独配$casts
format() 报错 Call to a member function format() on string 怎么办
说明你访问的字段根本不是 Carbon 实例，而是字符串——Laravel 没有自动转换它。
- 检查数据库字段类型：必须是
DATETIME、TIMESTAMP或DATE，VARCHAR不行 - 确认模型里写了
$casts：比如'event_time' => 'datetime'，而不是只靠$dates（Laravel 9+ 已废弃） - 别从
$model->attributes或getAttributes()直接取值——那绕过了 Eloquent 的 cast 逻辑 - 临时救急可用
Carbon::parse($model->event_time)->format(...)，但别长期这么写，掩盖了配置问题
数据库存 UTC，API 却要东八区时间？别在序列化里硬转
在 serializeDate() 里调 $date->timezone('Asia/Shanghai')->format(...) 看似简单，实则埋雷：所有时间字段都会被强制转时区，包括本该保持 UTC 的审计日志、定时任务触发点。
- 正确做法是：入库前统一
$date->utc()，查出来后按需转——比如在资源类（Resource）里做：'published_at' => $this->resource->published_at->timezone('Asia/Shanghai')->toDateTimeString() - 或者前端传时区标识，后端用
Carbon::createFromFormat(...)->tz(request()->timezone)动态处理 - 真要全局转，也该在响应层（如 API Resource 或中间件）控制，而不是污染模型序列化逻辑
最容易被忽略的是：改了 $casts 或 serializeDate() 后，whereDate()、whereBetween() 这些查询依然走原始数据库值，和序列化格式完全无关——别指望改个 format 就能影响 SQL 条件。
