Inertia.js Laravel 适配器中延迟属性的评估优化

在 Inertia.js 的 Laravel 适配器 v2 beta1 版本中，开发者发现了一个关于延迟属性评估的重要问题。这个问题会影响使用 Optional 和 lazy 属性的应用性能，特别是在部分重载(partial reload)场景下。

问题本质

当使用 Inertia.js 的延迟加载功能时，即使某些共享属性被标记为 Optional (使用闭包形式定义)，这些属性也会在部分重载时被不必要地评估执行。例如：

"shared_list" => fn() => // 某些耗时的数据获取逻辑

按照设计预期，这些使用闭包定义的属性应该只在真正需要时才被评估执行。但在 v2 beta1 版本中，所有属性都会在响应解析阶段被评估，无论它们是否最终会被包含在响应中。

技术分析

问题的根源在于 Response 类的 resolveProperties 方法中属性解析和过滤的执行顺序。原始代码会先解析所有属性，然后再应用 only 或 except 过滤器。这种顺序导致了不必要的属性评估。

// 原始问题代码逻辑
$props = $this->resolveArrayableProperties($props, $request); // 先解析所有属性
$props = $this->resolveOnly($props, $request); // 后过滤
$props = $this->resolveExcept($props, $request);

解决方案

通过调整执行顺序，将属性解析移到过滤之后，可以避免不必要属性的评估：

// 修正后的逻辑
$props = $this->resolveOnly($props, $request); // 先过滤
$props = $this->resolveExcept($props, $request);
$props = $this->resolveArrayableProperties($props, $request); // 后解析真正需要的属性

这种调整确保了只有最终会被包含在响应中的属性才会被评估执行，从而提高了性能，特别是对于那些包含复杂逻辑或数据库查询的延迟属性。

实际影响

这个问题会对以下场景产生显著影响：

1. 包含大量共享属性的应用
2. 共享属性中包含复杂逻辑或耗时操作的应用
3. 频繁使用部分重载功能的单页应用

在最新版本中，这个问题已经被修复。开发者可以放心使用延迟属性功能，确保只有在真正需要时才会执行相关逻辑。

最佳实践

对于使用 Inertia.js Laravel 适配器的开发者，建议：

1. 对于耗时的数据获取逻辑，始终使用闭包形式定义
2. 合理使用 only 和 except 来限制响应中包含的属性
3. 及时更新到最新版本以获取性能优化

这种属性评估优化对于构建高效的单页应用至关重要，特别是在数据获取成本较高的场景下，可以显著减少不必要的服务器负载和网络传输。