Struct vs Class：你以為你在選型，其實你在設計「狀態」
大多數 iOS 工程師在面試被問到：
Struct 和 Class 有什麼差別？
通常會回答：
- Struct 是 value type
- Class 是 reference type
- Struct 會 copy，Class 不會
然後結束。
但問題是 — — 這種答案幾乎沒有解釋任何「設計層級的意義」。
在真實的 iOS 專案裡，這題真正考的不是語法，而是：
你如何設計「狀態（state）」與「資料流（data flow）」
1. Struct vs Class 從來不是語法問題
Struct（Value Type）
struct User {
var name: String
}
var user1 = User(name: "Wayne")
var user2 = user1user2.name = "Kevin"
結果：
user1.name = "Wayne"
user2.name = "Kevin"
👉 各自獨立
Class（Reference Type）
class User {
var name: String
init(name: String) {
self.name = name }}var user1 = User(name: "Wayne")
var user2 = user1user2.name = "Kevin"
結果：
user1.name = "Kevin"
user2.name = "Kevin"
👉 共享同一個 instance
到這裡，大多數人就停了。
但真正的問題才剛開始。
2. 真正的核心差異：你是否「共享狀態」
這兩種設計，本質上在回答一個問題：
這份資料，應不應該被共享？
Struct 的世界觀：資料是「獨立的」
Struct 假設的是：
- 每一份資料都是獨立的
- 修改不應該影響其他人
- 行為應該是可預測的
👉 它追求的是：
deterministic state（可預測狀態）Class 的世界觀：物件是「共享的」
Class 假設的是：
- 這個 instance 是唯一的
- 多個地方可以引用它
- 改動是「同步發生」的
👉 它追求的是：
shared identity（共享身份）3. 真正讓系統失控的，是「共享可變狀態」
看這段：
class Cart {
var items: [String] = []
}
let cartA = Cart()
let cartB = cartAcartB.items.append("iPhone")
問題不是 syntax，而是：
你已經失去「誰改了 state」的控制權
在小專案這不是問題，但在大型專案會變成：
- ViewModel 改 state
- Service 改 state
- Cache 改 state
- Singleton 改 state
最後你會開始問：
到底是誰改壞我的資料？
這不是 bug。
這是設計問題。
4. 為什麼 Swift 反而鼓勵 Struct？
Swift 的核心設計哲學是：
Make state predictable.
也就是：
讓狀態變得可推理Struct 帶來三個關鍵優勢：
① 可預測性（Predictability）
資料不會被隱性修改
② 可測試性（Testability）
input → output 清楚
③ 可推理性（Reasoning）
不用追蹤 reference chain
這也是為什麼 SwiftUI 幾乎全是 struct。
因為 SwiftUI 本質是：
UI = function(state)
5. 那 Class 什麼時候才是正確選擇？
不是「不要用 Class」，而是：
只有在你需要 identity 的時候才用 Class
✔ Shared Resource
final class NetworkManager {
static let shared = NetworkManager()
}
✔ Lifecycle Object
例如：
- URLSession
- AVPlayer
- UIViewController
✔ Observable Object（SwiftUI）
class ViewModel: ObservableObject {
@Published var name = ""
}
👉 重點不是「可不可以共享」，而是：
你需不需要共享同一個 identity6. SwiftUI / TCA 為什麼幾乎全部用 Struct？
因為它們解決的是同一個問題：
如何讓 state flow 可追蹤
Struct 帶來的是：
- 沒有 hidden mutation
- state change 是顯式的
- diff 可以被計算
- UI 可以被重建
TCA 本質上是在強制你接受：
state 必須是可預測的 flow，而不是自由變動的物件
7. 這題真正想測的能力是什麼？
面試官其實不是在問：
你知不知道 value vs reference
而是在問：
你能不能設計一個「不會失控的狀態系統」
更深一層其實是：
- 你會不會避免 shared mutable state
- 你知不知道 side effect 從哪裡來
- 你能不能預測資料流
- 你能不能 debug state corruption
結論
Struct vs Class 不是選擇題。
它其實是一個設計問題：
你要選擇「自由共享」還是「可預測性」
Swift 的答案很清楚：
預設選擇可預測性，除非你真的需要 identity。
延伸思考
當你開始進入 SwiftUI、TCA、Concurrency，你會發現：
Swift 的演進方向不是 OOP 的進化版，而是：
State-driven programming
而 Struct vs Class，只是入口而已。
