访问器仅在读取模型属性时触发，不修改数据库、不参与保存，只影响$model->attribute返回值；方法名为get{Attribute}Attribute，接收原始值并返回格式化结果，不操作$this->attributes，且不介入查询或序列化，除非显式加入$appends。
访问器（Accessor）只在读取模型属性时触发，不改数据库、不参与保存逻辑，只影响 $model->attribute 的返回值。
访问器方法名必须是 get{Attribute}Attribute
比如数据库字段叫 user_name，对应访问器方法名是 getUserNameAttribute；字段是 is_active，方法就是 getIsActiveAttribute。Laravel 会自动把下划线转驼峰去匹配。
- 方法必须是
public，且只接受一个参数（即原始数据库值） - 必须
return处理后的值，Laravel 直接用这个返回值作为属性读取结果 - 不要在方法里写
$this->attributes['xxx'] = ...——那是修改器干的事，访问器改的是“读出来什么样”，不是“存成什么样”
getCreatedAtAttribute 这类时间访问器容易踩时区坑
如果你只是想格式化显示，别动原始值；但若直接用 strtotime($value) 或 date() 硬转，会绕过 Laravel 的 Carbon 封装和时区设置。
- 推荐方式：先确保
$casts已声明'created_at' => 'datetime'，再在访问器里调用$value->format('Y-m-d') - 错误写法：
return date('Y-m-d', strtotime($value))—— $value 可能已是 Carbon 实例，strtotime会报错或返回意外结果 - 更安全的判断：
return $value instanceof \Carbon\Carbon ? $value->format('m/d/Y') : $value
访问器不触发查询，也不影响 where 条件
User::where('name', 'John')->get() 不会走 getNameAttribute；$user->name 才会触发。这是初学者最常混淆的一点。
- where 查询永远基于数据库字段原始值，访问器对 SQL 层完全透明
- 如果你需要按格式化后结果筛选（比如“查所有生日在本月的用户”），得用
whereRaw或数据库函数，不能依赖访问器 - 访问器返回值不会被序列化进 JSON 默认响应 —— 除非你显式加到
$appends数组里
访问器真正的价值在于解耦展示逻辑和存储逻辑，但它的边界非常清晰：它只在模型实例被读取时生效，且绝不碰数据库、不干预查询、不改变底层数据结构。一旦开始想让它“影响查询”或“自动同步到其他字段”，就该考虑事件监听器或业务服务层了。
