Swift面试必备：深入解析高频技术点与实战应用

1. 值类型与引用类型：Swift设计的基石与面试必问

面试官问你“Struct和Class有什么区别”，如果你只回答“一个值类型一个引用类型”，那大概率只能拿个及格分。这个问题就像问你“汽车和自行车有什么区别”，你得从设计哲学、内存模型、使用场景，甚至编译器优化层面去拆解，才能让面试官眼前一亮。

我刚开始用Swift那会儿，也踩过不少坑。有一次，我写了个数据模型，里面有个数组属性。我把它定义成了Class，然后在多个地方传递和修改。结果你猜怎么着？一个地方改了数组，其他地方全跟着变了，直接导致界面显示错乱。后来我把模型改成了Struct，问题迎刃而解。这个经历让我深刻理解了值类型和引用类型不是简单的语法区别，而是两种完全不同的编程思维。

值类型（Value Types），比如Int、String、Array、Dictionary，还有你自己定义的struct和enum。它们最大的特点就是“独立”。每次你把一个值类型的变量赋值给另一个变量，或者作为参数传递给函数时，系统都会完整地拷贝一份新的数据。你可以把它想象成复印一份文件，你修改复印件，原件完全不受影响。这种特性带来了巨大的安全感，尤其是在多线程环境下。因为每个线程操作的都是自己的那份拷贝，根本不用担心数据竞争（Data Race）的问题。

引用类型（Reference Types），主要就是class。它更像是一个共享的储物柜。当你创建一个类的实例，系统在堆（Heap）内存中分配一块空间。变量本身不存储实际数据，只存储一个指向那块内存的“地址”（指针）。当你把这个变量赋值给另一个变量时，拷贝的只是这个“地址”，而不是储物柜里的东西。所以，两个变量指向的是同一个储物柜，任何一个修改了里面的内容，另一个看到的也会是修改后的结果。

这里有个非常关键的面试点：为什么Swift要把String、Array、Dictionary这些常用的集合类型设计成值类型？原始文章提到了安全性和性能，但我们可以说得更透。

首先是线程安全。想象一下，你在一个后台线程里遍历一个数组，同时主线程却在修改这个数组。如果是引用类型，这简直就是灾难现场，程序随时可能崩溃。但值类型就没这个问题，因为每个线程拿到的都是自己的独立副本，互不干扰。苹果在推动Swift成为更安全、更适合现代并发编程的语言时，这个设计至关重要。

其次是写时复制（Copy-on-Write, COW）这个性能魔术。很多人一听“拷贝”就觉得性能差，那是没理解COW。Swift聪明得很。当你把一个数组arrayA赋值给arrayB时，它们俩在底层其实共享同一块内存数据，并没有发生真正的拷贝。系统只是增加了一个引用计数。直到arrayB被修改（比如append一个新元素）的那一刻，系统才会检查这块内存是不是被多个变量引用。如果是，它才会真正开辟新内存，把数据复制过去，然后只修改arrayB的新副本。这个过程对开发者完全透明，既保证了值语义的安全，又兼顾了性能。

你可以写个小实验验证一下：

import Foundation var arrayA = [1, 2, 3, 4, 5] // 此时 arrayA 的底层缓冲区地址是唯一的 print(CFGetRetainCount(CFArrayCreateCopy(nil, arrayA as CFArray))) // 粗略观察，这里只是为了示意 var arrayB = arrayA // 此时发生“逻辑拷贝”，但物理内存未复制，两者共享数据 // 在修改前，它们指向同一块内存 arrayB.append(6) // 此时触发“写时复制”，arrayB拥有了自己独立的数据副本 // 现在修改 arrayB，arrayA 完全不受影响 print(arrayA) // 输出：[1, 2, 3, 4, 5] print(arrayB) // 输出：[1, 2, 3, 4, 5, 6]

所以，在面试中回答使用场景时，可以这样总结：当你需要表示一个独立的、自包含的数据状态，并且希望传递和修改时不影响源头，或者这个模型比较简单、不需要继承时，优先选择struct。比如坐标点CGPoint、矩形区域CGRect、数据模型User、Product等。而当你需要共享和修改同一个对象的状态，或者需要利用继承、多态等面向对象特性来构建复杂的类层次结构时，就该用class了，比如视图控制器UIViewController、网络管理器NetworkManager。

