Swift开发属性观察：让变量变化更可控

Swift开发属性观察：不只是监听值的变化

在写 Swift 项目时，经常会遇到这样的场景：一个用户头像的 URL 地址变了，你得立刻刷新界面；或者某个设置开关从 false 变成 true，后台需要同步更新状态。如果每次都手动去检查、调用方法，代码很快就会变得杂乱，还容易漏掉逻辑。

这时候，Swift 的属性观察就派上用场了。它不像 KVO 那样繁琐，也不需要引入响应式框架，原生支持，干净利落。

willSet 与 didSet 的基本用法

Swift 提供了 willSet 和 didSet 两个钩子，用来监听属性值即将改变和已经改变的时机。比如你有一个用户的积分字段，每次变动时都想记录日志并触发提示：

var userScore: Int = 0 {
    willSet {
        print("积分将从 \(userScore) 变为 \(newValue)")
    }
    didSet {
        if userScore > oldValue {
            showRewardAlert()
        }
    }
}

注意，willSet 拿到的是 newValue，didSet 能访问 oldValue，这两个参数都不用显式声明，直接就能用。而且只有在值真正发生变化时，didSet 才会触发——这点很贴心，避免了无意义的重复操作。

实际应用场景：网络请求的自动刷新

假设你在做一个天气 App，城市名是一个可变属性。每当城市切换，就要发起新的网络请求获取天气数据。以前你可能在每个赋值的地方都手动调 loadWeather()，现在只需要一次 setup：

var cityName: String = "北京" {
    didSet {
        guard cityName != oldValue else { return }
        fetchWeatherData()
    }
}

这样，无论是在搜索框输入、定位切换，还是从历史记录点击进入，只要 cityName 一变，数据自动拉取，界面自然更新。逻辑集中，维护简单。

再进一步，如果你用 Combine 或者 SwiftUI，属性观察还能和 @Published 配合，实现更流畅的数据流控制。但即使不用这些框架，纯 UIKit 项目中，didSet 也能大大减少通知中心或代理的滥用。

小心陷阱：循环引用与过度响应

属性观察虽然方便，但也别滥用。比如在一个 didSet 里又去修改自身属性，很容易造成死循环：

var name: String = "" {
    didSet {
        if name.isEmpty {
            name = "默认用户"  // 这里又触发 didSet
        }
    }
}

这种情况要么加判断条件，要么考虑用闭包解耦逻辑。另外，频繁触发网络请求也得节流，可以结合 DispatchTime 延迟处理，避免用户快速滑动时打爆接口。

属性观察不是万能钥匙，但它确实是 Swift 开发中提升代码整洁度的利器。把变化的响应逻辑收拢到定义处，读代码的人一眼就能看出“这个值变了会干嘛”，比散落在各处的 update 方法清晰多了。