答案。

问题的背景：

@autoclosure 是 Swift 中的一个特殊修饰符，允许自动从作为函数参数传递的表达式创建闭包。它首次出现是为了简化语法，提高撰写 assert/guard 表达式和延迟计算值时的可读性。

问题：

标准的闭包需要显式的语法 ({ ... })。当逻辑简单时（例如，在惰性检查中），这往往显得多余。但是，如果使用 autoclosure，开发者可能会不知不觉地改变代码的执行时机或失去表达式的副作用值。此外，autoclosure 不接受参数。

解决方案：

@autoclosure 允许以简洁的方式编写代码：

代码示例：

func logIfTrue(_ predicate: @autoclosure () -> Bool) {
    if predicate() {
        print("条件满足")
    }
}

// 没有 autoclosure：
logIfTrue({ 2 > 1 })
// 使用 autoclosure：
logIfTrue(2 > 1)

关键特点：

@autoclosure 允许将表达式的计算延迟 到函数调用时
@autoclosure 可以与 @escaping 结合使用 以适应异步场景
提高接口的可读性，向 API 用户隐藏闭包的语法

具有陷阱的问题。

autoclosure 可以接受参数吗？

不能。Autoclosure 始终是无上下文的：接受 0 个参数，并只是“包装”表达式。

类型 () -> T 和 @autoclosure () -> T 之间有什么区别？

普通闭包需要显式语法——autoclosure 允许传递表达式，而不需要用花括号包围，这对函数接口有显著影响。

如果 autoclosure 具有副作用，会发生什么？

autoclosure 只在调用时计算——如果表达式执行了副作用，它会严格在调用时发生，而不是在将参数传递给函数时。

var x = 5
func change(_ value: @autoclosure () -> Int) {
    print(value())
}
change(x += 1) // x 只会在这里增加

常见错误和反模式

不理解表达式不会立即执行（惰性行为）
将 autoclosure 与期望立即执行的副作用表达式一起使用
在未显式指明 @escaping 的情况下将 autoclosure 传递到逃逸上下文中

实际案例

负面案例

在实施错误分析时，使用 autoclosure 的函数写入消息。但是消息表达式具有副作用（发送网络请求），因此实际执行的顺序并不是开发人员所期望的。这导致统计数据收集不正确。

优点：

语法简短且表达力强

缺点：

副作用执行的时机不明显
调试困难

正面案例

在 assert 方法中使用 autoclosure，只有在需要时才计算表达式，或者简化终端用户 API 的语法。代码变得更简洁，副作用不存在。