macOS SwiftUI 2.0约300项长列表滚动卡顿问题求助

针对你已经试过替换LazyVStack、给List加id、接入自定义滚动条都没有改善的情况，结合SwiftUI 2.0在macOS端的已知性能短板，按排查优先级从高到低梳理可落地的修复方向：

排查假懒加载的实现问题 #

很多开发者切换到LazyVStack后以为自动获得了懒加载能力，实际在SwiftUI 2.0中，这类实现经常会退化为全量渲染：

• 不要提前遍历全量300条数据源，生成所有Row视图的实例数组后再塞给LazyVStack。这种写法哪怕用了懒加载容器，也会在初始化阶段就把所有300个Row的对象全部创建完成，和普通VStack没有性能差异。正确写法是直接在LazyVStack的闭包内部遍历原数据源，让框架自行判断哪些视图需要被加载渲染。
• 给每个Row明确指定固定高度的frame约束，同时对齐方式设为前导对齐。没有明确高度约束的Row，会触发SwiftUI 2.0的全尺寸布局遍历，哪怕屏幕上只显示5-6个Row，系统也会为所有300个Row计算布局尺寸，直接占用主线程渲染时间。

定位Row层的冗余渲染开销 #

你之前给List加id标识的操作，如果没有下沉到单个Row的层级，根本不会触发生成的视图diff优化：

• 检查每个Row的body中是否存在同步重型计算。比如在body里实时做图片解码、时间格式转换、富文本解析这类操作，哪怕只有少量Row在屏幕内，每次滚动加载新Row时，这类同步计算都会阻塞主线程的渲染循环。这类计算需要提前在数据源加载阶段完成，把结果存在模型结构体中，Row的body仅做取值渲染。
• 清理Row上不必要的onAppear逻辑。SwiftUI 2.0的List和LazyVStack在滚动过程中，离屏Row会频繁触发onAppear/onDisappear回调，如果回调里写了状态更新、网络请求这类操作，会直接打断渲染节奏。
• 把Row抽成独立的结构体，手动实现Equatable协议。SwiftUI 2.0默认的视图diff逻辑会对所有属性做全量比对，如果Row携带的模型包含嵌套引用类型，每次上层状态更新时都会触发全量Row的比对开销。手动指定比对的关键字段，可以将比对开销降低80%以上。

SwiftUI 2.0 专属的框架兜底优化 #

这部分是后续SwiftUI版本已经修复、但2.0版本必须手动处理的问题，也是很多常规优化方案无效的核心原因：

• 移除Row上不必要的离屏渲染修饰符，比如无特殊需求的cornerRadius、clipped()、自定义阴影。SwiftUI 2.0在macOS端对带离屏渲染的视图，滚动时会强制走CPU重绘，哪怕只有3个这类Row在屏幕内，也会把帧率压到30以下。
• 检查外层ScrollView的修饰符列表，不要叠加refreshable、自定义滚动拦截这类会触发额外渲染管线的修饰。SwiftUI 2.0的ScrollView和底层AppKit的NSScrollView衔接存在已知性能bug，一旦检测到这类自定义修饰，会自动切换为全量视图渲染模式，直接废掉Lazy容器的懒加载效果。
• 如果以上调整后还是达不到满帧效果，不需要硬扛框架的性能bug。可以将外层列表容器替换为AppKit层的NSCollectionView包装，300条的规模在成熟的AppKit列表组件上可以轻松实现满帧滚动。

内容的提问来源于stack exchange，提问作者Charly