List 还是 LazyVStack：SwiftUI 中的惰性容器选择

基于 fatbobman.com 博文整理

---

一、概述

List 和 LazyVStack（通常与 ScrollView + ForEach 组合使用）是 SwiftUI 中两大核心惰性容器。它们在某些场景下表现相似，但底层架构、设计哲学和适用场景各不相同。本文从六个维度进行对比分析。

说明： 本文中 LazyVStack 的特性大多也适用于 LazyHStack 及其他 Lazy 系列容器。

---

二、底层实现：不同的起源

维度	List	LazyVStack
首次亮相	SwiftUI 1.0（首个版本）	SwiftUI 2.0（第二年）
底层技术	UIKit/AppKit 封装	SwiftUI 原生实现
iOS 13–15	基于 UITableView	—
iOS 16+	基于 UICollectionView	—
UIKit 依赖	✅ 依赖	❌ 不依赖

这种根本性的实现差异，是导致两者在性能、功能、定制灵活性和布局逻辑等方面表现各异的根源。

---

三、风格化与预设功能

3.1 LazyVStack — 简约灵活

• 与 VStack 类似，专注于纯粹的布局功能
• 严格遵循布局规则，不会自动添加额外样式
• 如同一张白纸，为开发者创意提供无限可能

3.2 List — 功能丰富

• 不仅是容器，更是一个功能丰富的 UI 组件
• 通过 listStyle 可轻松切换多种预设视觉模板
• 提供一系列独特的交互能力：
  • 滑动操作（swipeActions）：专属于 List 子视图
  • onDelete / onMove：ForEach 的这两个功能仅在 List 中生效
  • 编辑模式：内置支持基于手势的项目重排，SwiftUI 中独一无二
• 丰富的构造方法，与 ForEach 和数据绑定深度集成

3.3 List 的局限

• 截至 iOS 18，Apple 仍未开放 List 样式的完全定制能力
• 预设模板丰富但自由度受限

总结定位： List = 具备默认风格和行为的多功能容器；LazyVStack = 纯粹、灵活的布局工具。

---

四、布局与自定义

4.1 LazyVStack 的尺寸特性

• 子视图未指定高度时，采用子视图的理想尺寸（ideal size）
• 例如 Rectangle() 在 LazyVStack 中仅显示为高度 10（Shape 默认理想尺寸），而非填满空间
• 这与 ScrollView 在可滚动方向上的布局方式一致
• 提供极大自由度，能更精确地还原设计样式

4.2 List 的布局约束

• 呈现受多方面因素影响：选定风格、容器环境、运行平台
• 样式调整主要依赖 Apple 提供的专用视图修饰器
• 早期 SwiftUI 版本中，复杂布局可能难以实现

4.3 List 的动画限制

• 行高动态变化存在局限，动画效果不理想（如通过 Toggle 切换行高时会出现异常）
• 对子视图（行）的转场动画类型有所限制
• 需要特殊动画和转场效果的场景，LazyVStack 能提供更好的表现

---

五、与其他容器的协同：上下文感知

5.1 List 的上下文感知优势

SwiftUI 拥有一个尚未公开的机制——上下文感知能力。官方容器能智能感知所处环境并自动调整样式。

List 与导航容器配合的突出表现：

1. 支持侧边栏（Sidebar）等特殊显示模式
2. 导航容器对 List 绑定的数据源和行标签提供出色支持
3. 某些组件（如 NavigationLink）在 List 中呈现独特样式

5.2 上下文感知的挑战

• 默认情况下，List 只响应行视图中一个 Button 的操作（可通过调整 buttonStyle 解决）
• 早期版本中控制 NavigationLink 样式较困难

结论： 需要与系统风格一致、充分利用自动感知能力时，List 是更优选择，且跨平台代码复用率更高。

---

六、滚动控制

维度	List	LazyVStack + ScrollView
官方滚动 API	仅 ScrollViewReader	iOS 17 起大幅增强，支持丰富的新 API
变通方案	通过第三方库（如 SwiftUI-Introspect）访问底层 UIKit API	原生支持
精确滚动控制	较弱	✅ 更优
基于位置的视觉效果	较难实现	✅ 更灵活

结论： 从 iOS 17 开始，ScrollView + LazyVStack 在滚动控制方面的能力和便利性已远超 List。

---

七、性能对比

7.1 LazyVStack 的性能特征

• 维护一个完整的容器高度（子视图高度总和 + 间距）
• 采用动态估算高度的方式实现惰性加载
• 问题一： 快速滚动到特定位置时，需实例化并计算该位置之前所有子视图的高度，可能导致性能下降
• 问题二： 子视图高度差异大时，快速滚动或大幅跳转可能出现白屏现象

7.2 List 的性能特征

• 在 SwiftUI 层面不维护完整内容高度
• 快速滚动/跳转时，智能选择必要子视图进行实例化和计算
• 滚动和跳转效率显著更高

7.3 注意事项

• 在 List 中使用 id 修饰器可能导致子视图失去惰性加载能力（LazyVStack 无此问题）
• 建议让数据类型同时遵循 Identifiable 和 Hashable 协议
• 避免使用 id 修饰器作为滚动控制的定位标签

结论： 相同数据量下，List 通常比 LazyVStack 表现出更高的效率。

---

八、选择决策速查表

考虑因素	倾向 List ✅	倾向 LazyVStack ✅
需要滑动操作 / 编辑模式	✅
需要系统风格一致性	✅
与导航容器深度集成	✅
跨平台兼容性	✅
大数据集滚动/跳转性能	✅
高度自定义 UI 设计		✅
精确滚动控制（iOS 17+）		✅
复杂动画与转场效果		✅
行高动态变化		✅
最大布局灵活性		✅

---

九、总结

没有一刀切的解决方案，最佳选择取决于具体的项目需求：

1. 性能表现 — 大范围跳转和子视图高度差异大的场景需重点关注
2. 滚动控制 — 精确度和位置感知能力
3. 布局灵活性 — 复杂 UI 设计适应能力、动画兼容度
4. 预设功能 — 是否需要系统内置特性
5. 跨平台兼容 — 不同 Apple 生态中的表现
6. 组件协同 — 导航和数据绑定方面的需求

实践中可以在不同页面分别使用两者以发挥各自长处，关键是根据应用需求灵活选择。随着 SwiftUI 的持续演进，这些组件的能力和适用场景也会不断变化。