Swift中用闭包包裹函数作为参数是否存在性能开销？

在Swift里，我们经常利用“函数可以作为参数传给接受闭包的函数”这个特性简化代码，比如用reduce求和时直接传+，代码非常清爽：

let values = 0 ..< 10
let sum = values.reduce(0, +)

但遇到重载的运算符（比如+支持Int、Double等多种类型），Swift的类型推断就会因为无法确定具体用哪个版本而报错——就像你写的castAndCombine函数，直接传+会编译失败：

func castAndCombine<T, U>(_ pair: (Any, Any), with fn: (T, T) -> U) -> U? {
    guard let first = pair.0 as? T, let second = pair.1 as? T else { return nil }
    return fn(first, second)
}
// 编译报错：无法推断出T和U的具体类型，导致+的重载版本不明确
let x = castAndCombine((1, 2), with: +)

你提到了两种解决思路，我们来拆解下，重点说说你关心的性能问题：

方案1：新增参数消除歧义 #

给函数添加一个toType参数，明确指定泛型T的类型，这样Swift就能精准匹配对应的+重载了：

func castAndCombine<T, U>(_ pair: (Any, Any), toType: T.Type, with fn: (T, T) -> U) -> U? {
    guard let first = pair.0 as? T, let second = pair.1 as? T else { return nil }
    return fn(first, second)
}
let x = castAndCombine((1, 2), toType: Int.self, with: +)

正如你所说，这个方案确实不够优雅，多出来的参数破坏了原函数的简洁性，用起来有点生硬，算不上理想的解决方案。

方案2：带显式类型注解的闭包包裹 #

保留原函数的签名，把+放进一个显式标注参数类型的闭包里，直接告诉Swift我们要使用Int版本的+：

func castAndCombine<T, U>(_ pair: (Any, Any), with fn: (T, T) -> U) -> U? {
    guard let first = pair.0 as? T, let second = pair.1 as? T else { return nil }
    return fn(first, second)
}
let x = castAndCombine((1, 2), with: { (a: Int, b: Int) in a + b })

关于这个方案的性能开销疑问 #

完全不用顾虑！Swift编译器的优化能力很强——在Release模式（开启优化）下，它会自动识别这种“单纯包裹函数的闭包”，做函数内联和闭包消除优化。简单来说，编译器会直接把闭包的逻辑替换成直接调用Int.+的代码，和你能直接传+（如果类型推断没问题的话）的执行效率完全一致。

就算是在Debug模式下，可能会有极细微的调试相关开销，但这只会影响开发阶段的运行速度，对发布后的App性能没有任何可感知的影响。所以这个方案既能保持函数签名的简洁，又不会带来性能负担，完全可以放心使用。

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