Eloquent 的 getAttribute 或访问器本身不会“死”，问题在于日期类型未正确配置导致解析失败；应优先用 $casts = ['deadline' => 'datetime'] 替代 $dates，访问器需兜底 null，前端传 ISO 格式时间并统一时区。
直接说结论：Eloquent 的 getAttribute 或访问器（accessor）本身不会“死”，但如果你在模型里写了一个叫 deadlines 或 deadline_l 的属性，又没配好类型转换、时区或日期格式，它会在取值时返回 null、错误时间戳，甚至抛出 DateTime::__construct(): Failed to parse time string —— 这不是属性“死了”，是解析断了。
为什么 deadline 字段取出来是空或报错？
常见于数据库字段类型为 datetime / timestamp，但 PHP 模型没声明为日期类型，或前端传入的字符串格式不被 Carbon 自动识别（比如 "2025-03-28 23:59:59" 看似标准，但在某些 MySQL 严格模式下会因时区或微秒精度被截断）。
- 检查迁移文件中该字段是否用了
$table->datetime('deadline')或更稳妥的$table->timestamp('deadline') - 确认模型中已添加
protected $dates = ['deadline'];（Laravel 8+ 推荐改用$casts） - 若用 Laravel 9+，优先写成：
protected $casts = ['deadline' => 'datetime'];，它比$dates更可靠，且支持自定义格式如'datetime:Y-m-d H:i:s' - 避免在访问器里手动 new DateTime() —— Carbon 已自动处理，重复解析反而容易崩
怎么安全地加一个 isDeadlinePassed 访问器？
别在访问器里写 Carbon::now()->gt($this->deadline) 这类逻辑，因为当 $this->deadline 是 null 或非法值时，gt() 会报错。要先兜底。
public function getIsDeadlinePassedAttribute()
{
if (! $this->deadline) {
return false;
}
return $this->deadline->isPast();
}
-
isPast()内部已做 null 判断，比手写Carbon::now()->gt(...)更健壮 - 如果业务需要考虑「宽限期」，比如过期后 1 小时内仍算有效，就用
$this->deadline->addHour()->isPast() - 不要把访问器命名成
deadline_passed（带下划线），Laravel 默认按驼峰解析，isDeadlinePassed才能正确映射为is_deadline_passedJSON 键
前端传 deadline 时间字符串，后端总存成当天零点？
典型现象：前端传 "2025-03-28"，入库变成 "2025-03-28 00:00:00"。这不是 Eloquent 的锅，是 Carbon 解析策略导致的 —— 它对纯日期字符串默认补零时分秒。
立即学习“PHP免费学习笔记（深入）”；
- 解决方案一（推荐）：前端传带时间的 ISO 格式，例如
"2025-03-28T23:59:59"，服务端$casts保持'datetime'即可原样入库 - 解决方案二：在模型的
setDeadlineAttribute中做强制补全：public function setDeadlineAttribute($value) { if ($value && ! is_a($value, \Carbon\Carbon::class)) { $this->attributes['deadline'] = Carbon::parse($value)->endOfDay(); } }注意这里用endOfDay()而非format()，避免类型丢失 - 千万别在控制器里用
strtotime()转再塞给模型 —— 绕过 Eloquent 铸造机制，时区和精度全乱
真正容易被忽略的是数据库连接的 timezone 配置和应用层 date_default_timezone_set() 是否一致。哪怕 $casts 写对了，MySQL 会话时区设成 +00:00 而 PHP 设成 Asia/Shanghai，deadline 存进去就差 8 小时 —— 这种问题不会报错，只会悄悄错。
