Swift 面试题库

ARC 会为类实例插入并平衡所需的保留与释放操作。强引用让实例保持存活；最后一个仍需要实例的强引用消失后，实例就可以执行析构。程序员仍要设计所有权图。ARC 不会替你决定双向属性、存储回调、任务或订阅是否应拥有目标，也不会回收全部由强引用组成的不可达循环。你必须把每个关系分类为 strong、weak 或 unowned，并为非内存资源和长期注册提供显式清理。

两者都是非拥有引用，都不会让目标保持存活。目标可能先释放，而且缺失是有效状态时，应选择 weak；ARC 会把可选的弱引用变量自动置为 nil。只有构造过程与封装能保证每次通过引用方访问时目标都存活，才能选择 unowned。普通 unowned 引用的保证一旦被破坏，访问就会触发运行时错误。这个选择表达语义，不是语法捷径或性能排名。评审时要寻找会破坏生命周期顺序的延迟回调、独立缓存、导航和取消路径。

应从存储关系开始，而不是只看闭包语法。先找出谁保留闭包，再列出闭包捕获的每个类实例，包括存储方法引用中隐藏的接收者。如果强引用边从对象通向闭包，再直接或经过其他所有者回到对象，就形成了循环。把一条不表示所有权的边改为弱捕获，并明确目标消失后的行为。随后在外部保留回调副本，释放原对象，并测试成功、失败、取消和延迟调用路径。

弱捕获会改变程序行为，不只是减少内存保留。如果没有其他所有者让实例存活，闭包可能静默跳过本应完成的保存或状态转换。反过来，在长任务开头把 weak self 绑定成强局部引用，又可能跨越每个挂起点保留实例，违背原本希望提前释放的意图。先决定工作应比发起者活得更久、随发起者取消，还是允许放弃单个步骤，再有意识地选择强或弱捕获，并测试每个 await 与取消边界附近的生命周期。

捕获列表项会在创建闭包时求值。[snapshot = value] 会保存当时求得的值，即使外层变量之后重新绑定也不改变。这样做不会自动变成非拥有关系；如果结果是类实例，snapshot 仍会强持有同一个对象。目标可以先消失而且闭包能处理 nil 时使用 weak。只有已证明的生命周期不变量保证每次访问时目标都存活，才能使用 unowned。评审时应把创建时的取值语义与存储项形成的所有权边分开判断。

闭包是函数值：它具有函数类型，可以存储、传递并在之后调用。Swift 的全局函数、嵌套函数和闭包表达式都是闭包的不同形式。捕获表示闭包在离开定义位置后，仍能访问词法上下文中的声明。可变局部变量可以位于共享的捕获存储中，因此之后的修改仍然可见。捕获列表项则在创建闭包时初始化。如果该项是类实例，而且没有标记 weak 或 unowned，它仍然是强引用。

闭包参数默认非逃逸，因此函数不能存储它，也不能用其他方式让它比当前调用活得更久。这是生命周期限制，不是“恰好调用一次”的保证；函数可以在返回前调用零次或多次。只有存储或延后调用需要更长生命周期时，才给参数标记 @escaping。逃逸本身不表示异步，逃逸回调也可能在函数返回前运行。API 还必须另外说明调用次数、重入、执行上下文、取消行为以及捕获对象的所有权。

Codable 是 Encodable 与 Decodable 的组合类型别名。Encodable 要求实现 encode(to:)，承诺能把值写入外部表示；Decodable 要求实现 init(from:)，承诺能从外部表示构造值。数据只朝一个方向流动时，应选择更窄的协议。只用于响应的传输模型通常只需 Decodable，避免通用代码意外输出内部字段。只用于发出的命令可以仅遵循 Encodable，因为从不可信输入接受同样形状并不属于它的契约。这种选择既说明边界，也减少无意开放的能力。

参与转换的存储属性都遵循目标协议时，Swift 可以合成相应的协议要求。没有 CodingKeys 时，属性名就是键；匹配的 CodingKeys 枚举可以重命名字段，也可以排除那些解码后仍能取得值的属性。计算属性不会参与。模型与外部表示形状相同时应保留合成。需要压平嵌套、读取判别字段、区分缺失与 null、迁移旧字段或应用明确的回退规则时，再手写 init(from:) 或 encode(to:)。自定义代码应保留 codingPath，并对契约要求的字段维持严格解码。

