12-12.【SwiftUI】State 和 Derived State 如何区分？错误区分会带来哪些一致性和性能问题？

在状态管理中，区分 State（源状态） 和 Derived State（派生状态/计算状态） 是构建健壮应用的第一步。如果把应用比作一条河流，State 就是源头的泉眼，而 Derived State 则是顺流而下的支流或人工运河。

1. 定义与核心区别

特性	State (Single Source of Truth)	Derived State (Computed)
本质	数据的唯一真理来源。是不可预测的、来自外部或用户输入的信息。	数据的投影。通过对源状态进行逻辑运算、转换或过滤得到的结果。
存储	需要持久化或存储在 `@State`、`@StateObject` 中。	不应存储。应作为计算属性（Computed Property）存在。
可变性	可以被直接修改。	只读。它随源状态的变化而自动更新。
例子	一个 `Todo` 列表数组。	已完成任务的数量、过滤后的搜索结果。

2. 错误区分的典型场景

最常见的错误是将 Derived State 当作 State 存储。这被称为“状态冗余”。

❌ 错误做法：同步存储

Swift

struct TodoListView: View {
    @State var todos: [Todo] = []
    @State var completedCount: Int = 0 // ❌ 错误：这是派生状态，不该用 @State
    
    func toggle(todo: Todo) {
        // 你必须手动维护两个状态的一致性，极其容易漏掉
        todo.isDone.toggle()
        completedCount = todos.filter { $0.isDone }.count 
    }
}

✅ 正确做法：按需计算

Swift

struct TodoListView: View {
    @State var todos: [Todo] = []
    
    // ✅ 正确：它是 todos 的影子，永远保持同步
    var completedCount: Int {
        todos.filter { $0.isDone }.count
    }
}

3. 错误区分带来的严重后果

A. 一致性问题：状态漂移 (State Drift)

这是最致命的问题。当你手动维护两个相关联的状态时，逻辑漏洞会导致它们不再同步。

现象：界面显示“已完成 3 个任务”，但列表里其实只有 2 个勾选。
后果：产生难以复现的“幽灵 Bug”，用户对 App 失去信任。

B. 性能问题：过度渲染与内存浪费

过度重绘：在 SwiftUI 中，如果你把派生结果存入 @State，每次手动更新该值都会触发一次额外的 body 计算。
内存碎片：对于大型集合，存储多份重复或转换后的数据会增加内存压力，尤其是在处理高频更新（如滚动位置计算）时。

C. 复杂度爆炸

如果你有 $N$ 个源状态和 $M$ 个依赖它们的派生状态，手动同步需要处理 $N \times M$ 种逻辑路径；而使用计算属性，你只需要处理 $N$ 个源状态。

4. 进阶策略：何时可以“缓存”派生状态？

虽然原则上不建议存储派生状态，但在以下特殊情况下，你可以进行局部优化：

计算极其昂贵：例如对数万条数据进行复杂的正则匹配。
- 解法：使用 memoization（缓存）技术。在 Swift 中可以利用 combine 的 .removeDuplicates() 或者手动实现“脏标记（Dirty Check）”机制。
跨组件共享：如果多个不相关的视图需要同一个昂贵的派生结果。
- 解法：在 ViewModel 中使用 Publisher 处理派生逻辑，仅当结果变化时才发出信号。

总结：防御式检查清单

在定义一个新的 @State 之前，先问自己三个问题：

它能通过现有的状态计算出来吗？ 如果能，它就是派生状态。
如果我改了 A，是不是必须记得手动去改 B？ 如果是，B 极大概率应该是派生的。
它的变化是否总是滞后于某个源状态？ 派生状态应当是瞬时的。

12-12. 【SwiftUI】How to Distinguish Between State and Derived State? What Consistency and Performance Issues Arise from Misclassification?

In state management, distinguishing between State (Source of Truth) and Derived State (Computed State) is the first step toward building a robust application. If you think of an app as a river, State is the spring at the source, while Derived State represents the streams or man-made canals flowing downstream.

1. Definition and Core Differences

Feature	State (Single Source of Truth)	Derived State (Computed)
Essence	The unique source of truth for data. Unpredictable information coming from external sources or user input.	A projection of data. Results obtained through logical operations, transformations, or filtering of the source state.
Storage	Needs to be persisted or stored in `@State`, `@StateObject`, etc.	Should not be stored. It should exist as a computed property.
Mutability	Can be modified directly.	Read-only. It updates automatically as the source state changes.
Example	An array of `Todo` items.	The count of completed tasks; filtered search results.

2. Typical Misclassification Scenarios

The most common mistake is storing Derived State as State. This is known as "State Redundancy."

❌ Incorrect Practice: Synchronized Storage

Swift

struct TodoListView: View {
    @State var todos: [Todo] = []
    @State var completedCount: Int = 0 // ❌ Error: This is derived state and should not use @State
    
    func toggle(todo: Todo) {
        // You must manually maintain consistency between two states, which is extremely easy to miss
        todo.isDone.toggle()
        completedCount = todos.filter { $0.isDone }.count 
    }
}

✅ Correct Practice: Calculation on Demand

Swift

struct TodoListView: View {
    @State var todos: [Todo] = []
    
    // ✅ Correct: It is a "shadow" of todos, always staying in sync
    var completedCount: Int {
        todos.filter { $0.isDone }.count
    }
}

3. Serious Consequences of Misclassification

A. Consistency Issues: State Drift

This is the most critical problem. When you manually maintain two related states, logical loopholes will eventually cause them to fall out of sync.

Symptom: The UI shows "3 tasks completed," but there are actually only 2 checkmarks in the list.
Consequence: It creates "ghost bugs" that are hard to reproduce, leading to a loss of user trust.

B. Performance Issues: Over-rendering and Memory Waste

Excessive Redraws: In SwiftUI, if you store a derived result in @State, every manual update to that value triggers an additional body recalculation.
Memory Fragmentation: For large collections, storing multiple copies of redundant or transformed data increases memory pressure, especially when handling high-frequency updates (like scroll position calculations).

C. Complexity Explosion

If you have $N$ source states and $M$ derived states depending on them, manual synchronization requires handling $N \times M$ logical paths. By using computed properties, you only need to manage the $N$ source states.

4. Advanced Strategy: When Can You "Cache" Derived State?

While storing derived state is generally discouraged, you can apply local optimizations in the following special cases:

Extremely Expensive Calculations: For example, performing complex regex matching on tens of thousands of data points.
- Solution: Use memoization techniques. In Swift, you can utilize Combine's .removeDuplicates() or manually implement a "Dirty Check" mechanism.
Cross-Component Sharing: When multiple unrelated views require the same expensive derived result.
- Solution: Use a Publisher in a ViewModel to handle derivation logic, emitting a signal only when the result actually changes.

Summary: Defensive Checklist

Before defining a new @State, ask yourself three questions:

Can it be calculated from existing state? If yes, it is derived state.
If I change A, must I remember to manually change B? If yes, B is highly likely to be a derived state.
Does its change always lag behind a source state? Derived state should be instantaneous.