使用火基（Firebase）SDK 的开发者在突发事件管理方面比火基团队更有能力。没错，这本就是火基应该做到的，可他们的状态页面却显示无任何事件！！哪怕已经过了 5 小时，此处依旧如此。火基团队宛如小丑，抱歉但确为事实。

在使用 Firebase SDK 的开发者，在事故管理方面比 Firebase 团队更能干。没错，这本就是 Firebase 该做的事。可他们的状态页面至今没有显示任何事故！！已经过去 5 个小时了，还是这样。

Firebase 团队的小丑——抱歉，但这是实话。

讨论围绕着一次 Firebase iOS SDK 引发的线上崩溃事故展开，气氛偏批评：多数人认为这不是孤例，而是第三方依赖加远程配置的结构性隐患，并顺带质疑 Firebase 本身的处境；少数人则把矛头对准开发者自己盲目打包依赖、以及用 AI/agent 写码却不读代码的风气。

认为固定版本根本挡不住这类事故

• 问题不在依赖版本，而在配置由对方服务器下发，锁死版本号照样中招（较多人） > 就算你把版本钉死也没用，因为配置是从他们服务器来的。（@hnisjafx40）
• 有人在当天只看到一堆 App 莫名闪退，事后才知道原因，侧面说明影响面很广（较多人）

认为这是老问题，早就发生过

• 2020 年 Facebook SDK 出过几乎一模一样的事故，因此这次不该被当作意外（较多人） > 完全一样的事情 2020 年就在 Facebook SDK 上发生过。（@jaen）
• 一句话点出「这不是第一次了」，暗示同类风险一直没被行业解决（较多人）

认为该反思的是开发者自己

• 与其质问「他们怎么能这样对我们」，不如问问有多少人真的读过自己塞进所有 App 里的第三方代码，这暴露了移动开发的整体状态（较多人） > 我听到的都是「他们怎么能这样对我们」，却几乎没人说「也许我们该读一读打包进全部 App 的那堆第三方代码」。（@Skwid）
• 反讽式的追问：难道就没有任何办法避免吗——言下之意办法明明存在（较多人）
• 第三方依赖确实带来巨大便利，所以这种吸引力可以理解，但这次正体现了它的阴暗面（少数人）

认为 Firebase 正在衰退，且与 GCP 拼接生硬

• 从早年做 Android 推送通知时就接触 Firebase，被收购后膨胀成完整开发平台，如今感觉被冷落、与 GCP 的整合也很生硬；这次事故加深了「它在走下坡」的判断（少数人） > 我还有些生产 App 跑在它上面，这类新闻让我更确信它在衰退。（@alex_suzuki）
• 同一人顺势发问：现在有什么开源、可自托管的替代方案，尤其是能覆盖 Firestore 离线同步场景的（少数人）

把责任归给 AI 写码与工程师降级

• 继续「凭感觉写码」就会继续搞崩一切；所有人类工程师被降级成实习生水平，用 agent 把坏更新推上生产，还搞不清自己在做什么，这次可别赖到 Claude 头上（少数人） > 越把编码全部外包给 agent、越不再读代码，这类事故就会越多，而且会加速，因为隐藏的错误会不断累积。（@elzbardico）

用玩笑表达情绪

• 至少 Google 工程师还会反转二叉树；以及「他们能救别人免于崩溃，却救不了自己」这类讽刺（少数人）

有价值的补充

• 事故的官方 issue 已在 firebase-ios-sdk 仓库中被标记为 resolved，回复里直接给了链接。
• 版本锁定失效的机制值得记住：SDK 的行为可能由服务端下发的配置决定，因此依赖管理只能冻结本地代码，冻结不了远端行为。
• 把这次事件和 2020 年 Facebook SDK 事故对照，可以看出移动端 SDK 的「远端开关」是一个反复出现、且单靠开发者侧无法完全防御的故障面。