原始值是在每个 case 声明中固定的一项字面值。所有 case 使用同一种原始值类型，各值必须唯一；外部输入找不到对应 case 时，init?(rawValue:) 会失败。关联值则在每次创建枚举实例时提供，因此同一个 case 的不同实例可以携带不同数据，不同 case 也可以拥有不同载荷类型。我会用原始值表示稳定的协议标记，用关联值保存错误原因、收据或进度等每次事件都可能变化的数据。

没有 default 时，编译器会证明所有当前 case 都已处理；以后增加 case，也会直接指出需要修改的 switch。default 会丢掉这条维护信号，并可能让新状态走进为旧状态编写的行为。确实共享行为的多个 case 可以写在同一个逗号分隔模式中，不必牺牲穷尽性。主要例外是可独立演进的外部非冻结枚举；此时 @unknown default 提供未来 case 的路径，同时仍会警告当前 SDK 中已知却未明确处理的 case。

代码负责完整分派时，我使用 switch，因为它保留穷尽性，也清楚展示分支优先级。if case 适合在局部像布尔判断一样检查一种结构；guard case 把某种结构作为继续执行的入口条件，并让绑定值在后续代码中可用。for case 会把序列筛成匹配元素，还能配合 where 增加条件。后三者会有意忽略其他 case，不适合代替状态机。如果跳过的 case 需要日志、拒绝或清理，普通循环加穷尽 switch 更清楚。

indirect 只让递归存储成为可能，并不会限制结构大小，也不会自动保证遍历安全。我会在解码或解析边界限制深度、节点总数和集合宽度，然后才接受该值。对于 all([])、any([]) 这类空组合节点，要先定义语义并单独测试。求值器应使用穷尽 switch，让新增语法 case 时必须补上语义决策。如果允许很深的结构，还要考虑迭代遍历，避免耗尽调用栈；递归值模型本身则尽量不包含副作用。

我会在能够作出真实恢复决策的最低边界捕获错误。也就是说，这一层可以重试文档明确说明的瞬时失败、要求修正输入、选择明确的后备方案，或把实现细节转换成稳定的领域错误。仅记录日志不算恢复；宽泛捕获后返回正常默认值，往往会制造假成功。如果当前层无法改变结果，我会保留错误并继续传播。我还会检查每个可抛出步骤前后的部分状态，因为 throws 并不意味着自动回滚。

普通 throws 等价于 throws(any Error)，因此函数类型暴露的是开放失败集合。throws(ParseError) 会把函数体限制为该具体错误类型，并为调用方保留类型信息，从而支持穷尽处理和更短的 case 语法。我会在一个抽象完整拥有少量稳定失败时使用类型化 throws，例如内部解析器。我不会只为形式整齐就把依赖错误强行压进封闭枚举，因为公共 API 可能需要演进空间。非抛出函数对应 throws(Never)，可以用于接受抛出函数的位置。

let 创建初始化后不能改绑到其他值的绑定，var 则允许重新赋值，也允许执行值的 API 所支持的修改。对于 Array 之类的值类型，let 绑定会阻止对该值执行修改操作。对于类引用，let 固定的是绑定指向哪个实例，但实例上的可变属性仍然可以改变。我默认从 let 开始，让确实需要修改的位置清楚可见；只有算法会重新赋值或修改该值时，才把绑定改成 var。

类型推断根据初始化值和周围上下文得出静态类型，并不会让声明保持动态类型。当空集合需要元素类型、数值字面量应采用特定表示，或公开契约不够清楚时，我会添加类型标注。转换是另一回事。Swift 不会隐式相加 Int 与 Double，所以我会先确定计算的单位和精度，再构造目标类型。对于文本输入，我会处理解析得到的可选结果，而不是把转换失败当成零。

我会先说明 nil 在该边界表示什么。字典查找失败可能表示字段缺失，Int(text) 失败则可能表示字段存在但格式错误；两者并不自动等价。局部的双路径判断使用 if let，函数后续都需要该值时使用 guard let。只有缺失确实应当具有某个默认含义时，?? 才是正确选择。外部数据不使用强制解包；调用方需要具体失败类别来恢复或诊断时，则使用可抛出或返回结果的 API。

