Swift 在显式内存所有权的演变始于引入 ARC（自动引用计数），它通过在编译时插入保留、释放和复制操作来自动管理内存。虽然 ARC 确保了内存安全，但它在性能敏感领域（例如实时系统或高频数据处理）中引入了运行时开销，这可能变得不可承受。为了解决此问题，Swift 5.9 引入了参数所有权修饰符——具体来说是 borrowing、consuming 和现有的 inout——它们提供了关于值生命周期和可变性的明确契约。
根本问题出在 Swift 的默认复制语义上：当传递一个类实例或一个包含堆分配存储的值类型（如 Array 或 String）时，编译器通常会发出一个保留调用，以确保被调用者在调用期间拥有强引用。对于值类型，如果引用计数大于一，这可能触发 COW（写时复制）逻辑。这种隐式复制确保了安全性，但在紧密循环或需要确定性延迟的并发环境中创建了可预测的性能瓶颈。
解决方案利用所有权转移语义：borrowing 参数表明被调用者接收一个临时的、不可变的引用而不声称所有权，从而允许编译器完全省略保留/释放对。consuming 参数表明调用者将所有权转移给被调用者，后者随后对值的销毁或进一步转移负责，仍然避免保留调用，将操作视为移动。对于值类型，consuming 允许进行位级移动而无需复制底层缓冲区，而 borrowing 通过保证只读访问来防止 COW 触发。
import Foundation final class AudioBuffer { var data: [Float] init(size: Int) { data = Array(repeating: 0.0, count: size) } } // 默认：入口时保留，退出时释放 func processDefault(_ buffer: AudioBuffer) -> Float { return buffer.data.reduce(0, +) } // 借用：无 ARC 交通，不可变引用 func processBorrowing(_ buffer: borrowing AudioBuffer) -> Float { return buffer.data.reduce(0, +) } // 消耗：所有权转移，无保留，被调用者管理生命周期 func processConsuming(_ buffer: consuming AudioBuffer) -> [Float] { return buffer.data // 转移内部数据或缓冲区的所有权 } // 使用示例演示移动语义 var buffer = AudioBuffer(size: 1024) let sum = processBorrowing(buffer) // 无保留 processConsuming(buffer) // 移动，此时缓冲区不再有效
我们的团队为 iOS 开发了一个实时音频合成引擎，其中音频渲染回调在一个专用的高优先级线程上操作。系统在复杂的滤波器链中开始遇到间歇性音频掉落（故障），分析显示是因为在处理节点之间传递样本缓冲区时的 ARC 保留/释放流量。这个开销违反了回调必须在 3 毫秒内完成以避免可听伪影的严格实时约束。
第一个考虑的解决方案是将所有音频缓冲区转换为 UnsafeMutablePointer<Float> 以手动管理内存。这种方法将完全消除 ARC，将缓冲区视为原始 C 指针。但是零开销的优点被重大缺点所掩盖：代码变得内存不安全，容易出现使用后释放错误，并且在经验水平各异的团队中难以维护。
第二个解决方案涉及使用 Unmanaged<T> 手动控制引用计数，包装类实例并使用特定边界上的 takeRetainedValue() 和 passRetained()。虽然这保持了一定的类型安全，但缺点包括极高的冗长度和引用计数不平衡导致泄漏或崩溃的风险。它还需要仔细审计每个代码路径，使代码库在重构时变得脆弱。
第三个解决方案采用 Swift 5.9 的所有权修饰符，重构音频管道以在只读滤波器操作中使用 borrowing AudioBuffer，在异步阶段之间转移缓冲区所有权时使用 consuming AudioBuffer。优点包括零成本抽象，完全由编译器强制执行安全性：borrowing 消除了滤波读取的保留调用，而 consuming 允许在管道阶段之间进行移动语义而无需复制大量音频数据。唯一的缺点是需要升级到 Xcode 15，并重新设计一些无法轻松表达所有权约束的面向协议接口。
我们选择了第三种解决方案，因为它提供了所需的性能特性，而不牺牲内存安全性或需要不安全的代码模式。通过将 borrowing 应用于音频回调的热点路径，我们将实时线程中的 ARC 流量降低到零，同时保持 Swift 的类型安全保证。consuming 模式通过明确转移所有权从生产者到消费者线程，简化了我们的环形缓冲区实现，而不需要昂贵的复制操作。
结果是完全消除了音频掉落，将音频线程在峰值处理负载下的平均 CPU 使用率从 45% 降低到 28%。代码库保持完全内存安全，编译时错误在重构过程中捕捉到了多个潜在的生命周期错误，这些错误在 UnsafeMutablePointer 方法下可能导致崩溃。此外，显式的所有权注释作为 API 合同的文档，使代码对未来的开发者更易于维护。
为什么将 borrowing 应用于值类型参数可以防止在底层存储共享时触发写时复制 (COW)，以及这与 inout 的区别是什么？
当通过 borrowing 传递使用 COW（如 Array 或 Dictionary）的值类型时，编译器保证被调用者无法通过该绑定变更值。由于变更不可能，Swift 可以通过引用传递值，而无需检查引用计数或复制缓冲区，即使存在其他引用。相比之下，inout 允许变更，迫使编译器在写入之前验证引用计数是否为一；如果不是，它会触发昂贵的复制以保持其他引用的值语义。
在什么特定条件下编译器会拒绝 consuming 参数传递，consume 操作符又是如何解决此问题的？
如果传递的参数不是该值的最终使用（即后续访问会违反排他性法则），编译器会拒绝将参数传递给 consuming 参数。对于不可复制类型，这是一个硬错误，因为无法复制该值以满足消耗和后续使用。consume 操作符在特定位置显式标记值的生命周期的结束，告诉编译器将该位置视为最终使用，从而允许移动操作继续，同时使原始绑定在后续代码中失效。
参数所有权修饰符如何与协议见证表交互，当使用泛型函数与存在类型时，以及什么限制阻止它们在协议要求中使用？
像 borrowing 和 consuming 这样的所有权修饰符完全支持在泛型函数中（例如，func process<T: AudioProtocol>(_ buffer: borrowing T)），编译器在尊重所有权契约的地方生成专门代码或使用见证表。然而，协议要求本身（截至 Swift 5.10）无法在其方法上声明所有权修饰符；你不能写 protocol P { func method(_ x: consuming Self) }，因为存在容器（any P）使用动态调度，目前缺乏区分借用和消费语义的元数据。这迫使开发者在处理仅移动类型或通过所有权优化 ARC 行为时，使用泛型约束（<T: P>），而不是存在类型。