Swift属性观察者didSet与willSet的适用场景辨析

嘿，这个问题问得特别到位——很多刚上手Swift属性观察者的开发者都会有这个疑惑：明明两者都能拿到新旧值，那为啥要分两个？其实核心区别就在于执行时机，而这个时机直接决定了它们各自的适用场景！

先把最关键的执行时机明确下来：

• willSet：在属性值即将被更新，但还没完成更新时触发。此时属性本身存储的还是旧值，newValue参数是即将要设置的新值。
• didSet：在属性值已经完成更新后触发。此时属性本身存储的是新值，oldValue参数是更新前的旧值。

接下来用具体场景帮你区分：

什么时候用willSet？ #

willSet的核心是「前置操作」——利用旧值还存在的时机，做一些需要在新值生效前完成的事情：

1. 清理旧资源/状态 #

比如切换网络会话、断开旧的连接时，在新会话生效前关闭旧的：

var activeNetworkSession: NetworkSession? {
    willSet {
        // 此时activeNetworkSession还是旧的会话，直接关闭即可
        activeNetworkSession?.disconnect()
    }
}

如果放到didSet里，activeNetworkSession已经是新会话了，旧会话只能通过oldValue获取，虽然也能实现，但willSet里直接用属性本身更直观，逻辑上也更顺——毕竟是在切换前清理旧资源。

2. 记录「即将发生的变更」用于审计/日志 #

比如需要记录某个属性的变更意图（哪怕后续变更可能被拦截）：

var userPrivilege: PrivilegeLevel {
    willSet {
        AuditLogger.log("用户权限即将从\(userPrivilege)变更为\(newValue)")
    }
    // 假设后续有自定义setter可能拦截非法变更
    set {
        if newValue.rawValue > currentUser.maxAllowedPrivilege.rawValue {
            return
        }
        self._userPrivilege = newValue
    }
}

这里用willSet就能完整记录所有变更尝试，哪怕最终变更没成功，日志也能保留下来。

什么时候用didSet？ #

didSet的核心是「后置操作」——只有当值确实更新完成后，才需要执行的依赖操作：

1. 更新UI或通知外部观察者 #

这是最常见的场景：属性值变化后，立即同步更新界面或通知其他组件：

var currentUserName: String {
    didSet {
        // 用户名已经更新，直接刷新界面上的标签
        userNameLabel.text = currentUserName
        // 通知数据中心同步更新用户信息
        UserDataCenter.shared.notifyUserNameChanged(currentUserName)
    }
}

如果在willSet里做这些操作，万一后续赋值失败（比如自定义setter里的校验不通过），UI就会显示错误的内容，逻辑完全不合理。

2. 基于新值触发后续业务逻辑 #

比如温度变化后触发警报、库存变化后触发补货提醒：

var warehouseStock: Int {
    didSet {
        // 只有库存确实低于阈值时，才触发补货请求
        if warehouseStock < 10 && warehouseStock != oldValue {
            InventoryAPI.sendRestockRequest(warehouseStock)
        }
    }
}

这里用didSet能确保只有当库存真正变化到符合条件的状态时，才执行后续请求，避免了willSet里可能出现的「变更未生效就触发操作」的问题。

最后再总结一下 #

• 如果你需要在值改变前处理旧状态、做前置准备/记录，选willSet
• 如果你需要在值改变后基于新状态更新依赖、触发业务逻辑，选didSet

虽然从获取值的角度看两者有重叠，但执行时机的差异才是它们分工的核心——选对时机，代码逻辑会更清晰、更可靠！

内容的提问来源于stack exchange，提问作者r.pul