iOS开发中调用set方法报错，常见原因有哪些？

在iOS开发中,“set方法报错”是一个让许多开发者，尤其是初学者感到困惑的问题，它通常不会直接指向someProperty = newValue这行代码本身有语法错误，而是暗示在属性赋值这一行为的背后，隐藏着更深层次的逻辑问题，如内存管理、线程安全或对象生命周期等，这类错误往往以崩溃的形式出现，并伴随着令人费解的异常信息，本文将深入剖析iOS中set方法报错的常见原因，并提供一套行之有效的调试策略与最佳实践，帮助开发者快速定位并解决这类棘手问题。

---

常见原因深度剖析

“set方法报错”只是一个表象，其根源多种多样，以下是最常见的几种情况：

KVO (Key-Value Observing) 相关错误

这是最经典也最臭名昭著的“set方法报错”来源，当某个对象A注册为对象B的属性的观察者后，一旦对象B的属性被修改（即调用其setter方法），对象A就会收到通知，如果对象A在被通知之前已经被释放（deallocated），而它又没有正确地移除观察者，系统就会尝试向一个不存在的对象发送消息，从而导致崩溃。

典型崩溃信息：

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7f8b1c404560 of class MyClass was deallocated while key value observers were still registered with it. Current observation info: <NSKeyValueObservationInfo 0x600003f4c200> (
<NSKeyValueObservance 0x600003f4c140: Observer: 0x7f8b1c404560, Key path: someProperty, Options: <New: YES, Old: NO, Prior: NO> Context: 0x0, Property: 0x7f8b1c4041a0>
)'

这个错误信息非常明确地指出：一个MyClass的实例在KVO观察者仍然注册的情况下被释放了。

错误示范：

class ObserverClass: NSObject {
    var observedObject: ObservedClass?
    func startObserving() {
        observedObject = ObservedClass()
        observedObject?.addObserver(self, forKeyPath: "someProperty", options: .new, context: nil)
    }
    // 如果没有在deinit中移除观察者，当ObserverClass实例被释放时就会崩溃
    // deinit {
    //     observedObject?.removeObserver(self, forKeyPath: "someProperty")
    // }
}

线程安全问题

在iOS中,所有UI相关的操作都必须在主线程上执行，如果你在后台线程中试图修改一个UI控件的属性（例如UILabel.text、UIView.backgroundColor等），虽然setter方法本身可能不会立即崩溃，但这种操作是未定义行为，它可能会导致UI绘制异常、数据竞争，或者在稍后的某个时间点，当主线程试图访问这个被非主线程修改的UI属性时引发崩溃。

错误示范：

DispatchQueue.global().async {
    // 错误：在后台线程更新UI
    self.myLabel.text = "Updated from background"
}

正确做法：

DispatchQueue.global().async {
    let newText = "Data fetched from network"
    DispatchQueue.main.async {
        // 正确：切换回主线程更新UI
        self.myLabel.text = newText
    }
}

Core Data 关系设置错误

在使用Core Data时，设置一个被管理对象的关联关系（relationship）也可能引发问题，你试图将一个属性设置为一个不属于同一个NSManagedObjectContext的对象，或者违反了在数据模型中定义的删除规则（如“级联删除”、“拒绝删除”等），Core Data会在你调用setter方法时进行校验，一旦发现数据不一致或违反规则，就会抛出异常。

didSet 与 willSet 观察器中的逻辑错误

Swift的属性观察器didSet和willSet为我们提供了在属性值变化前后执行自定义代码的机会，如果这些观察器内部的代码存在缺陷，比如强制解包一个为nil的可选值，或者访问了一个已经被释放的资源，那么错误就会在属性赋值时被触发。

错误示范：

var someOptionalProperty: String? {
    didSet {
        // 如果oldValue为nil，这里会崩溃
        print("Old value was: (oldValue!)") 
    }
}

---

调试策略与最佳实践

面对“set方法报错”，系统性的调试方法至关重要。

精读崩溃日志

