SwiftUI中Binding<Date?>转Binding<Date>扩展崩溃：赋值后仍为nil？

你的代码崩溃的核心原因可以从这几个角度拆解：

1. Binding的本质：它只是数据源的"代理"，而非存储容器 #

Binding本身不存储值，它的wrappedValue是计算属性，get/set操作都是直接委托给底层数据源（比如@State、@Published变量，或是自定义的Binding闭包）。

当你执行self.wrappedValue = .now时，只是调用了Binding的set闭包把值传递给底层数据源，但如果底层数据源的set逻辑没有真正保留这个值——比如：

• 数据源是Binding.constant(nil)：constant类型的Binding是只读的，set操作完全无效，值始终是nil
• 数据源的属性有自定义setter：比如某个ObservableObject的date属性在set时做了额外处理，又把值重置为nil
• 多线程竞争：其他线程在你赋值后立刻修改了数据源的值

这时候你紧接着访问self.wrappedValue!，拿到的依然是nil，自然会触发崩溃。

2. SwiftUI视图更新机制的干扰 #

在Binding的get闭包里修改值，会触发SwiftUI的视图无效化（视图需要重新渲染）。这个过程可能会打断当前的get闭包执行，或是在视图更新时重新调用get闭包。如果此时数据源的状态还没完成更新，就可能出现值再次变为nil的情况。

修复方案 #

要避免崩溃，你应该先把值取出来处理，不依赖修改wrappedValue后的即时读取：

public extension Binding where Value == Date? {
    var adapter: Binding<Date> {
        Binding<Date>(
            get: {
                let currentValue = self.wrappedValue
                guard let date = currentValue else {
                    let defaultDate = Date()
                    self.wrappedValue = defaultDate
                    return defaultDate
                }
                return date
            },
            set: { self.wrappedValue = $0 }
        )
    }
}

这样即使数据源的set操作没生效，你也直接返回了本地创建的defaultDate，不会触发强制解包崩溃。

另外，如果你确定底层数据源不应该出现nil，最好从源头保证数据源的非可选性——毕竟这种Binding层的适配只是临时补丁，无法解决数据源本身的问题。

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