崩溃报告与错误恢复：选择加入的开关与兜底界面

它做什么

两套机制协同工作。第一套是包裹应用各个受保护区域的 React 错误边界。如果该区域内的某个组件在渲染时抛出异常，React 本来会卸载整棵树，留下一个黑窗口；错误边界会捕获它，把错误连同组件栈打到控制台，并在该区域的位置渲染一张卡片。应用的其余部分继续运行：数据流和经纪商连接不受影响。

第二套是崩溃上报器。当错误边界捕获到渲染错误，或者全局处理器在 React 之外看到未处理的 Promise 拒绝或未捕获的错误时，会组装一份报告并发出，但仅限于你已同意的情况。该设置以单个键保存在本机；键不存在即表示未同意。发送是发后不理的：错误界面绝不会因为这个请求而延迟，发送失败也不会弹出任何提示。

设置

报告包含什么

请求体有六个字段：kind（Rust 侧为 panic，React 渲染错误为 render，Promise 拒绝或未捕获错误为 unhandled）、message、stack、appVersion、platform 和时间戳。message 截断到 1 000 个字符，stack 截断到 4 000 个，保留携带信息的顶部栈帧。

在放入请求体之前，message 和 stack 会经过一个脱敏器，它会屏蔽 AI API 密钥、Bearer 与 Basic 令牌、Windows 与 Unix 用户路径（以路径分隔符为界，因此带空格的双词 Windows 账户名不会泄露后半段）、电子邮件地址，以及 password、token、api_key、user_id、unique_user_id、login 或 account 之类的敏感键值对。一个测试用应用错误消息中真实出现的形式固定住了这些模式。经纪商凭据、账户名、持仓、盈亏、交易品种和 AI 密钥从不进入报告。

一个节流机制对每个不同签名（kind 加脱敏后 message 的前 200 个字符）只保留一份报告，每个会话最多五个不同签名，因此每一帧都抛异常的渲染循环不会产生成百上千次请求。

如何使用

• 如果某个界面显示“此界面已停止”，先点“重新加载”。如果再次出现，点“复制详情”，把文本粘贴进“报告问题”界面的报告里，那里也会自动附上最近的错误行。
• 如果你希望渲染错误和未处理错误无需你操作就能送达开发者，请在账户页面开启“崩溃报告”。复选框旁边的标签明确写出了发送什么、不发送什么。
• “报告问题”界面是一个独立的、自愿的渠道，有自己可见的失败提示；崩溃上报器则是按设计自动且静默的。

局限与陷阱

• 错误边界覆盖其区域内的渲染错误。事件回调、定时器和动态导入中的错误由全局处理器捕获，它们会上报但不显示卡片。
• 同意只是本机上的一个本地存储键；全新的配置文件、被清空的存储或应用无法读取的存储，都意味着未同意，因此什么都不会发送。
• 报告发往官方域名，超时 5 秒；如果这台电脑离线，报告会被丢弃，而不是排队等待。