H3.14.1automatic client error reporting设计研究
客户端错误需要自动上报以便发现用户未主动反馈的问题
别名: 自动上报 · crash reporting · 未反馈的错误
概念解释
多数失败不会变成工单。人重试、离开、或以为是自己的问题。客户端错误自动上报把这些没说出口的失败送到产品能看见的地方，否则恢复体系只优化了会投诉的那一小撮。这条只管「要自动送到」，不管上报里有没有复现路径、频率如何告警、内容怎么脱敏。
机制
反馈有成本：要描述、要找到入口、还要承认自己碰上了问题。成本高于当场重试时，失败在产品侧的计数是零。自动上报把计数从自愿改成发生即记录，诊断才能对准真实分布而不是健谈用户的分布。上报发生在错误表面出现时或捕获到未处理异常时，不依赖人再点「告诉开发者」。自愿开关可以存在，但默认关上等于选择看不见。没有这条管道，预防和文案的改动会围着工单转，而工单不是抽样。
怎么研究
对比「仅工单」「自动上报」「上报且可选择附加说明」，看同一时期内捕获的独特失败种类。
自变量：是否自动发送、是否默认开启、附加说明是否可选。 因变量：独特错误种类数、与工单重叠率、从未出现在工单里的失败占比。
不要用实验室里被要求「请报告问题」的被试当主样本。真正要看的是无人提醒时有多少失败被记下。
边界
用户明确退出诊断、或所在司法区要求选择加入时，不能偷偷开。企业设备可能由组织策略强制开或强制关，应用要服从并在关于页写明。仅在开发构建里打日志、生产关闭，等于生产用户的失败仍不可见。敏感会话（银行、医疗）的上报仍应发生，但载荷要按脱敏规则走，不能因为场景敏感就整段关掉。
怎么落地
- 在错误被用户看见或未捕获异常发生时发送一条事件，不额外要人点按钮。
- 默认开启诊断，设置里提供退出；退出后本地仍可看自己的失败记录。
- 把上报量与工单量并排看：只出现在上报里的种类，进入修复队列时不要等投诉。
- 验证：人为制造一种不会提示「请反馈」的失败，看远端是否在约定时间内出现事件。没有事件，自动上报就还没接上这条用户路径。