我先判断模型需要什么语义。快照、坐标或解码记录等值在复制后应独立变化，适合结构体；稳定身份与共享生命周期有意义的实体，适合类。继承、析构和 Objective-C 互操作也可能要求使用类，但仅仅需要遵循协议并不能推出必须用类。我不会根据大小或“栈与堆”的口号选择。我会沿调用点追踪赋值、修改与所有权；两者都可行时先用结构体，语义契约正确后再分析性能。

对于结构体，let 绑定会阻止修改该值，包括调用 mutating 方法，因为这些操作需要对 self 的写访问。对于类，let 只阻止绑定改指向另一个实例，所引用实例的可变属性仍可改变。因此，let 不表示深层不可变。我会分别检查绑定与可达对象。如果调用方需要冻结视图，就返回值快照或只暴露不可变属性，而不是假定常量类引用能保护整个对象图。

不会。复制会创建新的外层值，但每个存储属性仍遵循自己的语义。String 或其他普通值属性会独立变化，类类型属性则只复制指向同一实例的引用；修改该嵌套实例后，两个外层值都能观察到变化。我把它称为浅拷贝边界，而不是值语义失效，因为该字段的值本来就是引用。需要真实快照时，我会使用值类型的嵌套状态，或提供显式复制操作，并准确说明哪些引用资源会复制、哪些仍然共享。

扩展可以添加计算实例属性或类型属性、方法、类的便利构造器、值类型构造器、下标、嵌套类型与协议遵循。它不能添加存储属性或观察器、类的指定构造器、析构器、父类，也不能覆盖已有行为。行为只依赖现有状态，或把协议遵循分离后实现更清楚时，我会使用扩展。功能需要新存储、独立不变量、单独所有权，或需要安全适配外部类型时，我会引入包装类型，而不是用全局状态模拟存储。

泛型参数会在编译期保留所有同名位置之间的类型关系。对于 first<T>([T]) -> T?，传入 [Int] 就得到 Int?，实现也不能返回无关的 String。改用 Any 虽然允许异构输入，却会删除这项证明，使函数体只能使用 Any 的能力，并迫使调用方转换结果。只有运行时异构性本来就是数据模型的一部分时，我才使用 Any；输入与输出应保持关联时，泛型签名本身就是契约。

Optional<Wrapped> 是包含 .some(Wrapped) 与 .none 的枚举，Wrapped? 是常用简写，nil 表示 .none。当 API 只有一种有意义的缺失状态时，我会使用可选类型，例如查询未命中或用户没有填写资料字段。契约仍须说明 nil 的准确含义。我不会用 nil 合并调用方必须区分的格式错误、权限拒绝与传输失败；这些情况需要领域错误、throws、Result 或更丰富的枚举。空字符串、零、false 与空集合仍是存在的值，除非领域明确要求归一化。

当存在与缺失两个分支在局部都有行为时，我使用 if let；当剩余作用域都要求该值，而缺失路径应提前退出时，我使用 guard let。可选链适合任一环缺失后结果都相同的查询或修改，但它不会指出具体失败环节。空合并适合在语义上等同于缺失的后备值，而且右侧惰性求值。我不会用便利默认值替换格式错误。选择依据是调用方需要保留哪些信息，而不是哪种语法行数最少。

Swift 会把源码层属性变成计算接口，并引入名称带下划线前缀的私有后备存储。后备字段保存包装器实例，普通属性则把访问委托给它的 wrappedValue。如果包装器定义了 projectedValue，Swift 还会合成美元符号前缀的投影，其类型与可变性来自该成员。我把这种展开当作语义模型，而不是公开 ABI。使用方应访问普通属性和有文档的投影；只有外围类型才应在初始化期间配置下划线存储。

协议描述必须具备的能力，结构体、枚举、actor 与类都能显式遵循。类继承还会带来对象身份、存储状态、超类实现与“是一种”的层级关系，而且类只有一个直接超类。当调用方需要在无关类型之间建立窄小能力契约时，我选择协议；只有子类型身份与共享超类行为确实属于领域模型时，我才选择继承。协议不会自动产生解耦：过大的协议会迫使每个遵循类型依赖无关操作，耦合程度并不比设计不良的基类低。

