@ViewBuilder在属性、初始化器中的三种实现差异及选型依据

下面三种实现自定义View的方式都能借助@ViewBuilder支持多视图组合语法，它们的核心差异在于存储内容、初始化逻辑和响应性，适用场景各有不同：

1. 在属性上添加@ViewBuilder #

struct SomeView<Content:View>: View {
    @ViewBuilder var content: () -> Content
}

差异点 #

这是Swift 5.4之后推出的语法糖，编译器会自动生成带@ViewBuilder修饰的初始化器，无需手动编写init方法。属性本身被@ViewBuilder标记，存储的是经过ViewBuilder处理的闭包，调用时天然支持if/else、switch等多视图分支语法。

适用场景 #

绝大多数常规自定义View场景，尤其是不需要额外初始化逻辑的时候。写法最简洁，能满足90%以上的需求，比如自定义容器视图（类似VStack/HStack的简化版）。

2. 在初始化器中使用@ViewBuilder并存储闭包 #

struct SomeView2<Content:View>: View {
    var content: () -> Content
    
    init(@ViewBuilder content: @escaping () -> Content) {
        self.content = content
    }
}

差异点 #

手动编写初始化器，仅在初始化参数上标记@ViewBuilder，存储的是普通的逃逸闭包。和第一种方式相比，你能完全掌控初始化逻辑——比如可以在init里对传入的闭包做包装、添加日志，或者结合其他初始化参数做判断。

适用场景 #

需要自定义初始化逻辑的场景：比如要给传入的content闭包套一层通用修饰（比如统一加圆角、阴影），或者自定义View需要接收多个参数，需要在init里做参数校验、组合逻辑的时候。

3. 在初始化器中使用@ViewBuilder并存储结果值 #

struct SomeView3<Content:View>: View {
    var content: Content
    
    init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }
}

差异点 #

存储的是View实例而非闭包，初始化时就会执行闭包生成最终View。这意味着content是固定的，不会随外部状态变化而更新——除非整个SomeView3被重新创建。而前两种存储闭包的方式，每次视图刷新都会重新执行闭包生成新的View，能响应外部状态变化。

适用场景 #

当传入的content是静态内容、不需要依赖外部状态的时候。比如封装固定的页面头部、静态提示框，这种场景下提前生成View实例可以避免重复执行闭包，提升性能。

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