Firebase Crashlytics崩溃标签判定逻辑及参考资料咨询

下面是这些自动标签的实际运行逻辑（基于社区验证和实际使用总结，官方文档未明确公开细节）：

Early crashes #

• 核心特征：用户启动App后极短时间内触发的崩溃，直接影响新用户第一体验
• 计算逻辑：Crashlytics追踪崩溃发生时的App启动时长，通常以启动后30秒内为阈值；另外用户首次安装App后的第一次启动就崩溃，也会被归为这类
• 优先级：极高，直接决定新用户是否留存

Repetitive crashes #

• 核心特征：同一个用户多次触发完全相同的崩溃
• 计算逻辑：基于Crashlytics的崩溃签名分组规则，同一设备/用户ID在24小时内触发同一签名的崩溃≥2次，就会被标记
• 优先级：高，说明崩溃会持续干扰用户的正常使用，极易引发用户投诉或卸载

Regression issue #

• 核心特征：之前已经被你手动标记为「已修复」的崩溃，在新版本中再次出现
• 计算逻辑：Crashlytics会关联你在控制台的崩溃修复记录，当相同签名的崩溃在后续发布的版本中重新被检测到，自动打上该标签
• 优先级：极高，属于修复不彻底或新版本引入的回退问题，必须优先排查

Fresh issue #

• 核心特征：最近才出现的全新崩溃，此前从未被Crashlytics记录过
• 计算逻辑：当某个崩溃签名首次被捕获，且出现时间在最近7天内，就会被标记为Fresh issue
• 优先级：中高，先统计该崩溃影响的用户数、崩溃频率，再决定处理顺序

筛选与优先级建议 #

1. 最紧急：Early crashes + Regression issue 组合，既影响新用户又属于修复复发的问题
2. 次紧急：单独的Early crashes，直接关系新用户留存
3. 高优先级：Repetitive crashes，持续影响活跃用户体验
4. 按需处理：Fresh issue，先评估影响范围再安排排期

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