1.1 深拷贝与浅拷贝的陷阱

说到拷贝，这里还有一个容易混淆的点：深拷贝（Deep Copy）和浅拷贝（Shallow Copy）。对于纯值类型（比如只包含Int、String的struct），赋值就是深拷贝，因为所有内容都被复制了。但对于包含引用类型属性的值类型，情况就复杂了。

举个例子：

class Engine { var horsepower: Int init(horsepower: Int) { self.horsepower = horsepower } } struct Car { var brand: String var engine: Engine // 这是一个引用类型属性 } var myEngine = Engine(horsepower: 200) var car1 = Car(brand: "Tesla", engine: myEngine) var car2 = car1 // 这里复制了 car1 的值，但 engine 属性是浅拷贝！ car2.brand = "BYD" // 修改值类型属性，car1.brand 不受影响 car2.engine.horsepower = 300 // 修改引用类型属性，car1.engine.horsepower 也变成了300！

看到了吗？car2.engine和car1.engine指向的是同一个Engine实例。修改car2.engine的属性，car1的也跟着变了。这打破了值类型“独立修改”的预期。要解决这个问题，你需要为Car实现真正的深拷贝，比如让Engine也变成值类型（struct），或者让Car在拷贝时手动复制一个新的Engine实例（实现NSCopying协议或自定义拷贝初始化方法）。

在面试中，如果能主动提到这个陷阱，并给出解决方案，绝对是大大的加分项。这说明你不仅知道概念，还在实际项目中思考过如何正确使用它们。

2. 协议与继承：面向协议编程的思维转变

Swift被很多人称为“面向协议的语言”（Protocol-Oriented Programming， POP），这可不是随便说说的。苹果在2015年的WWDC上就大力推广POP，用它来解决很多传统面向对象继承带来的问题。面试中，关于协议和继承的区别与选择，是考察你对Swift语言哲学理解深度的绝佳问题。

先说说最基础的。继承（Inheritance）是面向对象的经典特性，一个类（子类）可以继承另一个类（父类）的属性和方法。它建立了一种“是一个（is-a）”的关系。比如Dog继承自Animal，狗是一种动物。但Swift只支持单继承，一个类只能有一个父类。这就带来了著名的“菱形继承”问题（虽然Swift用单继承避免了）和类层次结构可能变得过于臃肿、僵化的问题。

而协议（Protocol）定义了一组方法、属性或其它要求的蓝图。它只告诉你“应该有什么能力”，但不提供具体的实现（除非使用协议扩展）。一个类型可以遵循（conform）多个协议，从而建立“能做什么（can-do）”的关系。比如，一个Bird结构体可以同时遵循Flyable和Singable协议。

原始文章提到了协议可以被struct和enum遵循，这是Swift协议比Objective-C协议强大的关键一点。在OC里，协议基本只能由类来遵守。而在Swift里，值类型也能通过遵循协议来获得多态行为，这极大地扩展了值类型的能力，让它们也能参与到抽象的、基于接口的编程中。

我印象很深的一个实战案例是构建一个渲染引擎。最初我用继承：一个基类GraphicObject，然后派生出Circle、Rectangle、Triangle等子类。很快问题来了，我需要一个“可点击”的特性。如果用继承，我得创建一个ClickableGraphicObject子类，然后让需要点击功能的图形类再继承它。但如果一个图形既要可点击又要可拖拽呢？难道要搞一个ClickableDraggableGraphicObject？类爆炸了。

后来我用协议重构：

protocol Renderable { func draw() } protocol Clickable { var bounds: CGRect { get } func handleTap() } protocol Draggable { func beginDrag(at point: CGPoint) func drag(to point: CGPoint) } struct Circle: Renderable, Clickable { var center: CGPoint var radius: CGFloat func draw() { /* 绘制圆形 */ } var bounds: CGRect { /* 计算边界 */ } func handleTap() { print("Circle tapped!") } } struct Button: Renderable, Clickable, Draggable { var title: String var frame: CGRect func draw() { /* 绘制按钮 */ } var bounds: CGRect { return frame } func handleTap() { /* 处理点击 */ } func beginDrag(at point: CGPoint) { /* ... */ } func drag(to point: CGPoint) { /* ... */ } }

看，Circle只需要渲染和点击，Button则需要三种能力。通过组合协议，我轻松地给不同类型赋予了不同的能力，结构清晰又灵活。这就是POP的魅力：组合优于继承。

2.1 协议扩展与默认实现

协议真正的杀手锏是协议扩展（Protocol Extension）。你可以在扩展中为协议要求的方法和计算属性提供默认实现。这带来了两个巨大好处：

1. 代码复用：你可以把通用逻辑写在协议扩展里，所有遵循该协议的类型自动获得这份实现，无需重复编写。
2. 可选方法：在Swift协议中，没有@optional关键字（除非是@objc协议）。但通过协议扩展提供默认实现，你可以模拟出“可选”的效果。遵循类型可以选择使用默认实现，也可以提供自己的实现来覆盖。

protocol Greetable { var name: String { get } func greet() -> String } // 协议扩展提供默认实现 extension Greetable { func greet() -> String { return "Hello, my name is \(name)." } } struct Person: Greetable { var name: String // 这里可以不实现 greet()，直接使用默认实现 } struct Dog: Greetable { var name: String // 也可以提供自定义实现来覆盖默认实现 func greet() -> String { return "Woof! I'm \(name)." } } let alice = Person(name: "Alice") print(alice.greet()) // 输出：Hello, my name is Alice. let buddy = Dog(name: "Buddy") print(buddy.greet()) // 输出：Woof! I'm Buddy.

面试官可能会追问：“那如果协议中声明了方法，又在扩展里提供了默认实现，这算是协议要求吗？” 答案是：算，但遵循类型可以选择不实现。如果一个方法在协议定义中声明了（有方法签名），那么它就是一个协议要求。即使扩展提供了默认实现，遵循该协议的类型依然“满足”了这个要求。这允许你定义一套基础能力（协议声明），同时提供一套开箱即用的通用实现（扩展），非常优雅。

2.2 关联类型与泛型约束

这是协议中比较高级，也是面试中区分中级和高级开发者的分水岭。协议中的关联类型（Associated Type）使用associatedtype关键字声明，它相当于给协议提供了一个“占位符”类型，让遵循协议的类型在实现时来指定具体的类型。

这有什么用呢？想象你要定义一个“容器”协议，它能存放元素，并能返回一个迭代器来遍历这些元素。你不知道容器会存什么类型（Int？String？），也不知道迭代器具体是什么类型。这时关联类型就派上用场了。

protocol Container { associatedtype Item // 关联类型，代表容器中元素的类型 var count: Int { get } mutating func append(_ item: Item) subscript(i: Int) -> Item { get } } struct IntStack: Container { // 在这里，将关联类型 Item 具体化为 Int typealias Item = Int // 这一行可以省略，编译器能推断出来 private var items: [Int] = [] var count: Int { return items.count } mutating func append(_ item: Int) { items.append(item) } subscript(i: Int) -> Int { return items[i] } }

关联类型让协议变得非常灵活和强大，可以用来定义像Sequence、Collection这样的抽象概念。你还可以在协议扩展或泛型函数中，使用where子句对关联类型添加约束，实现更精细的控制。

// 扩展 Container 协议，但只适用于 Item 类型是 Equatable 的情况 extension Container where Item: Equatable { func contains(_ item: Item) -> Bool { for i in 0..<count { if self[i] == item { return true } } return false } }

这个contains方法只对Item可比较的Container有效。这种能力让基于协议的抽象既强大又安全。在面试中，如果能结合Collection协议或自定义的泛型网络层来讲解关联类型，会显得你功底非常扎实。

3. 错误处理：从“崩溃艺术”到“优雅恢复”

错误处理是衡量代码健壮性的重要标尺。Swift抛弃了Objective-C中主要依赖异常（NSException，通常意味着致命错误）和返回错误指针（NSError **）的模式，引入了一套全新的、显式的、类型安全的错误处理机制。面试中，你需要清晰地阐述throw、try、catch、defer这一套组合拳，以及try?和try!的适用场景。

首先，Swift中的错误是实现了Error协议的类型，通常是枚举，因为它能清晰地表达一组相关的错误情况。

enum NetworkError: Error { case invalidURL case requestTimeout(duration: TimeInterval) case noInternetConnection case serverError(statusCode: Int) }

定义错误类型时，使用枚举并关联值，可以携带丰富的错误上下文信息，比如超时了多久、服务器返回了什么状态码，这对于后续的日志记录和问题排查至关重要。

一个可能抛出错误的函数，必须用throws关键字标记。调用它时，你必须用do-catch块来处理可能的错误，或者用try?、try!来简化，或者继续向上层抛出。

func fetchData(from urlString: String) throws -> Data { guard let url = URL(string: urlString) else { throw NetworkError.invalidURL } // 模拟网络请求 let data = try Data(contentsOf: url) // Data的初始化方法本身也会抛出错误 return data }

try：最标准的方式，必须在do-catch块内使用，让你能捕获并处理每一个具体的错误。

do { let data = try fetchData(from: "https://api.example.com/data") // 处理成功获取的数据 parseData(data) } catch NetworkError.invalidURL { print("提供的URL无效，请检查。") } catch NetworkError.requestTimeout(let duration) { print("请求超时，耗时：\(duration)秒。") } catch { // 捕获其他所有错误 print("发生了未知错误：\(error)") }

这种方式的优势是处理粒度细，能针对不同的错误采取不同的恢复策略，用户体验好。

try?：如果你不太关心具体的错误原因，只想知道成功还是失败，可以用try?。如果函数成功，返回一个可选值；如果抛出错误，则返回nil。这常用于那些“有则最好，没有也行”的场景。

if let data = try? fetchData(from: someURL) { // 成功拿到数据 process(data) } else { // 失败了，但我们不关心具体原因，可能使用缓存或显示默认内容 showCachedData() }

try!：断言式调用。你非常确定这个调用在当前的上下文下绝对不会失败。如果它真的失败了，程序会直接崩溃。请极度谨慎地使用它，通常只用于那些在开发阶段就已经完全确定、绝无失败可能的情况，比如加载App内置的、必然存在的资源文件。

// 假设 `appConfig.json` 一定存在于Bundle中 let configData = try! Data(contentsOf: Bundle.main.url(forResource: "appConfig", withExtension: "json")!)

在面试中，面试官可能会问：“什么情况下该用try?，什么情况下该用do-catch？” 这考察的是你对错误处理策略的理解。我的经验是：在UI层或业务逻辑的顶层，尽量使用do-catch进行细致的错误处理和用户提示；在底层工具函数或非关键路径中，可以使用try?简化代码；try!则要像对待!强制解包一样，有十足把握时才用。

3.1 rethrows 的妙用

这是一个高级话题。rethrows关键字用于声明一个函数，它本身不产生新的错误，但它接收的闭包参数可能会抛出错误。这个函数的作用是“传递”错误。最经典的例子就是标准库中的map、filter等高阶函数。

// 模拟一个简单的 map 函数 func myMap<T, U>(_ items: [T], transform: (T) throws -> U) rethrows -> [U] { var result = [U]() for item in items { // 如果 transform 闭包抛出错误，try 会将其向上传递，由 myMap 的调用者处理 result.append(try transform(item)) } return result } let numbers = [1, 2, 3, 4, 0] do { // 使用一个会抛出错误的转换闭包 let strings = try myMap(numbers) { num in guard num != 0 else { throw NetworkError.serverError(statusCode: 400) } return "Number: \(num)" } print(strings) } catch { print("Mapping failed: \(error)") }

注意看myMap的声明：transform闭包是throws -> U，而myMap本身是rethrows -> [U]。这意味着：

• 如果你传给myMap的transform闭包是一个不会抛出错误的普通函数，那么调用myMap时不需要加try。
• 如果transform闭包会抛出错误，那么调用myMap时就必须处理错误（用try、try?等）。

rethrows让函数签名更加精确和友好。它告诉调用者：“我是否抛出错误，取决于你传给我的闭包。” 这使得像map这样的高阶函数既能处理可能出错的转换，又能与不会出错的转换无缝协作，保持了API的简洁性。在面试中能讲清楚throws和rethrows的区别及设计意图，绝对是亮眼的表现。

3.2 defer 的清理艺术

defer语句是Swift错误处理中一个优雅的补充。它用于定义一段代码，无论函数是正常返回、提前返回还是因为抛出错误而退出，这段代码都必定会在当前作用域结束时执行。它的主要用途是进行必要的清理工作，比如关闭文件、释放锁、还原UI状态等，确保资源不会泄漏。

func processFile(atPath path: String) throws { let fileHandle = FileHandle(forReadingAtPath: path) guard let handle = fileHandle else { throw FileError.unableToOpen } // 确保无论如何都会关闭文件 defer { handle.closeFile() print("文件句柄已关闭。") } // 尝试读取文件内容（可能抛出错误） let data = handle.readDataToEndOfFile() // 处理数据（可能抛出错误） try parseData(data) // 函数正常结束，defer 块在这里执行 }

在这个例子里，即使readDataToEndOfFile或parseData抛出了错误，控制流跳出函数，defer块中的closeFile()依然会被调用，文件资源得到妥善释放。这比在函数的多个返回点（return或throw）前都写一遍清理代码要安全、简洁得多。

defer的执行顺序是后进先出（LIFO），即最后一个被定义的defer语句最先执行。这在处理多个需要清理的资源时很有用，可以确保释放顺序与申请顺序相反（这是良好的资源管理实践）。在面试中提及defer，并强调其在资源管理和状态还原中的作用，能体现你编写健壮、安全代码的意识。

4. 高阶函数与函数式编程思想

Swift虽然是一门多范式语言，但其对函数式编程（FP）的支持非常出色。map、filter、reduce、flatMap、compactMap这些高阶函数，是Swift开发者日常工具箱里的必备品。面试中，不仅要会使用它们，更要理解其背后的函数式思想：使用不可变值和表达式，避免状态和副作用，通过组合小函数来构建复杂逻辑。

map：转换。它接受一个闭包，将集合中的每个元素按照闭包的规则进行转换，返回一个新的数组。核心思想是“一一映射”。

let numbers = [1, 2, 3, 4] let squared = numbers.map { $0 * $0 } // [1, 4, 9, 16] let strings = numbers.map { "Number: \($0)" } // ["Number: 1", "Number: 2", ...]

它让你摆脱了繁琐的for-in循环，代码意图更清晰：我要把数组里的每个数变成它的平方。

filter：过滤。它接受一个返回Bool的闭包（谓词），筛选出满足条件的元素组成新数组。

let evenNumbers = numbers.filter { $0 % 2 == 0 } // [2, 4] let bigNumbers = numbers.filter { $0 > 2 } // [3, 4]

reduce：归纳。它接受一个初始值和一个组合闭包，将数组中的所有元素依次与当前累积值进行组合，最终“缩减”成一个单一的值。这是最强大也稍难理解的一个。

let sum = numbers.reduce(0) { partialResult, nextValue in return partialResult + nextValue } // 10 // 简洁写法： let sumShort = numbers.reduce(0, +) // 10，利用运算符函数 let factorial = (1...5).reduce(1, *) // 计算5的阶乘：120

你可以把reduce想象成一条流水线。初始值 (0) 是放在流水线起点的一个空盒子。闭包 ({ $0 + $1 }) 是工人，他的工作是把当前盒子里的东西（$0，即partialResult）和下一个零件（$1，即nextValue）组装起来放回盒子。流水线走完一遍，盒子里就是最终产品。

4.1 flatMap 与 compactMap 的演进

这是面试中的高频细节题。在Swift 4.1之前，flatMap身兼多职，容易让人困惑。之后，它的职责被清晰地拆分：

• flatMap(对序列)：主要职责是“降维”（Flatten）。当你有一个二维数组（数组的数组），想把它“拍平”成一维数组时用它。

  let arrayOfArrays = [[1, 2], [3, 4, 5], [6]] let flattened = arrayOfArrays.flatMap { $0 } // [1, 2, 3, 4, 5, 6]

  它接收一个闭包，闭包对每个元素（子数组）进行转换，但要求转换结果本身也是一个序列。然后flatMap会把所有这些序列连接起来，形成一个新的一维序列。

• compactMap：主要职责是“转换并解包，同时过滤掉nil”。这是从旧版flatMap中分离出来的最常用功能。

  let possibleNumbers = ["1", "2", "three", "4", "//5//"] let mapped = possibleNumbers.map { Int($0) } // [Optional(1), Optional(2), nil, Optional(4), nil] let compactMapped = possibleNumbers.compactMap { Int($0) } // [1, 2, 4]

  map转换后得到的是[Int?]，包含了nil。而compactMap在转换的同时，自动解包并剔除了所有nil，直接得到[Int]，干净利落。这在处理网络返回的JSON数据、解析可能失败的字符串时极其有用。

记住这个口诀：要拍平，找flatMap；去nil，用compactMap。

4.2 组合使用与链式调用

函数式编程的威力在于组合。你可以将多个高阶函数像管道一样连接起来，写出非常声明式的代码。

// 任务：从一个字符串数组中，找出所有能转换成数字的，计算它们的平方，然后求和。 let inputs = ["10", "42", "abc", "33", "99", "xyz"] let result = inputs .compactMap { Int($0) } // 1. 过滤并转换为整数: [10, 42, 33, 99] .map { $0 * $0 } // 2. 计算平方: [100, 1764, 1089, 9801] .reduce(0, +) // 3. 求和: 12754 print(result) // 输出：12754

这段代码几乎没有临时变量，逻辑一气呵成，就像在描述“要做什么”而不是“怎么做”。它更易读、更易维护，也减少了因中间状态出错的可能。在面试中，展示这种链式调用的代码，并解释其相对于命令式循环的优势（如不可变性、无副作用、易于测试），能很好地体现你的现代编程思维。

5. 内存管理与ARC进阶

Swift使用自动引用计数（ARC）来管理引用类型（类实例）的内存。对于大多数开发者来说，ARC是自动的、无形的。但要想在面试中脱颖而出，你必须深入理解ARC的工作原理，特别是强引用循环（Strong Reference Cycle）这个经典问题及其解决方案。

当一个类实例A强引用了实例B，同时实例B也强引用了实例A，它们之间就形成了一个循环。即使外部已经没有变量引用它们中的任何一个，ARC也无法释放它们的内存，因为它们的引用计数永远不会降到0。这就是内存泄漏。

class Person { let name: String var apartment: Apartment? // 强引用一个公寓 init(name: String) { self.name = name } deinit { print("\(name) is being deinitialized") } } class Apartment { let unit: String var tenant: Person? // 强引用一个租客 init(unit: String) { self.unit = unit } deinit { print("Apartment \(unit) is being deinitialized") } } var john: Person? = Person(name: "John") var unit4A: Apartment? = Apartment(unit: "4A") john!.apartment = unit4A unit4A!.tenant = john // 循环引用形成！ john = nil unit4A = nil // 注意：这里没有任何 deinit 消息被打印！John 和公寓 4A 的内存泄漏了。

Swift提供了两种弱引用来打破循环：weak和unowned。

• weak：弱引用。不会增加被引用实例的引用计数。当被引用的实例被释放后，弱引用会自动变为nil。因此，弱引用必须被声明为可选类型（var）。它常用于可能变为nil的引用，比如 delegate 模式。

  class Apartment { let unit: String weak var tenant: Person? // 弱引用租客 // ... 其余代码不变 } // 现在，当 john = nil 时，Person 实例会被释放，tenant 自动变为 nil。然后 unit4A = nil 时，Apartment 也能被释放。

• unowned：无主引用。同样不会增加引用计数。但它假定引用对象在整个生命周期中永远不会变成nil。因此，无主引用总是被定义为非可选类型。如果你尝试在被引用对象释放后访问一个无主引用，会导致运行时崩溃。它用于生命周期相同或更长的引用，比如顾客和信用卡（信用卡不能脱离顾客存在）。

  class Customer { let name: String var card: CreditCard? init(name: String) { self.name = name } deinit { print("\(name) is being deinitialized") } } class CreditCard { let number: UInt64 unowned let customer: Customer // 无主引用顾客 init(number: UInt64, customer: Customer) { self.number = number self.customer = customer } deinit { print("Card #\(number) is being deinitialized") } }

5.1 闭包捕获列表与循环引用

闭包是引用类型，当它捕获了外部的类实例属性时，也会导致循环引用，因为闭包持有实例，而实例可能又通过属性持有了这个闭包（比如将闭包赋值给一个实例属性）。

class HTMLElement { let name: String let text: String? // 闭包属性，可能捕获 self lazy var asHTML: () -> String = { // 这个闭包捕获了 self (通过 text 和 name) if let text = self.text { return "<\(self.name)>\(text)</\(self.name)>" } else { return "<\(self.name) />" } } init(name: String, text: String? = nil) { self.name = name self.text = text } deinit { print("\(name) is being deinitialized") } } var paragraph: HTMLElement? = HTMLElement(name: "p", text: "Hello, world!") print(paragraph!.asHTML()) // 调用闭包，创建了强引用循环 paragraph = nil // 即使 paragraph 设为 nil，HTMLElement 实例也不会被释放！

解决方法是使用捕获列表（Capture List），在闭包定义时明确指定如何捕获self。

lazy var asHTML: () -> String = { [unowned self] in // 捕获列表：使用无主引用来捕获 self if let text = self.text { return "<\(self.name)>\(text)</\(self.name)>" } else { return "<\(self.name) />" } }

这里使用[unowned self]是因为asHTML闭包和self（HTMLElement实例）的生命周期相同，当实例被释放，这个闭包也不会再被使用。如果闭包可能在实例被释放后仍然被调用（比如异步回调），那么应该使用[weak self]，并在闭包内安全解包。

在面试中，面试官可能会让你手写一个存在循环引用的例子，并让你修复它。清晰地指出问题所在，并正确使用weak或unowned以及捕获列表，是必备技能。更进一步，你可以讨论在SwiftUI中，@StateObject、@ObservedObject、@EnvironmentObject这些属性包装器是如何在背后管理生命周期和避免循环引用的，这能展示你对现代Swift框架的深入理解。

6. 派发机制：静态与动态的权衡

方法的派发方式决定了程序在运行时如何找到并执行正确的方法实现。理解静态派发（Static Dispatch）和动态派发（Dynamic Dispatch）对于编写高性能Swift代码至关重要，也是面试中考察底层原理的常见问题。

静态派发，也叫直接派发。编译器在编译时就能确定要调用哪个方法的具体实现，并直接生成调用该实现地址的指令。这非常快，因为运行时没有任何查找开销。在Swift中，以下情况使用静态派发：

• 全局函数。
• 结构体 (struct) 和枚举 (enum) 的方法（因为它们不能被继承，方法实现是确定的）。
• 使用final关键字标记的类和方法（禁止重写，实现唯一）。
• 使用static关键字定义的类方法（隐式final）。
• 被编译器内联 (@inline(__always)) 的函数。

动态派发，在运行时决定调用哪个方法。这提供了多态性（Polymorphism）的灵活性，但带来了一些运行时查找的开销。Swift中主要有两种动态派发：

1. 虚表派发（VTable Dispatch）：这是Swift类方法默认的派发方式。每个类都有一个虚表（vtable），里面存储了该类所有可重写方法的函数指针。当调用一个方法时，运行时根据对象的实际类型，去对应的虚表中查找方法的地址。这支持了继承和方法重写。
2. 消息派发（Message Dispatch）：这是Objective-C运行时使用的机制。通过objc_msgSend函数发送消息，在运行时动态查找方法实现。在Swift中，只有显式标记为@objc或dynamic的类成员才会使用消息派发。这主要用于与Objective-C代码交互或支持KVO等动态特性。

协议派发是Swift中一种特殊的动态派发。对于协议中声明的方法（没有默认实现），Swift会为每个遵循该协议的具体类型创建一个协议见证表（Protocol Witness Table, PWT）。当通过协议类型调用方法时，运行时通过PWT找到具体类型的实现。如果协议扩展提供了默认实现，并且遵循类型没有重写它，编译器可能会优化为静态派发。

为什么派发方式很重要？因为性能。静态派发允许编译器进行更多的优化，比如内联（将函数体直接插入调用处，消除调用开销）。在性能关键的代码路径中（比如在紧密循环中调用的方法），使用final、将类改为struct，或者将方法标记为private/fileprivate（这暗示它们不会被重写，编译器可能将其推断为final）可以触发静态派发，从而提升性能。

面试中可能会问：“如何让一个类的方法使用静态派发？” 答案是：将其标记为final。或者更进一步：“一个协议方法，如何尽可能让它快？” 答案是：如果可能，让遵循该协议的类型是值类型（struct/enum），因为协议对值类型的方法调用经过优化后可能更接近静态派发；或者，如果协议方法有默认实现且遵循类型不重写它，编译器也可能优化。

在实际项目中，我经常对工具类、纯数据模型类使用final，或者直接设计成struct。对于需要多态的核心业务类，则接受动态派发的成本。这是一种典型的空间（灵活性）换时间（性能）的权衡，理解这一点能帮助你在架构设计时做出更明智的选择。