从命令式界面转向状态驱动
学习 SwiftUI 时，最先需要转变的是“界面如何变化”的思路。过去写界面时，我常会主动找到某个控件，然后修改它的文字、颜色或隐藏状态。SwiftUI 的写法更像是在描述一种映射关系：当前状态是什么，界面就应该长成什么样。
这种思路刚开始有些绕，但一旦接受之后，很多问题反而变简单了。按钮点击时不必手动刷新某个视图，只需要改变状态；状态改变以后，视图会重新计算并呈现新的结果。
@State 与 @Binding
@State 适合放在视图内部，保存一些只属于当前视图的小型状态，例如是否展开、输入框内容、当前选中的标签等。它的重点是“归属清晰”，不要把所有数据都塞进一个视图里。
当子视图需要修改父视图中的状态时，@Binding 就很自然。它并不拥有数据，而是拿到一个可读可写的引用。这样父视图仍然是状态来源，子视图只负责在合适的时机表达修改意图。
状态归属比语法更重要
我现在会先问几个问题：这个状态是谁创建的？谁需要读取它？谁有权修改它？它是否应该跨页面存在？这些问题比具体用哪个属性包装器更重要。
- 只影响当前视图的小状态，优先考虑
@State。 - 父子视图之间传递可修改状态，可以使用
@Binding。 - 多个视图共享的复杂数据，应该进一步考虑可观察对象或统一的数据模型。
一点小结
SwiftUI 的状态系统让我意识到，界面代码并不是把控件一步步摆出来那么简单。更好的方式是先整理数据关系，再让视图成为状态的自然表达。这样写出来的代码通常更短，也更容易在以后维护。