Batching & Client-Side Caching

大家好，今天我们来看一个非常重要的细节——Apex动作按钮的排队发送机制，还有跟它相关的@wire缓存刷新。这个机制框架会自动处理，我们感觉不到，但它对性能影响很大，所以一定要理解。 首先，当你点击按钮调用Apex方法的时候，Lightning Web Components框架不是立即一个个把请求发出去，而是会悄悄地把这些调用排好队，然后合并成一批，一次性发送到服务器。这个过程叫“boxcar”，就像把很多小车箱挂在一辆火车头上一起拉走。这样做的目的是为了尽量减少网络请求次数，提升整体性能。这个过程是透明的，我们不需要写任何代码去处理。 但要小心，如果一个页面上累积的调用数量太多，超过了2500个，服务器就会返回413错误，请求就失败了。所以如果真的遇到这种情况，你就得重新设计组件，把操作合并或者减少不必要的调用，千万别让它堆积到2500个。 接下来是@wire。用@wire装饰的Apex方法必须在方法定义里标记cacheable=true，这样它返回的数据就会被框架缓存起来。我强烈建议你在命令式调用中也尽量利用这种缓存，因为缓存的数据可以瞬间加载，用户不用等待服务器响应，体验会顺畅很多。 那么，问题来了——如果你通过命令式Apex修改了记录数据，比如更新了一个字段，那LDS（Lightning Data Service）的缓存就过时了。这时候你需要主动告诉缓存：“嘿，你的数据旧了，需要更新一下。” 怎么告诉呢？调用notifyRecordUpdateAvailable()这个方法，LDS就会知道自己持有的数据可能过时了，下次请求时会重新获取。 如果你的操作影响到了某个用@wire拿到的数据，比如你改了数据，导致某个wire的结果也跟着变了，这时候就需要用refreshApex()来手动刷新那个wire。用的时候要记住，refreshApex()会立即发起一次网络请求去拿最新的数据，所以只能在你知道缓存已经陈旧的情况下使用它。绝对不要在轮询循环里用refreshApex()，那样会每轮都发一次请求，毫无意义地消耗资源。 另外，对于用@wire装饰的函数，你要注意：这个函数被调用时会收到一个数据对象，你需要把这个对象保存下来，之后调用refreshApex()时，就把它作为参数传进去。这样框架就知道你要刷新的是哪个wire的结果。 总结一下，理解boxcar机制能帮你避免413错误，合理使用缓存和刷新方法，能让你的组件既高效又及时反映数据变化。记住这几点，你的组件就会更健壮、性能更好。