@escaping 允许函数值比接收它的调用活得更久。@Sendable 表示函数值可以安全跨越并发域，因此会对捕获值和可变状态增加约束。两者相互独立：闭包可能只需要其中一个、两个都需要或都不需要；async 也只增加挂起能力。在 Swift 6 严格并发检查下，捕获可变的非 Sendable 类或修改共享局部状态可能产生诊断。应修复所有权或隔离设计，例如把状态移入 actor，或只传递不可变的 Sendable 值，而不是机械添加 @unchecked Sendable。

count += 1 这样的复合表达式先读取再写入。如果包装器分别给两个访问器加锁，它会在读取后释放锁，写入时再取得锁；另一个调用方可能在间隙读到相同旧值，导致一次递增丢失。修复方式是提供覆盖完整状态转换的同步操作，或用 actor 隔离让状态归属一个执行器。我会在竞争调用下测试业务不变量；孤立的读写能够成功，不表示具备事务级原子性，也不能证明满足 Sendable 契约。

应从字段语义出发，而不是把所有属性都改成可选。合成解码通常忽略对象中的额外未知键，因此服务端增加字段一般安全。客户端新增必需属性会让旧载荷触发 keyNotFound；只有缺失确实有合理含义时，才使用可选类型或显式默认值。字段重命名要通过 CodingKeys 或迁移逻辑保留。服务端可扩展枚举可以用携带原始值的 unknown case 提供向前兼容，但安全敏感状态可能必须严格拒绝。测试两个版本方向的黄金载荷，并分别覆盖缺失、null、错误类型和未知值。

应在数据边界捕获 DecodingError，而不是用 try? 抹掉它。不同错误 case 能区分缺失键、空值、类型不匹配和损坏数据；每个上下文还带有指向嵌套对象与数组的 codingPath。把底层原因包装进应用错误，同时只记录模型类型、请求标识、错误类别和脱敏路径等获准元数据，默认不要记录完整载荷。解码成功只验证表示，不代表业务可信。范围限制、最大尺寸、URL 策略、跨字段不变量与授权仍需单独验证，然后才能构造可信的领域对象。

一次调用产生成功值或把失败直接交给当前调用方时，我使用 throws。它让正常路径保持线性，也能自然配合 async throws。只有结果本身必须成为数据时，我才选择 Result，例如保存多次尝试、把结果放入集合、通过回调协议发送，或跨越适配边界。Result 不会增加恢复语义，调用方仍要决定如何处理每种失败。get() 会把保存的失败重新变成抛出控制流，map 与 mapError 则分别转换两侧。

rethrows 保证高阶函数只会因为某个声明为可抛出的函数参数抛错而抛错。因此，传入非抛出参数时，包装调用仍然不抛错。包装器不能在不修改声明的情况下新增无关的审计、缓存或配置错误。defer 是另一项机制：它会在成功或错误退出作用域前按后进先出顺序运行，但不会回滚外部副作用。如果主体与清理都可能失败，API 必须规定哪个错误优先，以及如何让另一个原因仍然可观察。

我会把约束放在真正使用它的最窄稳定能力上。如果缓存始终用字典保存键，哈希能力支撑类型不变量，Key: Hashable 就属于类型声明。若只有一个 contains 方法比较元素，Element: Equatable 应放在该方法或受约束扩展上；只有部分类型实参能让泛型类型遵循协议时，则使用条件遵循。我会让每项要求都能指向需要它的表达式。无用约束不是无害文档，它会排除有效调用方，还可能传播到更高层签名。

当调用方只需要“有值”或“没有结果”，而缺失是无需诊断信息的正常结果时，我返回 T?。失败原因会改变当前调用方控制流并需要携带上下文传播时，我使用 throws。结果本身需要保存、排队、组合或通过回调传递时，我使用 Result<T, Failure>。try? 会把错误转换为可选值，同时有意丢弃原因，因此只适合所有错误处理方式都相同的地方。如果存在多个正常的非错误状态，领域枚举通常比嵌套可选值或含义过载的 nil 更清楚。

projectedValue 是通过 $property 公开的可选 API，并不会自动成为绑定或包装器实例。我只用它提供一种补充包装值的稳定能力，例如验证状态或范围明确的修改接口。美元符号语法会隐藏类型、所有权与可变性选择，因此这些信息必须有文档。组合包装器只公开最外层投影；需要内层能力时，外层必须有意转发。我不会返回所有内部可变状态，因为这会绕过不变量，并把后备实现顺序变成使用方契约。

