为何Xcode Clean & Build能修复EXC_BAD_ACCESS崩溃？

嘿，我太懂这种困惑了！不管是我自己还是身边好多开发者，都碰到过那种毫无头绪的EXC_BAD_ACCESS崩溃，搜一圈下来，最被推崇的解决方案居然都是“清理项目再重新构建”——而且还真管用！但说实话，之前我也跟你一样好奇：这到底是为啥？为啥清理重建就能搞定这些莫名其妙的问题？

为啥会出现这种“无厘头”的EXC_BAD_ACCESS崩溃？ #

这类崩溃大多跟Xcode的构建缓存或者生成的中间文件出问题脱不了干系，常见的触发场景包括：

• 缓存的旧编译产物和新代码不匹配：比如你修改了类的属性、方法签名，但Xcode的增量构建缓存没同步更新，导致运行时调用了错误的内存布局，直接触发内存访问错误
• 代码索引文件损坏：Xcode的代码索引（Index）一旦出问题，可能会让编译阶段就生成错误的代码，运行时自然就崩了
• 派生数据（Derived Data）残留冲突：比如旧的.framework、.a库文件，或者生成的临时脚本，和当前项目的依赖、代码逻辑冲突
• Xcode自身的版本bug：某些版本的Xcode在处理特定代码结构（比如子视图控制器的属性调用）时，缓存机制会抽风，导致编译出的二进制存在隐性问题

为啥“清理+重建”能解决问题？ #

清理重建本质上是彻底清除Xcode在构建过程中生成的所有临时文件和缓存，强制Xcode从头开始编译整个项目：

• 执行「Clean」会删除当前项目的本地构建产物（比如Build/目录下的所有文件）
• 删除Derived Data则是清除Xcode全局的缓存文件，包括代码索引、中间编译产物、依赖库缓存等
• 重新构建时，Xcode会重新分析所有代码、生成全新的索引、编译每个文件，彻底摆脱旧缓存带来的不匹配问题

比如我自己就碰到过离谱的情况：在viewDidLoad里只是写了super.viewDidLoad()之后调用self.childVC的某个属性，就突然触发EXC_BAD_ACCESS——查遍代码逻辑都没找到问题，结果清理重建之后居然就好了！

说实话，这种“治标不治本”的方案之所以被大家广泛接受，主要是因为排查缓存问题太耗时，而清理重建又快又有效——但要是碰到频繁出现的情况，还是建议检查下Derived Data的存储路径，或者升级Xcode到稳定版本，从根源减少这类问题。

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