Swift学习专栏

为什么“并发”突然成了刚需 真实场景里： 游戏服务器：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

## Actor 是什么？（一句话版） Actor = 自带大门的房间：一次只能进一个人，进门要“等钥匙”（`await`）。 它存在的唯一理由：保护非 Sendable 的可变状态。 ## A

## 为什么要谈“死锁” 在 Swift 并发编程中，`DispatchQueue.sync` 以“阻塞式同步”著称：简单、直观、线程安全，却也最容易让生产环境直接崩溃。 ## 什么是死锁（Dea

## 为什么要有“协议扩展” 1. 协议只能“声明”要求，不能“实现”要求 在 Swift 2 之前，协议类似 Java 的 Interface： - 只能写方法签名，不能写大

## 为什么 Swift 5.7 再次“颠覆”协议 在 Swift 5.7 之前，带关联类型的协议只能当约束 `<T: Sequence>`，不能当类型 `Sequence`。 这导致两个老大难：

## 为什么“关联类型”是协议的分水岭 在上面，我们接触的协议都属于“无关联类型协议”——编译期无需知道协议里的泛型占位符具体是什么。 一旦协议里出现了 `associatedtype`，它就不再

## 基础语法：一份“合同”长什么样 ```swift // 1. 定义协议：只声明，不实现 protocol FullyNamed { // 只要可读，不要求可写 var full

## 现象：看起来“随机”的结果顺序 在 Swift 并发模型里，`withTaskGroup` 让我们可以一次性启动多个子任务并发执行。 很多初学者第一次写出的代码类似下面这样 ```swi

省流版（先给结论） 场景 建议 App 目标（Xcode 26 新建） 保持默认 MainActor.self —— UI 代码省心、并发自己显式开 纯网络/计算 SPM 包 别开 —— 默认无隔离，

什么是 Extension 定义 extension 是 Swift 提供的一种纵向扩展机制：“不修改原始代码、不创建子类”的前提下，给任意类型（class / struct / enum / pro