访问器应避免触发数据库查询、重复对象实例化及JSON解析异常，仅执行纯内存操作，必要时用预加载、缓存或$casts优化，且须校验空值与数据结构。
访问器不是“越写越多就越优雅”，而是写错一个就可能拖慢整条请求链。关键不在数量，而在是否在序列化时触发了不该触发的逻辑。
getXXXAttribute 方法里别查数据库
常见错误是把 getIsLikedAttribute 写成带 auth()->id() 查询关联表的逻辑，结果每次 $post->toArray() 都执行一次 SQL。这类访问器一旦放进 $appends，就会在 JSON 响应中无差别执行。
- 只做纯内存操作：字符串处理、日期格式化、数组合并等
- 需要查库的逻辑，改用显式方法（如
isLikedBy($user)）或预加载关系后判断 - 如果必须动态计算，至少加一层缓存：用
$this->attributes['is_liked'] ??= ...避免重复执行
Carbon 日期访问器要防重复实例化
直接在 getCreatedAtAttribute 里写 Carbon::parse($value) 看似干净，但每次访问都新建对象；若模型被序列化多次（比如同时用于 API 响应和日志记录），开销会叠加。
- 推荐复用：先判断是否已存在实例，再解析
return $this->attributes['created_at'] instanceof Carbon ? $this->attributes['created_at'] : Carbon::parse($value); - 更稳妥的做法是配合
$casts：在模型里声明protected $casts = ['created_at' => 'datetime'];，让框架自动处理，访问器只负责格式化输出（如转为中文时间） - 避免在循环中批量访问该属性——宁可用
map提前转好，也不要让每个模型自己 parse 一遍
JSON 字段访问器必须加空值防护
getPreferencesAttribute 这类解析 JSON 的访问器，最容易在生产环境崩掉，因为数据库字段可能是 null、空字符串、甚至损坏的 JSON。
- 永远用
json_decode($value, true) ?? []，不能只靠?? []，因为json_decode('invalid', true)返回null - 如果业务强依赖结构，建议加简单校验：
is_array($decoded) ? $decoded : [] - 不要在访问器里做深层嵌套转换（如把 JSON 里的时间字符串再 parse 成 Carbon）——拆成两个访问器，或由调用方按需处理
最常被忽略的一点：访问器的执行时机不可控。它可能在你完全没意识到的地方被触发，比如日志记录、队列任务序列化、甚至某些调试工具 dump 模型时。写之前先问一句：这个转换，是不是真的每次都要做？