我会先检查 any Catalog<Product> 之类的原生存在类型是否已经能表达边界。只有包装器提供了存在类型没有的稳定接口、值语义，或对多个隐藏对象的组合时，才值得手写。它的泛型构造器应验证关联类型关系并捕获类型正确的操作；Any 字典加 as! 是运行时陷阱，不是可靠的擦除。我还会检查复制、共享引用状态、可发送性、取消和错误传播，因为只转发方法签名并没有定义这些语义。测试应替换遵循者、复制包装器，并通过擦除后的 API 覆盖失败路径。

我根据契约选择，而不是只看有哪些方法。Array 表示有序序列并允许重复。Set 表示唯一且符合 Hashable 的元素，适合成员判断与集合运算，但其迭代顺序不是展示契约。Dictionary 把唯一且符合 Hashable 的键映射到值；键可能缺失，所以查找返回可选值。如果输出顺序可观察，我会先显式排序。我还会在访问数组下标前验证外部索引，并明确重复字典键应被拒绝、保留首项、保留末项还是合并。

写时复制允许多个逻辑值暂时共享私有引用存储。每条修改路径在写入前检查存储引用是否唯一；不唯一时先复制，因此调用方仍会观察到独立值。如果存储逃逸、某个 setter 跳过唯一性检查，或代码把 isKnownUniquelyReferenced 当作同步机制，自定义实现就会失败。该检查只描述当时的引用情况，并不会让并发修改自动安全。我会在复制后测试所有修改 API，并确保值包装器之外无法访问存储类。

每项协议要求在遵循关系中都有见证。扩展实现可以作为默认见证；具体类型自己满足要求时，通过存在类型调用仍能到达该实现。只在扩展中声明的成员没有见证槽。如果接收者的静态类型是协议，即使具体类型声明了同名方法，Swift 仍会选择扩展成员；同名方法不是覆盖。调用方需要多态定制时，我会把成员写进协议声明，只把默认方法体留在扩展中，并测试具体类型与协议类型两条路径。

受约束扩展只在 where 条件可被证明时提供其中的成员，例如仅在 Element: Equatable 时添加 contains。条件遵循则让泛型类型只在条件成立时遵循某个协议，例如 Element 可比较时 Batch 才遵循 Equatable。两者都是编译期关系，不是运行时能力探测。我会把约束放在真正需要它的最窄能力上，让无条件操作服务所有类型实参，并避免用重叠条件给同一泛型类型提供语义不同的同协议遵循。

追溯遵循是当前模块既不拥有类型、也不拥有协议时声明的遵循。协议遵循在进程中全局唯一，任一上游拥有者以后都可能在不知道客户端声明的情况下发布同一组合，因此 Swift 6 会发出警告。写出 @retroactive 只表示接受责任并消除警告；它不会提供命名空间、文件局部性，也不会安全解决未来的重复遵循。我会优先使用包装类型或当前模块拥有的协议；无法避免时，则记录语义、依赖升级检查与迁移方案。

两者都是占位类型，但具体类型由不同边界选择。使用者在命名或创建泛型类型时选择 Box<Value>；协议遵循者则通过满足协议的成员确定关联类型，泛型代码用 C.Item 引用这个依赖类型。主关联类型只增加 some Catalog<Product> 这样的简洁约束语法，不会把协议变成普通泛型类型。我会根据谁拥有类型选择权，以及调用方需要表达哪些同类型关系来选择形式。

对于 <T: P>，每个调用方选择一种具体 T，所有 T 位置都保留该类型身份。参数位置的 some P 是未命名泛型参数的简写，仍由调用方选择具体类型，但实现不能在其他位置引用它。返回位置的 some P 由实现选择，并具有一个隐藏的底层类型。any P 值可以在运行时保存不同遵循类型，只保留协议接口。我只在确实需要异构存储时使用 any，不会把它当作修补泛型约束错误的机械手段。

