iOS 11.3中WKWebview调用getAllCookies仅TestFlight/Fabric构建崩溃

我之前在项目迁移到WKWebView时也碰到过几乎一模一样的问题——本地Xcode运行不管Debug还是Release都好好的，一上TestFlight就崩在getAllCookies:调用上。结合你的场景，主要有几个可能的原因和对应的解决方案：

1. 回调线程非主线程导致的崩溃 #

WKHTTPCookieStore的getAllCookies:回调默认是在后台线程执行的，如果你的后续逻辑涉及UI操作、访问线程不安全的自有存储（比如非线程安全的单例存储类），就很容易触发崩溃。而Xcode直接运行时可能因为调试环境的线程保护机制没暴露这个问题，但TestFlight的Release构建会把这个问题放大。

解决办法很简单，把回调里的逻辑切回主线程：

- (void)cookiesDidChangeInCookieStore:(WKHTTPCookieStore *)cookieStore {
    [cookieStore getAllCookies:^(NSArray* cookies) {
        // 切到主线程处理存储更新
        dispatch_async(dispatch_get_main_queue(), ^{
            // 这里执行你的自有存储更新逻辑
            NSLog(@"获取到Cookie数量：%lu", (unsigned long)cookies.count);
        });
    }];
}

2. 监听器未及时移除导致野指针崩溃 #

如果你的控制器被释放了，但WKHTTPCookieStore的监听器还没移除，后续触发cookiesDidChangeInCookieStore:时，self已经是野指针，调用getAllCookies:就会崩溃。本地调试时可能因为内存回收机制的差异没触发，但TestFlight的Release构建会更快回收内存。

记得在控制器销毁时移除监听器：

- (void)dealloc {
    if (@available(iOS 11.0, *)) {
        [[WKHTTPCookieStore sharedHTTPCookieStore] removeObserver:self];
    }
}

注意要适配iOS版本，WKHTTPCookieStore的监听是iOS 11才引入的。

3. 构建配置差异导致的优化问题 #

TestFlight的Archive构建默认开启了更激进的编译器优化（比如-O2），可能会把一些隐式的内存问题放大。你可以尝试在Archive构建中临时开启调试选项来定位问题：

• 在Xcode的Build Settings里，把Enable Zombie Objects设为YES（仅用于调试，上线前要改回来）
• 利用你已经在用的Fabric收集符号化的崩溃栈，看崩溃具体是在getAllCookies:的调用还是回调里，以及对应的调用栈信息，这样能更精准定位。

额外建议 #

如果以上方法都没解决，你可以在TestFlight版本中添加详细的日志，比如在cookiesDidChangeInCookieStore:开头和getAllCookies:回调里打日志，确认崩溃发生的时机，以及cookieStore对象是否有效。

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