Swift

一、先给结论版（重要） 但在绝大多数常见场景下： 类型 本体通常在哪里 变量里存的是什么 struct 栈 / 内嵌在宿主对象中 实际数据 enum 栈 / 内嵌 实际数据（含 tag） class

一、内存布局上的差异 1️⃣ 值类型（Value Type） 典型代表：struct、enum、tuple、基本类型（Int、Double） 📦 内存存储方式 直接存储数据本身 通常分配在： 栈（St

一、概念：延迟决策（Delay Decision） 目标：避免早期猜测导致架构僵化 核心原则：面向抽象、保持可替换性 本质是“先定义接口 / 协议 /抽象，后选择实现”，而不是一开始就固定实现方案 二

一、设计原则 最小接口原则（Interface Segregation） 提供尽量精简、单一职责的 API 不暴露内部实现细节 依赖方只看到它需要的功能 稳定性优先 依赖方越多，API 越难改动 尽量

一、问题本质 反向依赖会导致： 模块耦合：UI 改动 → 逻辑层也必须改 测试困难：无法在不加载 UI 的情况下测试业务逻辑 可替换性差：逻辑层无法被不同 UI 重用 二、常见反向依赖形式 直接引用

一、构造注入（Constructor / Init Injection） ✅ 优点 依赖明确：实例一创建就完整 不可变性：依赖不能被随意修改 → 模块边界清晰 易测试：可以直接传入 Mock ⚠️ 滥

一、问题根源：Swift 的派发机制 协议方法的派发规则 Protocol requirement（协议声明的方法）： 如果被类实现 → 动态派发（类似虚方法） 如果通过协议类型调用 → 动态派发 P

一、模块边界的本质 特点： 隐藏实现 模块内部细节不暴露 外部只能依赖公开接口 单向依赖 外部可以依赖模块，但模块不依赖外部（或最少依赖） 可替换 / 可测试 可以 mock / stub 模块接口

一、本质对比：async/await vs 响应式流 特性 async/await 响应式流 (Combine/Rx) 时间模型 单值异步操作，顺序完成 多值随时间流动，可组合、可取消 核心问题 “如

一、本质：Cancel 的角色 在响应式系统中（Combine / Rx / TCA / Redux Observable）： 核心理念： 时间流不等于事件流完成 Cancel = “我不再关心这个流

一、本质：AnyPublisher 是什么 AnyPublisher<Output, Failure> 本质上是 类型擦除 (Type Erasure) 的 Publisher： Combine 中大

一、原则：副作用放的位置 1️⃣ 核心原则 换句话说： Reducer = 纯函数，不执行网络 / DB / UI Effect / SideEffect = 可组合、可取消、可追踪的副作用 2️⃣

一、本质区别 假设有一个 Publisher（Combine / Rx）： 你想根据它生成 B 类型的数据流，可以用 map / flatMap / switchLatest，但它们的处理方式本质不同

一、核心结论（工程直觉） 换句话说，它解决的不是“异步”，而是状态随时间变化的传播和组合问题。 二、传统问题 在传统命令式或回调式代码中，我们经常遇到： 状态依赖难管理 a 改了 b 也要改 b 改了

一、目标拆解 你希望 State 具备： UI 可预测 每次 State 改变 → UI 渲染可预期 没有隐藏副作用，避免“偶发性闪烁/错误” 易调试 可以追踪“谁改了 State、什么时候改的、为什

一、结论先行 换句话说：大 State 偶尔改没问题，小 State 高频改也能炸。 二、渲染角度（Render） 1️⃣ SwiftUI 的渲染机制 State 改变 → SwiftUI 标记依赖该

一、问题本质 在并发场景下，State 的核心问题是： 例如 SwiftUI / TCA 中： 如果没有约束： 最终状态可能不是任何一个动作的正确结果 UI 会显示“半更新”或“回退” Bug 随机出

这是一个所有“状态驱动 UI”体系的核心问题。 如果把它搞清楚，SwiftUI / TCA / Redux / Jetpack Compose 的 80% 性能与一致性问题都会自动消失。 什么是 St

“全局 State 是不是反模式”本身就是一个误导性命题——真正的问题不是 全不全局，而是： 一句话结论（先给判断） 一、为什么“全局 State”会被骂成反模式？ 因为历史上它常常长这样👇 灾难不是

一句话定义（不是教科书版） 换句话说： 没有： View 直接改 State A 改 B，B 又反改 A “我也不知道是谁动了它” 一、单向数据流出现之前，世界有多糟？ 典型的“双向地狱”（UIKit