移动应用上线后，崩溃问题往往最先由用户反馈才会被发现，而不是开发团队主动察觉。Firebase Crashlytics 能够自动收集未捕获异常、崩溃堆栈、设备型号、系统版本、启动时间以及自定义日志，但它在默认状态下更像一个被动记录器，不会主动把新出现的崩溃推送给负责人。想要实现分钟级响应，必须完成监控告警配置，让崩溃在爆发初期就进入团队的协作流程。
一、Crashlytics 告警体系与基础概念
Crashlytics 将每一次崩溃归纳为问题，同一个根因的多次崩溃会聚合在同一个问题下。控制台中的核心指标包括事件次数、受影响用户数、无崩溃用户比例和会话数。理解这些指标有助于设置合理的告警条件，避免阈值过低导致通知泛滥，或阈值过高导致严重崩溃被忽略。
Firebase 为 Crashlytics 提供了四类默认告警规则：新问题告警、回归告警、速度告警和稳定性告警。新问题告警在某个问题第一次出现时触发，适合上线新版本后的初期观察；回归告警用于此前已关闭的问题再次出现；速度告警监控单位时间内某个问题的发生频率；稳定性告警则从整体会话角度判断无崩溃用户占比是否低于设定值。
- 新问题告警：首次出现某个聚合问题时发出通知，避免新版本引入未被发现的致命缺陷。
- 回归告警：已标记为关闭的问题再次活跃时触发，提醒团队旧 bug 可能未被彻底修复。
- 速度告警：在短时间窗口内某问题发生次数超过阈值时触发，适合捕获突然爆发的严重崩溃。
- 稳定性告警：当无崩溃会话占比低于配置值时发出警告，用于从整体质量视角监控应用健康度。
这四类告警均可在 Firebase 控制台直接配置，无需额外编码。对于大多数中小团队，先完成这部分配置就能覆盖约八成日常崩溃场景。
二、在 Firebase 控制台配置基础告警
配置入口位于 Firebase 项目控制台的 Crashlytics 页面，点击顶部设置图标后选择通知选项。首次进入时通常为空，需要手动创建规则。创建规则时可以选择应用范围、告警类型、触发条件以及通知渠道。应用范围可以是单个 App 或多个 App，条件可以使用比较运算符和数值阈值。
以速度告警为例，假设每日活跃用户在五万左右，可以设置条件为 10 分钟内同一问题超过 20 次，这样能过滤掉低频偶发崩溃。对于稳定性告警，可以参考历史无崩溃用户比例，例如平时数据为 99.5%，则阈值可设为 99.2%，一旦下降超过 0.3 个百分点就触发通知。阈值设置没有统一标准，需要结合应用体量和历史数据逐步调整。
通知渠道支持邮件、Slack、PagerDuty 和通用 Webhook。邮件配置最简单，适合小团队；Slack 和 PagerDuty 适合已经建立值班体系的技术团队；Webhook 则可以对接企业微信、钉钉或自建告警平台。建议至少同时配置邮件和一个即时通讯渠道，避免单一渠道失效导致漏报。保存规则后，Firebase 会提供发送测试通知的按钮，务必先验证接收端是否可以正常收到消息。
很多团队误以为只要接入 Crashlytics SDK，崩溃后就会自动收到邮件。实际上控制台通知规则是空白的，不配置任何规则就不会有任何主动告警。因此接入 SDK 后要第一时间进入通知设置，根据应用阶段创建至少一条新问题告警和一条稳定性告警。
三、通过 Cloud Functions 实现自定义推送
如果团队使用企业微信、钉钉或内部工单系统，Firebase 内置的通知渠道可能无法直接覆盖。这时可以利用 Cloud Functions 定时任务，将 Crashlytics 数据推送至自定义 Webhook。常用的实现方式有两种：一是开启 Crashlytics 数据导出到 BigQuery，由 Cloud Functions 定时查询新增崩溃记录；二是通过 Crashlytics REST API 拉取问题列表，在本地缓存已通知的问题 ID 后去重推送。
下面以 BigQuery 导出加企业微信机器人为例。Cloud Functions 每五分钟执行一次，查询过去十分钟内首次出现的问题，并调用企业微信机器人的 Webhook 发送文本消息。需要提前在 Firebase 控制台开启 BigQuery 导出，并确认数据集中包含 issue 相关表。
const functions = require('firebase-functions');
const { BigQuery } = require('@google-cloud/bigquery');
const fetch = require('node-fetch');
const bigquery = new BigQuery();
exports.crashlyticsAlert = functions.pubsub
.schedule('every 5 minutes')
.onRun(async (context) => {
const query = `
SELECT issue_id, issue_title, event_count, first_seen
FROM \`your_project.firebase_crashlytics.issue\`
WHERE first_seen > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
ORDER BY first_seen DESC
LIMIT 10
`;
const options = { query };
const [rows] = await bigquery.query(options);
if (rows.length > 0) {
const message = rows.map(row => {
return `问题：${row.issue_title}，次数：${row.event_count}`;
}).join('\n');
await sendToWeCom(message);
}
return null;
});
async function sendToWeCom(text) {
const webhook = 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY';
await fetch(webhook, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
msgtype: 'text',
text: { content: text }
})
});
}
代码中的 BigQuery 数据集名和表名需要根据实际导出配置调整。Cloud Functions 部署时需要开启对应项目的计费计划，并使用具备 BigQuery 读取权限的服务账号。如果不想依赖 BigQuery，也可以使用 Firebase Crashlytics 的 REST API 定时获取问题列表，服务账号需要授予相应权限，并在代码中实现简单的去重缓存，防止同一条崩溃被重复推送。
自定义推送的优势是能够将崩溃告警接入现有值班体系，例如按照严重级别路由到不同群组，或在消息中附带堆栈摘要、影响用户数和版本信息。后续还可以扩展为自动创建 Jira 工单、触发回滚脚本等自动化动作。
四、验证告警与排查漏报
配置完成后需要做一次完整的闭环验证。可以在测试设备上通过调试按钮触发一个必然崩溃的操作，例如故意访问越界数组或强制解包空值。触发后等待几分钟，检查 Firebase 控制台是否生成新问题，再确认邮件、Slack 或企业微信群是否收到对应的告警消息。测试时最好使用真实设备而非模拟器，因为部分崩溃在模拟器上的堆栈和符号化结果会与真机不同。
如果测试后发现控制台有崩溃但通知未送达，常见原因包括：通知规则的应用范围没有覆盖当前测试 App；速度告警的阈值设置过高，测试崩溃次数未达到触发条件；邮件被企业垃圾过滤网关拦截；Webhook 地址失效或密钥错误。对于 Cloud Functions 自定义推送，还需要检查定时任务是否成功部署、服务账号权限是否足够、BigQuery 导出是否开启，以及函数日志中是否出现未捕获异常。
建议为不同严重级别建立差异化告警策略。速度告警的灵敏度和阈值可以针对核心支付、登录等关键流程设置得更严格，稳定性告警作为整体兜底监控，避免某个低频但严重的崩溃被淹没。同时保留邮件作为兜底通知渠道，防止即时通讯渠道因网络或配置问题失效。
Crashlytics 告警只是崩溃治理的起点，收到通知后还需要结合日志、用户操作路径和版本发布记录进行定位。把告警、定位、修复和验证四个环节串联起来，才能有效降低崩溃率，提升应用整体稳定性。
Crashlytics崩溃监控告警配置修改时间：2026-10-04 22:46:22