Swift学习专栏

引言：单一缓存策略的局限性 在移动应用开发中，缓存是提升性能的关键手段。然而，单一的缓存策略往往难以同时满足三个核心诉求：高性能、低内存占用和数据一致性。 内存缓存速度快但容量有限，磁盘缓存容量大但访

Swift 5.5 引入 Actors 时，苹果承诺这将终结数据竞争问题。"只需把 class 换成 actor，问题就解决了"——但事实远比这复杂。 陷阱 1：Reentrancy（重入）——Act

引言 Swift 的字符串插值功能远不止简单的值替换。虽然大多数开发者习惯使用 \() 语法将变量直接嵌入字符串，但 Swift 的字符串插值系统实际上是一个高度可定制、功能强大的机制。通过扩展 St

引言：为什么方法调度如此重要 在 Swift 开发中，你可能听过其他人给出这样的建议："把这个方法标记为 final"、"使用 private 修饰符"、"避免在扩展中重写方法"。这些建议的背后，都指

核心概念解析 什么是AutoreleasePool？ AutoreleasePool（自动释放池）是iOS内存管理中的重要机制，它本质上是一个局部上下文或容器。所有在这个容器内定义的对象，在容器退出作

引言 在 Swift 开发中，闭包是强大的功能特性，但不当使用会导致严重的内存泄漏问题。闭包捕获列表（Closure Capture List）是 Swift 提供的一种精确控制变量捕获行为的机制，是

若你只想记住一句话：“当闭包生命周期可能长于 self 时，永远不要使用 unowned。” 从一段崩溃代码说起 运行步骤： 用户进入页面 → Timer 持有闭包 → 闭包持有 unowned se

## 前言 iOS 17 引入的 `@Observable` 宏让 SwiftUI 刷新机制大变天，但官方文档只告诉你“在 View 里用就行”。 如果我们想在 非 SwiftUI 场景（比如 N

## 为什么“状态”是 SwiftUI 的牛顿第三定律？ 在物理学里，力与反作用力成对出现；在 SwiftUI 里，状态变化与UI 反应也成对出现。 用户每一次点击、每一次网络返回，都相当于给系统

为什么“并发”突然成了刚需 真实场景里： 游戏服务器：32 条网络线程并发处理玩家技能； 客户端：主线程发动画，后台线程算伤害，Timer 触发 dot； 单机多核：SceneKit 物理回调、Vis

为什么“泛型”还不够 上一篇我们写出了这样的代码： 它编译得快、跑得也快，但当你想把它存进数组、或者作为属性逃逸到运行时，就会遇到三个灵魂问题： 编译器不知道具体类型有多大，如何分配内存？ 协议里有

为什么要“再抽象一层” 上两篇我们已经用协议把“攻击”拆成了能力插件，但遗留了一个硬核问题： 游戏前期用 Int 足够，后期为了避免除法误差想换成 Double，甚至金融级精度要用 Decimal；

用 protocol + extension 把上一篇的 BOSS 战例彻底重构，让代码轻量、可测试、易扩展 为什么“不用继承” 上一篇我们用 class Entity → Monster / Bos

为什么必须有“继承” 在真实世界里，我们习惯把事物归类：车 → 自行车 → 双人自行车。 Swift 的 class 类型允许我们用同样的层级方式建模，把公共的代码放在“上层”，把差异化的代码放在“下

前言 日常开发里，我们写 for item in list 像呼吸一样自然。 但 Swift 编译器在背后悄悄做了三件事： 调用 list.makeIterator() 拿到一个迭代器 反复调用 it

为什么旧的 NotificationCenter 会“踩坑” 在 Swift Concurrency 时代，即使你把 addObserver 的 queue 设成 .main，只要闭包里调用了 @Ma

为什么 .task 默认不会“跟着变量跑” 在 UIKit 时代，我们手动 addObserver、removeObserver，一不小心就忘记移除。 SwiftUI 带来了“自动依赖追踪”：只要 b

前言 ARC 让 90% 的 iOS 开发者“无痛”管理内存，但剩下的 10% 却能把 App 拖进 OOM 深渊。 ARC 原理：一张图先记住 结构体 / 枚举是值类型，不走 ARC；只有类（cla

## 为什么需要“访问控制” 1. 隐藏实现细节，只暴露必要接口 2. 防止外部误用，减少后续兼容压力 3. 支持模块化开发（App、Framework、Swift Package 多目标混

## 前言 在 iOS 开发中，「实时刷新」需求随处可见： - 天气卡片 3 秒更新一次 - 座位状态由绿变红 - 股价、比分、配送进度…… 过去我们习惯用 `Timer.sche