API资源本身不加速，真正拖慢响应的是未控制的关联加载、重复计算和无条件字段渲染；优化核心是切断N+1、跳过未加载关联、剥离运行时开销，如避免toArray中新建Carbon实例、重复Storage解析及修改$this->resource。
API资源本身不加速，它只负责格式化输出；真正拖慢响应的，是资源里没控制好的关联加载、重复计算和无条件字段渲染。优化核心不是改toArray写法，而是切断N+1、跳过未加载关联、剥离运行时开销。
为什么UserResource::collection($users)一查就卡
常见现象：返回100个用户时，接口耗时从200ms飙升到3s以上，日志里出现上百条SQL查询。
- 根本原因不是
UserResource本身慢，而是每个$this->posts在toArray里被直接访问，触发懒加载 -
whenLoaded('posts')必须显式调用，否则Eloquent不会跳过未预加载的关联 - 即使写了
with('posts')，如果控制器里漏了->loadMissing('posts')，资源仍会 fallback 到懒加载
toArray里哪些操作实际吃CPU
看似简单的格式化，某些写法会在循环中反复执行高开销操作。
-
'created_at' => $this->created_at->format('Y-m-d H:i:s')：每次调用都新建Carbon实例，100条记录≈100次对象构造 -
'full_name' => $this->first_name . ' ' . $this->last_name：字符串拼接本身快，但若first_name是数据库字段，且没加select()限定，就会多读两个字段 -
'avatar_url' => Storage::url($this->avatar)：每次调用都走一遍Storage驱动解析，建议提前生成并缓存到模型属性
怎样让资源不成为性能瓶颈
关键不是“怎么写得更漂亮”，而是“怎么让它少干活”。
- 控制器里强制预加载所有资源要用的关联：
User::with(['posts', 'profile'])->get()，别信“后面资源里再whenLoaded也来得及” - 把运行时计算移到模型访问器里，并用
appends声明，避免在toArray里重复判断：protected $appends = ['is_active']; - 对高频字段（如状态码转文字）用
match或查表数组，别用if/else链或函数调用 - 资源类本身不处理分页，交给
ResourceCollection或PaginatedResourceResponse——自己在toArray里手动塞meta会破坏复用性
最易被忽略的一点：资源类里的$this->resource是原始模型实例，不是克隆体。任何在toArray里对$this->resource的修改（比如$this->resource->name = strtoupper(...)）都会污染后续使用该模型的其他逻辑。别动它，只读取。
