12-2.【SwiftUI】body 为什么必须是纯函数？如果 body 里有副作用会发生什么？在 SwiftUI 中，

在 SwiftUI 中，body 属性必须是纯函数（Pure Function），这是由其声明式架构的本质决定的。简单来说，纯函数意味着：相同的输入（State/Props）永远产生相同的输出（View Description），且不产生任何副作用。

如果把 body 比作一份菜单，SwiftUI 的引擎就是厨师。如果菜单在阅读过程中突然自己改了内容，厨师就会陷入混乱。

1. 为什么必须是纯函数？

高频且不可控的调用 (Idempotency)

SwiftUI 的渲染引擎非常精明，它会为了优化性能而**随时、多次、甚至在多线程（后台预处理）**中调用 body。

它可能为了计算布局调用一次。
可能为了对比差异（Diffing）调用一次。
可能为了准备转场动画调用一次。

如果你在 body 里写了逻辑，你无法预知它会被执行 1 次还是 100 次。

依赖追踪机制 (The Dependency Graph)

SwiftUI 通过执行 body 来构建“属性图”（Attribute Graph）。如果 body 不是纯函数，渲染引擎就无法确切知道：到底是哪个状态导致了 UI 的变化？ 这会破坏 SwiftUI 的自动更新逻辑。

2. 如果在 body 里写副作用会发生什么？

现象一：死循环（The Infinite Loop of Doom）

这是最常见的错误。如果你在 body 里修改了驱动 UI 的状态（如 @State），会触发以下连锁反应：

状态改变，SwiftUI 调用 body。
执行 body 时，你修改了状态。
状态再次改变，SwiftUI 认为需要重新调用 body。
结果：你的 CPU 飙升到 100%，App 卡死或直接崩溃。

Swift

var body: some View {
    // ❌ 错误：在 body 中修改状态
    self.count += 1 
    return Text("(count)")
}

现象二：UI 极度卡顿（Jank）

如果在 body 里进行耗时操作（如网络请求、复杂的 DateFormatter 格式化、磁盘读取）：

结果：因为 body 是在主线程执行的，且调用频率极高，这会直接阻塞 UI 渲染，导致掉帧和动画撕裂。

现象三：状态不一致与难以调试的 Bug

如果你的 body 依赖于外部的全局变量（非状态变量），由于 SwiftUI 可能会缓存 body 的结果，UI 可能不会更新，或者在不同设备上表现不一，产生极其隐蔽的“幽灵 Bug”。

3. 如何优雅地处理副作用？

SwiftUI 提供了一套专门的生命周期钩子（Hooks） ，用于将副作用移出“渲染纯区”：

需求场景	推荐方案	说明
视图出现时加载数据	`.onAppear { ... }`	仅在视图进入屏幕时触发一次。
异步任务/请求	`.task { ... }`	Swift 6 推荐，支持异步且在视图消失时自动取消。
监听状态变化	`.onChange(of: value) { ... }`	状态改变时才触发逻辑，而非重绘时触发。
计算属性优化	`let` 预处理	在构造函数或 ViewModel 中处理好数据，body 仅负责读取。

4. 防御式编程建议： body 的“三不”原则

不发起请求：绝对不要在 body 里写 URLSession。
不修改状态：绝对不要给 @State 赋值。
不创建复杂对象：复杂的格式化工具（如 NumberFormatter）应当通过 static 变量或 ViewModel 复用，而不是在 body 里反复 init。

12-2. [SwiftUI] Why must `body` be a Pure Function? What happens if it has Side Effects?

In SwiftUI, the body property must be a pure function. This is dictated by the very nature of its declarative architecture. A pure function means: The same input (State/Props) always produces the same output (View Description), and it produces no side effects.

If you imagine the body as a menu, the SwiftUI rendering engine is the chef. If the menu suddenly changes its own content while the chef is reading it, the kitchen falls into chaos.

1. Why must it be a Pure Function?

High-Frequency and Unpredictable Execution (Idempotency)

SwiftUI's rendering engine is highly optimized. It may call body at any time, multiple times, and potentially on background threads for pre-processing.

It might call body once to calculate layout.
It might call it again to perform a Diff (difference comparison).
It might call it a third time to prepare a transition animation.

If you include logic inside body, you cannot predict whether it will execute once or a hundred times.

The Dependency Graph

SwiftUI builds an Attribute Graph by executing body. If body is not pure, the engine cannot determine with certainty which specific state change caused the UI update. This breaks SwiftUI's automatic data-driven logic.

2. What happens if you include Side Effects in `body`?

Scenario 1: The Infinite Loop of Doom

This is the most common error. If you modify a state that drives the UI (like @State) inside the body, it triggers a catastrophic chain reaction:

State changes -> SwiftUI calls body.
While executing body, you modify the state.
State changes again -> SwiftUI decides it needs to call body again.
Result: Your CPU spikes to 100%, and the App freezes or crashes.

Swift

var body: some View {
    // ❌ ERROR: Modifying state inside body
    self.count += 1 
    return Text("(count)")
}

Scenario 2: Extreme UI Lag (Jank)

If you perform time-consuming operations inside body (such as network requests, complex DateFormatter logic, or disk I/O):

Result: Since body executes on the main thread and is called frequently, these operations block UI rendering, leading to dropped frames and stuttering animations.

Scenario 3: Inconsistent State and Ghost Bugs

If your body depends on external global variables (that are not wrapped in SwiftUI state containers), the UI might fail to update because SwiftUI may have cached the body result. This creates "Ghost Bugs" that are incredibly difficult to debug.

3. How to Elegantly Handle Side Effects

SwiftUI provides specific Lifecycle Hooks to move side effects out of the "pure rendering zone":

Scenario	Recommended Solution	Description
Load data when view appears	`.onAppear { ... }`	Triggered exactly once when the view enters the screen.
Asynchronous tasks/requests	`.task { ... }`	Recommended for Swift 6; supports async and auto-cancels on disappear.
Observe state changes	`.onChange(of: value) { ... }`	Triggers logic only when a specific value changes, not every redraw.
Pre-process calculations	`ViewModel` or `let`	Process data in the constructor or ViewModel; `body` only reads the result.

4. Pro-Developer Tip: The "Three Nos" for `body`

No Network Requests: Never put URLSession or API calls directly in body.
No State Assignments: Never assign values to @State variables within body.
No Complex Initializations: Heavy objects like NumberFormatter should be reused via static variables or handled in the ViewModel, rather than being re-initialized inside body.

12-2.【SwiftUI】body 为什么必须是纯函数？如果 body 里有副作用会发生什么？