Swift不可变数组元素替换：Copy与Map方案对比及运行机制差异

嘿，这个问题问得挺到位的——我刚好对Swift数组的这类不可变操作有过不少实践，咱们来好好拆解下这两种方案的区别～

哪个方案更优？ #

结论先给你：绝大多数场景下，Copy方案的表现要优于Map方案，尤其是当数组元素数量较多或者元素是值类型的时候。

为什么这么说？咱们从实际运行的开销来看：

• Copy方案依赖Swift数组的**写时复制（COW）**机制，复制数组的操作是底层高效的内存块拷贝，而且只有当你真正修改元素时才会触发实际的内存复制，没有额外的闭包调用开销。
• Map方案需要遍历数组的每一个元素，还要对每个元素执行一次索引判断的闭包逻辑，闭包调用本身就有一定的性能损耗，数组越大，这种损耗越明显。

当然，如果你的数组特别小（比如只有几个元素），两者的性能差异几乎可以忽略，这时候选哪个就看你更喜欢哪种代码风格了。

运行机制的核心差异 #

Copy方案的底层逻辑 #

extension Array {
    func replacingItem(at index: Int, with item: Element) -> Array {
        precondition(index < self.count)
        var copy = self
        copy[index] = item
        return copy
    }
}

• 第一步的precondition是为了提前拦截越界操作，避免运行时崩溃。
• var copy = self：因为Array是值类型，这里并不会立刻复制整个数组的内存——Swift会让copy和原数组共享同一块存储空间，直到你对copy进行修改。
• copy[index] = item：这一步触发了写时复制，系统会分配新的内存块，把原数组的所有元素拷贝过去，然后修改指定索引位置的元素，最后返回这个新数组。

Map方案的底层逻辑 #

extension Array {
    func replacingItem(at index: Int, with item: Element) -> Array {
        precondition(index < self.count)
        return self.enumerated().map { $0.offset == index ? item : $0.element }
    }
}

• 同样先做索引合法性检查。
• self.enumerated()会生成一个包含每个元素索引和值的序列，相当于把原数组转换成了(offset: Int, element: Element)的序列。
• map方法会遍历这个序列的每一个元素，对每个元素执行闭包里的判断：如果索引匹配就返回新元素，否则返回原元素。
• 最后map会把所有处理后的元素收集起来，创建并返回一个新的数组。

额外补充：适用场景 #

• 如果只是单纯替换单个元素，优先选Copy方案，性能更好。
• 如果替换元素的同时，还需要对其他元素做一些统一变换（比如把非目标索引的元素都转成大写），那Map方案会更简洁，不用先复制再遍历修改。

内容的提问来源于stack exchange，提问作者XmasRights