SwiftUI使用onChange更新@StateObject参数的合理性及更优方案

你当前的实现是完全合理可运行的，没有逻辑错误，通过onChange监听url变化同步给ImageLoader的思路完全符合SwiftUI的状态管理规则，而且你额外加了loader.url != newValue的判断避免重复触发加载，这个细节处理得很到位。
不过当前实现存在两个可以优化的小问题：

• onAppear和onChange的逻辑存在重复触发的可能性，虽然你加了判重不会产生实际问题，但代码可以更精简
• 你实现了Equatable协议但仅比较url，如果业务中存在placeholder变化也需要更新视图的场景，需要补充placeholder的比较逻辑，否则修改placeholder不会触发视图重绘

根据你的部署目标不同，可以选择更简洁的实现方式：

方案1：使用task(id:) 修饰符（iOS 15+ 推荐） #

直接替换掉原有onAppear和onChange两个修饰符，代码更精简，同时自带任务生命周期管理：当url发生变化时，自动取消上一次未完成的图片加载任务，避免旧请求返回后覆盖新url对应的图片，非常适合异步资源加载的场景。
示例代码修改点：

// 删掉原有.onAppear和.onChange块，添加以下修饰符
.task(id: url) {
    guard let url = url, loader.url != url else { return }
    loader.url = url
    // 如果你的ImageLoader的load方法是async的，直接在这里调用await loader.load()即可
}

方案2：使用带initial参数的onChange（iOS 17+） #

如果不想改动现有异步加载逻辑，可以用带初始执行参数的onChange直接合并onAppear的逻辑，减少冗余代码：

// 删掉原有.onAppear块，修改onChange为以下实现
.onChange(of: url, initial: true) { oldValue, newValue in
    guard loader.url != newValue else { return }
    loader.url = newValue
}

方案3：兼容iOS13/14的最优实现 #

如果你需要支持更低的系统版本，你当前的onAppear+onChange的实现已经是最优方案，只需要保留现有逻辑即可，不需要额外修改。

• 可以给ImageLoader增加请求去重、内存/磁盘缓存的逻辑，避免同一个url重复发起网络请求，提升加载性能
• 如果业务不需要高度自定义AsyncImage的实现，iOS15+可以直接使用系统自带的AsyncImage组件，不需要自己维护加载逻辑

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