我先判断由谁选择具体类型。对于 <T: P>，每个调用方选择一种 T，所有 T 位置都保留该身份，适合存在输入输出关系的算法。返回 some P 时，实现方选择一种隐藏的底层类型，适合隐藏实现的工厂。any P 值可在运行时保存不同遵循者，只暴露协议边界，适合异构存储。我不会为了消除泛型错误就机械改用 any，因为这会擦除证明并引入转换。签名应保留调用方需要的所有关系，只隐藏不需要的细节。

不能。优化器可能针对具体类型特化泛型函数，但源码语义不保证每种类型都生成一份机器码。优化级别、可见性、模块边界、弹性模型和编译器版本都可能改变结果。我把静态类型关系与复用视为泛型的确定收益；处理性能问题时，则在目标平台上测量发布构建并检查真实热点。我不会只为促使特化而增加约束，因为约束首先会改变 API 契约、排除调用方，却未必改善已测量的工作负载。

Dictionary<Key, Value> 下标返回 Value?，因为键可能不存在。如果 Value 本身是 T?，查询类型自然就是 T??。外层区分键缺失与键存在，内层还能表示记录存在但没有值。当这些状态驱动不同行为时，我会保留两层，例如“没有问卷响应”与“已记录响应但尚未评分”。如果区别无关，可以用连续绑定或 flatMap 有意合并。对于公开模型，具名的三分支领域枚举通常更容易阅读，也更不容易写错。

我先判断谁选择具体类型，以及哪些类型关系必须保留。泛型参数，包括参数位置的 some P，让每次调用选择一种类型，并保留涉及该类型的关系。返回位置的 some P 让实现选择一个固定但隐藏的类型，同时保留其身份与关联类型约束。any P 允许变量或集合随时间保存不同遵循类型，但会擦除具体类型身份，只公开协议契约。我只在确实需要运行时异构性时使用 any，不会把它当作泛型的短写；调用方需要关联类型信息时，我会约束主关联类型。

关联类型让协议命名一种由每个遵循类型确定的类型关系，例如信息源的 Item 或解析器的 Output。泛型代码可以引用这个见证，把参数与返回值关联起来，而无需全局选定一种具体类型。any P 值能够保存遵循者，但擦除后可能隐藏输入操作或跨值关系所需的关联类型。主关联类型允许签名保留选定信息，例如 any Feed<String>。如果两个值必须共享同一种未知元素类型，我会把该类型提升为泛型参数，而不是假设两个独立存在盒彼此相关。

关联类型是由每个遵循关系选择的依赖类型，例如 Sequence.Element 或解析器的 Output。泛型代码可以用 C.Element 引用它，并添加约束或同类型要求，而无需全局决定一种具体类型；这样能保留协议成员与函数签名其他位置之间的关系。主关联类型只为选定关联类型提供 any Catalog<Product> 这样的简洁约束语法，不会把协议变成普通泛型类型。当一次遵循拥有选择权时，我使用关联类型；当每次方法调用应独立选择时，我使用方法类型参数。

对于 @Rule(options) var value = initial，Swift 把 initial 传给 wrappedValue 参数，其余 options 传给包装器的其他参数。没有初始值时，可以使用匹配的包装器构造器或 init() 初始化后备存储。外围构造器若只需 init(wrappedValue:)，可以通过普通属性初始化；需要直接配置包装器时则赋值 _value。对于结构体，这些能力还会决定合成逐成员参数采用原属性类型还是包装器类型。公开 API 的构造签名需要稳定时，应显式声明构造器。

只有协议声明中的成员才是带遵循见证的要求。扩展可以为这类要求提供默认实现，遵循类型的匹配实现随后能通过协议边界被选择。仅由扩展新增的成员没有见证项，Swift 会根据表达式的静态类型解析它。因此，具体值可能调用自身的同名成员，而 any P 值却调用扩展成员。如果行为需要多态变化，我会先在协议中声明要求，再把默认实现放进扩展，并同时测试两条调用路径。

首先要看方法是否出现在协议声明中。如果它是协议要求，扩展可以提供默认见证，遵循类型也可以提供通过遵循关系选择的实现。如果方法只存在于扩展中，受协议约束的泛型代码会静态解析这个便利成员。具体类型上的同名方法只影响直接以具体静态类型发起的调用，不会追溯成为见证。行为必须可定制时，我会在协议中声明要求，并分别通过具体类型、泛型约束与存在类型测试调用，而不是只测一次直接调用。