Performance, Display Density & Usage Considerations

同学们，今天咱们要聊的这块内容，虽然看起来信息挺碎，但每一条都是在实际开发中能帮你少走弯路的宝贝。我先从性能优化说起，再到表单显示密度，最后落到记录类型和操作覆盖，咱们一步一步来理解。 好，先说，性能优化，。在Lightning里，有一条铁律——，数据集一定要小，。记住一个黄金上限：页面最多展示，1000行，，每行最多，5列，。超过这个数，用户体感就会明显变慢。别想着把所有数据一股脑全扔给浏览器，要用，无限滚动，去渐进式加载，用户滚到哪数据才跟到哪。还有，，内联编辑，一定要省着用，只把那些真正需要频繁改动的关键字段放开，其他字段就老老实实只读。自定义数据类型也往简单了做：尽量减少与服务端的往返交互，我们管这叫“Inbox操作”——也就是后台Apex的调用次数，要能省则省。对象关系嵌套不要太深，查询时用，LIMIT，来翻页，另外如果你已经加载了超过250行数据，列数最好控制在，20列以内，，这样界面的渲染压力会小很多。 聊完性能，咱们看一个常常被忽视但直接影响用户手感的功能——，显示密度，。在Lightning里，表格和表单标签的定位会跟着密度设置变。，舒适模式，下，标签稳稳地放在字段上方，看着清爽；而，紧凑模式，下，标签会和字段嵌在同一行里，节省空间。在记录表单组件`lightning-record-form`上，直接有个`density`属性，你可以把它设为`comfy`或者`compact`，这个设置会覆盖掉组织级的密度配置，非常适合按场景微调。如果想更细地控制某个字段的标签样式，还可以用单个字段组件的`variant`属性，比如`label-hidden`隐藏标签、`label-stacked`让标签搁在字段上面。另外，有一个CSS类值得记住：`slds-form-element_1-col`，把它加到表单元素上，能在紧凑模式下极好地拉近标签和字段之间的间距，让表单看起来更紧凑又不凌乱。 接下来，咱们谈，记录类型，。当你的对象有很多种记录类型时，应该先调用，`getObjectInfo`，这个服务，从返回的元数据里读出当前用户能用的记录类型有哪些，然后把选中的记录类型ID通过`record-type-id`属性传给`lightning-record-form`或者`lightning-record-edit-form`。这样表单就会自动按类型显示出对应的字段，不用你手动拼布局。 表单提交成功后，父组件怎么知道创建了哪条新记录呢？这就要靠，自定义事件，。监听表单的`onsuccess`事件，在回传的`event.detail`里能得到新记录ID，父组件拿到ID后就能做后续跳转或刷新列表了。这个模式让组件之间保持松耦合，一个表单不直接操作父级逻辑，只负责上报结果。 最后这个知识点虽然偏底层，但很多新人容易卡住——，标准操作覆盖，。假如你想把一个LWC做成新建、编辑这种标准动作的替代页面，直接引LWC是不行的。Lightning要求你必须把这个LWC，包裹在一个Aura组件里，，然后在Aura组件上实现`lightning:actionOverride`接口。简单说就是Aura做壳，LWC当内核，这样标准操作按钮点开时，系统才能正确识别并调用你的自定义界面。 好了，今天这几块内容杂而不乱，帮你梳理完它们之间的逻辑，下次写代码的时候试试带着这些优化和配置思路，整个应用体验立马就上来了。如果有哪个点没听明白，随时提，我再细讲。