iOS开发：设置NSAttributedString触发EXC_BAD_ACCESS错误如何解决？

首先，EXC_BAD_ACCESS 本质是内存访问错误——你的代码尝试访问了一块已经被释放、或者不属于当前进程的内存地址。结合你提到的「直接设置text正常，设置attributedText就崩溃」的现象，大概率是以下几个原因之一：

1. fourthString 存在内存野指针问题 #

虽然直接赋值text时看起来正常，但这可能是UIKit内部对字符串做了额外的内存处理（比如自动拷贝了一份）。而创建NSAttributedString时，会直接引用fourthString的原始指针，如果这个字符串已经被提前释放（比如是栈上的临时对象、或者没有用strong属性正确持有），就会触发崩溃。

你可以先做个快速验证：把fourthString替换成硬编码的@"测试文本"，如果崩溃消失，那百分百是fourthString的内存生命周期出了问题。接下来要检查：

• 它是不是异步回调里的局部变量？
• 有没有用strong修饰的属性来持有它？

2. NSStrokeWidthAttributeName 的值存在异常 #

你用的@-2.0本身是合法的（负数值表示同时显示填充色和描边），但如果这个NSNumber对象的内存被篡改、或者是意外创建在栈上的非法实例，也可能导致崩溃。可以临时替换成[NSNumber numberWithFloat:-2.0]试试，看是否解决问题。

3. label1 本身的内存状态异常 #

虽然设置text正常，但设置attributedText会触发Label更多的布局和渲染逻辑。如果label1已经被释放（比如是一个被移除父视图且没有strong引用的对象），或者它的内部状态被篡改，就可能在更复杂的操作中暴露问题。

你可以在设置attributedText前加一句断言排查：

NSAssert(self.label1 != nil, @"label1 已被释放或未初始化！");

如果触发断言，说明你需要检查label1的引用关系。

4. 非主线程操作UI引发的内存异常 #

UIKit的所有UI操作必须在主线程执行，有时候在子线程设置text不会立刻崩溃，但设置attributedText涉及更复杂的属性解析和渲染，更容易触发内存错误。你可以确认代码是否在主线程运行，或者直接把代码包进主线程队列：

dispatch_async(dispatch_get_main_queue(), ^{
    self.label1.attributedText = [[NSAttributedString alloc] initWithString:fourthString attributes:@{NSStrokeColorAttributeName:[UIColor blackColor],NSForegroundColorAttributeName:[UIColor whiteColor],NSStrokeWidthAttributeName:@-2.0}];
});

快速排查工具推荐 #

用Xcode的Zombies工具（路径：Product > Profile > Zombies）可以精准追踪到哪个对象被重复访问，帮你快速定位内存问题的根源。

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