firebase-ios-sdk

此崩溃（EXC_BAD_ACCESS / KERN_INVALID_ADDRESS，发生在由 +[GULNetworkURLSession setSessionInFetcherMap:forSessionID:] 调用的 -[NSConcreteMapTable setObject:forKey:] 中）是 GoogleUtilities 8.1.0 及更早版本中的一个已知 bug（跟踪编号为 GoogleUtilities#228）。该问题已在 GoogleUtilities 8.1.1 中修复，并在 8.1.5 之前持续进行了强化。由于 Firebase 12.14.0 仅要求 GoogleUtilities ~> 8.1，CocoaPods 可能会在你的 Podfile.lock 中一直锁定 8.1.0。请检查你的 Podfile.lock 中的 GoogleUtilities 版本，然后运行：pod update GoogleUtilities 以拉取 8.1.1 或更高版本（推荐 8.1.5），然后重新构建。

当流式 callable 函数空闲超过 30 秒时会出现此错误。firebase-functions（v7.x）会在 30 秒无活动后发送一行 SSE 注释（: ping）作为心跳（默认 heartbeatSeconds: 30），但 Firebase iOS SDK 在 Functions.swift 中的解析器只接受以 data: 开头的行，遇到其他任何内容都会抛出 FunctionsError(.dataLoss)。

解决方法：在 Cloud Function 的 CallableOptions 中禁用或调大心跳间隔：

import { onCall } from 'firebase-functions/v2/https';

export const slow = onCall({ heartbeatSeconds: null }, async (req, res) => {
  await new Promise((r) => setTimeout(r, 40_000));
  res.sendChunk('hello');
  return 'done';
});

或者，将 heartbeatSeconds 设置为大于函数最长预期空闲时间的值（例如 heartbeatSeconds: 60）。注意：禁用心跳可能会导致中间代理或负载均衡器关闭长时间空闲的连接。Node 客户端和 Web SDK 能够正确处理 : ping 注释；要永久修复，需要 iOS SDK 按照 SSE 规范跳过 SSE 注释行。

在 FirebaseDataConnect（11.12.6 及更早版本，包括 main @ be6a46f）中，Timestamp.init(from:) 使用一个仅检查格式（^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}...）而不检查取值范围的正则表达式来验证字符串，随后强制执行 try! Google_Protobuf_Timestamp(jsonString:)。格式匹配但取值超出范围的字符串——例如 "2026-13-01T00:00:00Z"（月份 13）、"2026-01-01T24:00:00Z"（小时 24）、"0000-01-01T00:00:00Z"（年份 0）——能够通过该正则表达式，但会抛出 SwiftProtobuf.JSONDecodingError.malformedTimestamp，而 try! 会导致进程崩溃。由于 AnyCodableValue.init(from:) 会对每个 JSON 字符串首先尝试按 Timestamp 解析，任何持有此类值的 GraphQL String 或 Any/JSON 字段都会触发崩溃——包括首次获取数据时客户端缓存 dehydration（脱水）期间，因此该查询每次运行都会重现崩溃。修复方法：在 CodableTimestamp.swift（约第 61-62 行）中，将 init(from:) 内的 try! 替换为 try——该初始化器本身就会抛出错误，这样 AnyCodableValue 会通过其现有的 try? 回退到 .string，而按实际的 Timestamp 解码时则会抛出 DataConnectCodecError。包含测试的 PR 已在 firebase/data-connect-ios-sdk#123 上开放；待其合并并发布后，请更新 SDK。在此之前，请对数据进行清洗，确保超出范围的类日期值永远不会匹配该时间戳正则表达式（例如更改存储格式），并注意：对于 Any/JSON 字段，禁用客户端缓存并不能完全避免崩溃。

这是 Firebase iOS SDK 11.0.0 至 13.1.0 版本中的一个已知 bug（由 Auth 的 Swift 重写引入的回归问题）。addIDTokenDidChangeListener(_:) 会将监听器闭包存入 listenerHandles，但 removeStateDidChangeListener(_:)、removeIDTokenDidChangeListener(_:) 和 deinit 却试图从该数组中移除观察者 *handle*。由于 handle 永远无法与已存储的闭包匹配，移除操作就成了空操作：你添加的每个监听器（以及它所捕获的一切）都会在 Auth 实例的整个生命周期内一直存活——而对于 Auth.auth() 而言，这相当于整个 App 会话期。反复添加/移除监听器（例如按页面或按响应式订阅）会导致内存无限制地泄漏。

**修复方法：**升级到 Firebase iOS SDK 13.2.0 或更高版本，修复（存储观察者 handle 而非闭包）已合并到该版本中。

**旧版本的临时解决方案：**在监听器闭包内部使用弱引用捕获状态，使被保留的闭包不会让其他对象保持存活：

let handle = Auth.auth().addStateDidChangeListener { [weak self] _, user in
    guard let self = self else { return }
    // 处理认证状态变化
}

Firestore 在 Objective-C 中校验文档路径并抛出 NSException(FIRInvalidArgumentException),而 Swift 的 do-catch 无法拦截它——因此应用总是会在输入无效时崩溃。唯一可靠的修复方法是在调用 document(id) 之前自行校验/清理 ID。文档 ID 不得包含 /,不得为 . 或 ..,必须非空,且必须 ≤1500 字节。

先进行校验:

func isValidDocumentID(_ id: String) -> Bool {
    return !id.isEmpty
        && !id.contains("/")
        && id != "." && id != ".."
        && id.utf8.count <= 1500
}

guard isValidDocumentID(id) else { return /* reject or transform */ }
let docRef = db.collection(recipeShareCollection).document(id)

针对 URL 的更好做法:永远不要将原始 URL 用作文档 ID,而是对其进行哈希处理:

import CryptoKit
let docID = SHA256.hash(data: Data(urlString.utf8))
    .map { String(format: "%02x", $0) }.joined()
let docRef = db.collection(recipeShareCollection).document(docID)