Swift值类型语义、Binding的影响及SwiftUI文档示例实现疑问

关于结构体Binding是否绕过值类型语义 #

答案是否定的，该方案并没有破坏值类型的核心语义。Binding本质是一个封装了读写访问逻辑的中间人类型，它本身不持有值，只存储了对应值的读取、写入闭包：

• 你通过Binding读取结构体值的时候，拿到的仍然是原值的独立拷贝
• 修改后赋值给Binding时，底层是将你修改后的完整副本写回原存储位置
  整个过程依然遵循「值修改必然产生副本」的规则，只是SwiftUI帮你封装了手动读写源状态的重复逻辑，不存在绕过值语义的情况。

无发布者时SwiftUI如何感知结构体更新 #

所有SwiftUI的状态相关属性（@State/@Binding/@StateObject等）底层都由SwiftUI运行时统一托管：
当你通过Binding修改结构体值时，会自动触发对应状态源的变更标记，SwiftUI会自动扫描所有依赖该状态的视图，将其标记为需要重新渲染，在下一个渲染周期用更新后的状态值重建视图树，不需要开发者手动添加发布者来通知变更。

struct+Binding方案相比ObservableObject类方案的核心优势 #

• 天然线程安全：值类型的修改都是独立副本操作，不存在多线程读写竞态问题，不需要额外加锁维护线程安全；而ObservableObject类的属性如果在非主线程修改，不仅会触发运行时警告，还很容易出现数据不同步的问题。
• 适配文档类应用的存储逻辑：基于ReferenceFileDocument的文档应用需要检测数据变更触发自动保存，值类型的全量替换特性可以让文档系统自动识别变更，不需要开发者手动监听属性变更调用markAsNeedsSave()，反而减少了冗余代码。
• 状态边界清晰可追溯：Binding的传递链路是明确的，你可以很容易追溯到状态的源头，不会出现类实例被多场景隐式持有、随意修改导致的莫名bug，排查问题的成本低很多。
• 无生命周期管理负担：结构体不需要考虑实例持有、循环引用、释放时机等问题，而ObservableObject类需要开发者手动维护生命周期，很容易出现内存泄漏或者实例提前释放的问题。
• 更贴合SwiftUI的声明式设计范式：SwiftUI本身就是围绕值类型的状态驱动设计的，值类型的变更是单向可预测的，不会出现类实例修改后多视图无预期更新的问题，代码的可维护性更高。

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