SwiftUI中Picker在EquatableView内绑定@Published属性异常问题

核心结论 #

这是SwiftUI视图更新机制与Equatable协议结合时的边界行为陷阱，并非常规代码错误，但属于框架设计中容易踩坑的点，不算严格意义上的bug。

具体原因分析 #

1. Equatable的判断逻辑冲突
   当视图遵循Equatable时，SwiftUI会通过对比新旧视图实例的==实现，决定是否跳过视图更新。如果你的CustomPicker的Equatable实现未包含绑定的选中状态值，仅对比了样式、选项列表这类无关属性，那么当@Published属性变化时，系统会判定新旧CustomPicker实例“相等”，从而跳过更新——导致Picker的UI无法同步新的选中值。
   而绑定@State时，@State的变化会强制触发所在视图的全量重绘，即使子视图遵循Equatable也会被重新计算，因此能正常工作。

2. PickerStyle的内部机制差异
   segmented/inline样式的Picker属于即时渲染的内联控件，状态变化会直接触发自身UI更新，不受父视图的Equatable判断影响；而默认的menu/popover样式是弹出式控件，依赖父视图的状态同步来更新弹出内容和选中状态，一旦父视图被判定无需更新，就会出现状态不同步的问题。

3. TabView的特殊处理逻辑
   TabView内部会对每个标签页的视图进行独立的状态管理和强制刷新，即使子视图遵循Equatable，TabView在状态变化时也会强制重新计算子视图，绕过了Equatable的判断逻辑，因此CustomPicker能正常工作。

解决方案 #

方案1：修正Equatable实现

确保Equatable的对比逻辑包含所有影响Picker状态的属性，尤其是绑定的选中值：

struct CustomPicker: View, Equatable {
    let options: [String]
    @Binding var selection: String
    
    static func == (lhs: CustomPicker, rhs: CustomPicker) -> Bool {
        // 必须包含selection的对比，确保状态变化时视图会更新
        lhs.options == rhs.options && lhs.selection == rhs.selection
    }
    
    var body: some View {
        Picker("选择", selection: $selection) {
            ForEach(options, id: \.self) {
                Text($0)
            }
        }
    }
}

方案2：使用.equatable()修饰符精准控制更新

如果不需要让整个视图遵循Equatable，可以通过修饰符指定仅在特定属性变化时更新：

struct CustomPicker: View {
    let options: [String]
    @Binding var selection: String
    
    var body: some View {
        Picker("选择", selection: $selection) {
            ForEach(options, id: \.self) {
                Text($0)
            }
        }
    }
}

// 使用时指定需要对比的属性
CustomPicker(options: ["A", "B"], selection: $vm.selected)
    .equatable(by: \.options, \.selection)

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