崩溃日志是你的第一手资料,重点关注Exception Type和Exception Reason，对于KVO错误，Reason会明确指出哪个类的哪个实例出了问题，对于其他错误，堆栈跟踪（Stack Trace）会告诉你崩溃发生时完整的函数调用链，帮助你定位到出错的setter方法。

启用“异常断点”

这是调试此类问题的“核武器”，在Xcode中，开启异常断点可以让程序在抛出任何异常的瞬间暂停，而不是等到程序崩溃才停止，这样你就能直接查看导致异常的代码行以及当时的变量状态。

设置方法：

1. 打开断点导航器（快捷键⌘8）。
2. 点击左下角的号。
3. 选择“Exception Breakpoint…”。
4. 在弹出的窗口中保持默认设置,直接点击“Done”。

当set方法报错时,程序会自动停在出错的那一行，极大地方便了问题排查。

使用“僵尸对象”模式

当怀疑是内存管理问题（尤其是KVO）时，可以开启Zombies模式，这个工具不会真正释放被废弃的对象，而是将其标记为“僵尸”，当有代码试图访问这个僵尸对象时，程序会立即中断，并告诉你具体是哪段代码“复活”了本该逝去的对象。

注意： Zombies模式只能在模拟器中使用，且会消耗大量内存，不建议一直开启。

代码审查与规范

预防胜于治疗,遵循良好的编码规范可以从源头避免很多问题。

• KVO配对原则：addObserver和removeObserver必须成对出现，并且通常在deinit中执行移除操作，确保对象生命周期结束时清理干净。
• 主线程更新UI：将“更新UI必须在主线程”作为铁律，可以使用DispatchQueue.main.async来确保线程安全。
• ：在didSet中处理逻辑时，充分考虑各种边界情况，特别是可选值的处理。

---

问题类型与解决方案速查表

错误类型	典型症状	核心解决方案
KVO相关	崩溃日志提示was deallocated while key value observers were still registered	在观察者的deinit中移除KVO观察者。
线程安全	UI更新不及时、UI错乱、随机崩溃，且崩溃堆栈可能指向UIKit内部方法	确保所有UI属性的set操作都在主线程执行。
Core Data	设置关系属性时崩溃，日志提示数据模型验证失败	确保关联对象来自同一个上下文，并遵守删除规则。
didSet逻辑错误	属性赋值后立即崩溃，堆栈指向didSet内部代码	检查didSet中的逻辑，特别是强制解包和对已释放资源的访问。

---

相关问答FAQs

Q1: 我的代码非常简单，就是一行 self.view.backgroundColor = .red，为什么在某个控制器中会随机崩溃？

A: 这极有可能是线程安全问题，虽然这行代码本身看起来无害，但如果它是在一个后台队列或回调中被执行的，你就违反了UIKit的主线程规则，系统可能不会在赋值的那一刻崩溃，但当渲染服务在主线程尝试读取这个被非主线程修改的视图层属性时，就会因为数据竞争而崩溃，请立即检查这行代码的调用上下文，并用DispatchQueue.main.async将其包裹起来，确保其在主线程执行。

Q2: 我已经非常确定在 deinit 里移除了 KVO 观察者，为什么还是偶尔会报 was deallocated while key value observers were still registered 的错误？

A: 这个问题的发生通常意味着观察者本身在被观察者之前被意外释放了，你将一个视图控制器作为观察者去观察一个单例对象的属性，当这个视图控制器被pop或dismiss后，它正常进入deinit并移除了观察者，一切正常，但如果这个单例对象的生命周期非常长，而你的视图控制器因为某些原因（如循环引用）没有被释放，那么当它最终被释放时，如果它所观察的单例对象已经不存在了，或者观察者列表已经被破坏，就可能出错，更常见的情况是，你注册了观察者，但被观察者对象本身先于观察者被释放了，此时如果代码逻辑中仍有地方试图修改被释放对象的属性，就会触发这个异常，请使用异常断点和僵尸对象工具来精确定位是哪个对象的生命周期管理出了问题。