SwiftUI中@Observable类为何需用@Bindable而非@Binding？

在SwiftUI中，@Bindable用于创建对@Observable类实例可变属性的绑定，确保父子视图间的状态同步；而用@Binding配合$符号传递Observable实例，也能实现属性修改时的视图同步效果。那Apple为何要单独推出@Bindable？两者的核心工作差异到底是什么？

使用@Bindable的实现方式 #

@Observable
class People {
    var name = "No name"
}

struct ChildView: View {
    @Bindable var person: People

    var body: some View {
        VStack {
            TextField("...", text: $person.name)
        }
    }
}

struct ParentView: View {
    @State private var person = People()

    var body: some View {
        VStack {
            TextField("...", text: $person.name)
            // 传递实例本身，无需$符号
            ChildView(person: person)
        }
    }
}

使用@Binding的实现方式 #

@Observable
class People {
    var name = "No name"
}

struct ChildView: View {
    @Binding var person: People

    var body: some View {
        VStack {
            TextField("...", text: $person.name)
        }
    }
}

struct ParentView: View {
    @State private var person = People()

    var body: some View {
        VStack {
            TextField("...", text: $person.name)
            // 传递绑定的引用，需要$符号
            ChildView(person: $person)
        }
    }
}

核心差异与设计原因 #

1. 语义与API体系的一致性 #

@Bindable是专门为@Observable类打造的属性包装器，语义上直接表明：这个Observable实例的属性可被双向绑定修改，完美融入Observable的响应式体系。而@Binding原本是为值类型（如@State包装的结构体）设计的双向绑定工具，用于Observable类属于“兼容使用”，并非原生适配，语义上不够精准。

2. 对实例操作的限制不同 #

• 使用@Binding时，绑定的是整个Observable实例的引用：如果在ChildView中直接替换实例（比如person = People(name: "New Name")），会直接修改ParentView中@State保存的引用，这在很多场景下属于误操作。
• 使用@Bindable时，仅能绑定实例内部的属性，无法直接替换整个实例，更贴合大多数业务场景中“修改属性而非替换实例”的需求，减少意外的状态变更。

3. 底层响应机制的适配性 #

@Observable类的响应式依赖编译器自动生成的属性级变更通知，@Bindable在底层直接对接这套通知系统，属性修改时能精准触发相关视图更新；而@Binding用于引用类型时，依赖外部State/ObservableObject的顶层变更通知，在复杂嵌套场景下可能出现更新不精准的问题。

4. API的未来扩展性 #

@Bindable作为Observable体系的核心组件，Apple可以针对它添加更多专属特性（比如和后续新的响应式API联动）；而@Binding作为通用绑定工具，不会专门为Observable类做特殊优化，扩展性受限。

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