SwiftUI容器视图依赖合成成员逐一初始化器是否存在弊端？

闭包执行时机的核心差异 #

• 自定义初始化器实现：视图初始化阶段就执行传入的闭包，将生成的View实例存储为属性，后续body直接返回该存储的实例，闭包仅执行一次。
• 合成成员逐一初始化器：容器的body会在每次SwiftUI需要计算视图内容时调用闭包，重新生成View实例。

性能担忧的实际情况 #

首先要明确：SwiftUI的body频繁调用，并不等同于一定会带来显著性能损耗，因为框架有一套成熟的视图差异对比（diffing）机制：

• 即使闭包多次执行生成新的View值类型实例，SwiftUI会对比新旧视图的结构、状态和标识，只有真正发生变化的部分才会触发底层UI渲染更新。
• 对于无状态的简单视图（比如Text、VStack组合），重复生成实例的开销微乎其微，几乎可以忽略。
• 但如果闭包内部包含昂贵计算（如复杂数据解析、大图解码）或状态密集型视图创建，多次执行闭包确实会产生额外性能开销，这种场景下自定义初始化器存储结果的方式更合适。

需要警惕的实际问题场景 #

• 闭包存在副作用：如果闭包里包含网络请求、文件读写、计数器递增这类有副作用的逻辑，body的多次调用会导致副作用重复触发，引发逻辑错误或资源浪费，此时必须用自定义初始化器固定闭包执行时机。
• 依赖静态不变数据：如果闭包生成视图依赖的外部数据是静态的（比如编译期常量、初始化后不再变化的配置），合成初始化器会重复执行无意义的计算，这时候自定义初始化器能避免冗余操作。

利弊总结 #

合成成员初始化器的优势 #

• 代码更简洁，无需手动编写初始化方法和存储属性，可读性更强。
• 贴合SwiftUI声明式编程的设计思路，直接在初始化环节描述视图结构。

潜在弊端 #

• 闭包逻辑会随body的每次调用重复执行，若包含高开销操作或副作用，会引发性能问题或逻辑异常。
• 无法自主控制闭包的执行时机，完全依赖SwiftUI的视图更新调度。

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