关于 Eloquent accessor 的性能问题，有一个核心判断：getXXXAttribute 方法真的是不适合放什么耗时逻辑的。为什么这么讲？因为每次你访问这个属性，哪怕是在同一个模型实例的生命周期内，它都会老老实实地重新执行一遍。
比如你在 getFullNameAttribute 里想拼接一个在数据库里并不存在的字段——你猜怎么着？每次访问它都会重新算一遍。如果这个拼接操作里还涉及调用外部 API、做复杂的数组遍历，那重复触发、反复计算，就纯粹是性能浪费了。
更隐蔽的问题是：Eloquent 并不会自动帮你缓存 accessor 的返回值，也不会敏感地察觉到内部逻辑是不是“幂等”的。你可能会想手动加 $this->attributes['full_name'] 来赋值，但真的不行——因为 accessor 本质上是只读的计算逻辑，往里面写入数据会直接污染原始属性。这一污染，后续你去调 toArray() 或者 sa ve()，很可能就跑偏了。
所以，下面这些情况最好坚决避免：
- 不要在 accessor 里查库、发 HTTP 请求、解密大字符串
- 不要试图用
$this->setAttribute('xxx', $val)来缓存结果——这会破坏数据一致性 - 如果实在要延迟计算并且复用，那必须自己来管理生命周期和缓存边界
用私有属性 + 惰性初始化实现单实例内缓存
最轻量、零依赖的方案，其实很简单：在模型类里声明一个私有属性（比如 $fullNameCache），然后在 accessor 中判断一下——已经算过了就直接返回，没算过就执行计算再赋值。这就行了。
class User extends Model{
private $fullNameCache;
public function getFullNameAttribute()
{
if ($this->fullNameCache !== null) {
return $this->fullNameCache;
}
// 这里放真正耗时逻辑，比如：
$this->fullNameCache = trim($this->first_name . ' ' . $this->last_name);
return $this->fullNameCache;
}
}
有几个细节值得注意：
- 缓存变量必须是
private，避免被外部误改或序列化时带出去 - 不能用
static，否则不同User实例会互相污染，影响数据准确性 - 如果属性依赖其他动态字段（比如关联模型变化），需要手动重置该缓存
关联变更时如何清空缓存
当 accessor 依赖了关联模型（比如 $this->posts->count()），而你在当前请求中又修改了 posts 数据，那缓存就过期了。Eloquent 不会自动通知你，你得手动干预。
常见做法是：在关联更新后显式重置缓存变量。
- 在
attach()/detach()后手动设$this->fullNameCache = null - 监听模型事件（如
sa ved），检查是否影响相关字段，再清缓存 - 更稳妥的做法：把缓存逻辑抽成独立方法，调用处统一控制生命周期，而不是全塞在 accessor 里
举个例子：
public function refreshFullNameCache()
{
$this->fullNameCache = null;
return $this;
}
// 使用时
$user->posts()->attach($post);
$user->refreshFullNameCache();
需要跨请求缓存？别硬套 Eloquent accessor
如果“减少重复计算”指的是跨 HTTP 请求的场景（比如首页多次显示用户头衔），那 Eloquent 层面的缓存其实意义不大——模型实例早就销毁了。这时候应该换思路：
- 用 Lara vel 的
Cache::remember()做键值缓存，key 包含模型 ID 和版本标识（比如"user:{$id}:full_name:v2"） - 在模型的
sa ved事件中主动清除对应缓存 - 避免在 accessor 内直接调用
Cache::get()——它可能触发 IO，而且违背了“计算属性应该轻量”的设计直觉
说到底，真正该放在 accessor 里的，只是“本实例内不重复算”这样的小优化；跨请求的一致性，得靠应用层的缓存策略来兜底。
容易被忽略的是缓存键的设计。ID 相同但业务含义不同（比如审核前后的头衔不一样）时，v1/v2 版本号或者逻辑的 hash 必须跟着变，否则缓存雪崩或者脏读就容易出现了。
