H3.14.2reproduction path in error reports设计
上报内容需要包含复现路径而非仅错误堆栈
别名: 复现路径 · breadcrumbs · 不只堆栈
概念解释
堆栈说明代码停在哪一行，不说明人怎么走到那里。上报要带复现路径：最近的界面、动作序列、关键参数的形态（不是原文），好让修复者按用户的任务把失败再走一遍。只有堆栈的上报会变成「已知崩溃、无法复现」。这条管载荷里要有路径，不管发不发送、怎么脱敏。
机制
交互失败多数是状态问题：某一步之后的非法组合、某次导航留下的残值、某个刚关的开关。堆栈停在症状，路径才是病因的候选。面包屑（breadcrumbs）把最近 N 步的界面标识和动作类型按时间排好，修复者才能从任务语言回到代码。版本、设备、语言、实验分组同样是路径的一部分：同名崩溃在旧版与新版可能不是同一条路。没有这些，自动上报只是把「发生过」记下来，不能把「如何再发生」交给下一个人。
边界
路径不是会话录像，更不是输入原文。足够的是界面标识、动作类型、顺序和时间间隔。付费墙后的页面名可以上报，墙里的内容不行。路径过长会变成另一份隐私问题，保留最近一段并在上报时截断。前端框架的组件名对用户无意义，应映射成稳定的界面 ID，否则路径无法跨版本对齐。
怎么落地
- 每条错误事件附带最近若干步的界面 ID 与动作类型、应用版本、设备与语言。
- 不要只存异常类名；没有路径的事件在分流时标为「不可复现」，并优先补采集而不是反复看堆栈。
- 用同一路径在预发环境走一遍作为修复验收，走不出则载荷还不够。
- 验证：拿一条真实上报，不看用户口述，能否独立复现。不能，就还缺路径。