能判断这是新版本回归，也知道该从哪个业务帧修。
先看见结账崩溃，再把 32 次同类错误收成一张 Issue
左边是炸掉的支付页，右边是错误追踪。接入聚合后，刷屏变成一张带版本的 Issue；拿掉 release，卡片会标「缺版本」。
第 0 步 · 打开工具先打开错误追踪后台的 Issues。线上 SDK 会在崩溃后自动上报，本地可用开发者工具对照栈
夏季衬衫 × 1¥ 269
!
支付崩溃 · TypeError用户停在支付按钮，同一 TypeError 还在发生
Issues
32 条刷屏- TypeError · 刚刚
- TypeError · 1 分钟前
- TypeError · 2 分钟前
- + 29 条相同错误
错误追踪把同根因异常聚成可处理的 Issue。计数、版本和业务帧长在卡片上；缺 release 就要补版本再判断。
知识点：先聚合和分诊，再修
上面的工作台已经演示了核心关系，这里只给可复用的命名。
- 同一指纹的异常要收成一张 Issue，而不是 32 条闹钟。
- release 和首个业务帧决定「新回归还是旧问题」。
- 先看影响范围，再选择修复或回滚；Issue 卡不是术语的全部。
什么时候用、怎么用
生产崩溃、同类错误刷屏，或你需要按版本判断回归时用错误追踪。
- 入口：打开错误追踪后台的 Issues；本地用开发者工具对照同一栈。
- 最短路径：触发/等待上报 → 看聚合计数 → 读 release 与业务帧 → 决定修或回滚。
- 不要只盯最新一条；没有版本就无法判断是不是这次发布引入。
正反例：同一 TypeError，只改有没有聚合并挂版本
目标都是处理结账崩溃。差别在于你面对的是 32 条噪音，还是一张可分诊的 Issue。
值班只能一条条点；没有版本就无法决定回滚还是继续观察。
快速自测
结账页同一 TypeError 报了 32 次。你打开追踪后台时，最先该确认什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。