$casts能解决80%类型转换需求，但需字段名、数据库类型、php类型三者严格匹配；不生效主因是键名不一致、字段类型不支持目标cast或null未处理。
直接用 $casts 就能解决 80% 的类型转换需求，不用写访问器或修改器——但前提是字段名、数据库类型、PHP 类型三者对得上，否则它就“假装没看见”。
为什么 $casts 不生效？先查这三件事
最常见的失效不是配置错，而是底层不匹配：
- 数据库字段名和
$casts数组的键必须**完全一致**：包括下划线、大小写、甚至空格（比如迁移里是is_active，模型里就不能写成isActive） - 数据库类型要支持目标 cast：
boolean只认TINYINT(1)，VARCHAR存'1'或'true'都不会被转成布尔值 -
date和datetime要求字段是DATE或DATETIME类型；如果字段是TIMESTAMP，且应用时区和数据库时区不一致，Carbon 实例的时间可能偏移
验证是否生效：别只看 dd($model->active)，用 gettype($model->active) 或 var_export($model->active) 看真实类型。PHP 的 echo true 显示 1，不代表它不是布尔值。
什么时候该写自定义 Cast 类，而不是访问器？
当你需要**双向、可复用、不绕过 Eloquent 生命周期**的转换时，选自定义 Cast 类；访问器只管读，修改器只管写，还容易漏逻辑。
- 适合场景：把数据库里的
price_cents（整数）转成Money对象，且保存时自动回写为整数；或把 JSON 字符串转成不可变的PhoneNumber实例 - 关键点：必须实现
Illuminate\Contracts\Database\Eloquent\CastsAttributes接口，包含get()和set()两个方法 - 别踩坑：
getCastType()只控制读取，不处理写入；直接重写castAttribute()会跳过 Laravel 的 Cast 管理器，null 处理、批量赋值、序列化都可能出问题 - Laravel 9+ 推荐在模型里用
castUsing()声明，而不是在$casts里写类名字符串，更易测试和调试
访问器和修改器只在模型赋值时触发，别指望它们管 SQL
它们不是“魔法拦截器”，只是 PHP 层的钩子函数，对查询条件、批量更新、原生 SQL 完全无效。
-
setPublishedAtAttribute($value)里把字符串转成 Carbon 并格式化为Y-m-d H:i:s，只影响$post->published_at = '2025-01-01'这种写法；但Post::where('published_at', '>', '2025-01-01')->get()里的条件仍按数据库原生格式比，不会被修改器处理 - 修改器必须手动写进
$this->attributes['field_name']，漏掉这句，数据根本不会存进去 - 批量操作如
User::where(...)->update([...])或DB::table()->update()完全不走修改器——这些绕过了模型实例 - 密码哈希、邮箱小写这类标准转换，优先用
$casts或模型事件，比手写修改器更稳、更易覆盖测试边界
toArray() 输出不对？先看原始值和转换链顺序
toArray() 是最终结果，但它背后有明确执行顺序：$casts → 访问器 → $appends。任何一环断掉，输出就失真。
- 字段没出现在数组里？检查
$hidden/$visible里的字段名是否拼错，或者$appends里写的名称和访问器方法名不一致（比如$appends = ['is_admin']，但访问器是getIsAdminAttr()，少了个ibute） - 关联数据为空？
toArray()不会自动加载关联，必须提前调用$model->load('relation')或用with() - 别重写
toArray()方法：Laravel 7+ 不建议覆盖它，否则所有访问器、$casts、$appends全部失效 - 调试技巧：
$model->getAttributes()看原始数据库值，$model->toArray()看最终输出，对比就能定位哪一层掉了链子
最常被忽略的是 null 处理和字段映射一致性——比如自定义 Cast 里没判断 $value === null，或者数据库字段是 JSON 类型却用了 'array' 而不是 'json'，导致返回对象而非数组。
