连接失败的错误分流与文案

30 秒回答

wagmi 官方文档把 hook 的 error 定义为强类型对象，并建议用 name 判别；文档示例给出了 HttpRequestError 与 LimitExceededRpcError 两类失败。useConnect 是 mutation，文档说明其 retry 默认为 0，status 取值包含 pending 与 error。因此连接失败可以按类型分流：传输与限流分别处理，用户在钱包里取消属于可重试的正常操作。实现差异与工程取舍见深入回答。

深入回答

• 【实现行为】useConnect 是 mutation，retry 默认为 0，status 取值为 idle、pending、error、success（依据：wagmi useConnect §mutation 的 retry、§Return Type 的 status）。
• 【实现行为】hook 的 error 是强类型对象，文档建议用 name 判别，示例包括 HttpRequestError 与 LimitExceededRpcError（依据：wagmi 错误处理指南 §Error Handling）。
• 【实现行为】useConnect 的 mutate 变量包含 connector，也可以传 chainId 与 withCapabilities（依据：wagmi useConnect §mutate 的 variables）。
• 【实现行为】文档提示：并非每个 connector 都支持连接时指定 chainId，不支持时以钱包当前链为准（依据：wagmi useConnect 页面末尾的 TIP）。
• 【工程经验】用户在钱包里取消属于正常操作，静默回到可重试状态即可，不要弹红色错误（工程经验，无规范依据）。
• 【工程经验】把失败拆成可观察的类别：用户取消、传输失败、限流、connector 未就绪与目标链不受支持，再为每类定义文案与重试策略（工程经验，无规范依据）。
• 【工程经验】重试按类型区分：对用户取消不自动重试，对限流降低频率，对传输失败使用有限次退避（工程经验，无规范依据）。
• 【工程经验】isPending 期间锁定按钮，避免连点触发重复请求（依据：wagmi useConnect §Return Type 的 isPending；工程经验）。
• 【工程经验】日志保留错误类型与必要上下文，同时脱敏 RPC URL、地址与请求参数（工程经验，无规范依据）。

常见错误

• 各类失败都显示「连接失败，请重试」（【工程经验】）。
• 对用户取消显示红色错误并自动重试（【工程经验】）。
• 无视 retry 默认值，在 mutation 上直接打开重试（【实现行为】useConnect 的 retry 默认为 0；依据：wagmi useConnect §retry）。
• 假定传入 chainId 会在每个 connector 上生效（【实现行为】文档提示部分 connector 不支持连接时指定链；依据：wagmi useConnect 页面 tip）。
• 日志原样记录 RPC URL 与请求参数（【工程经验】）。

面试官追问

1. 用户取消连接后，按钮与提示应该怎样恢复？
2. 限流导致的连接失败与网络不可用如何区分？
3. 重试策略配置在 mutation 上，还是由业务层控制，取舍是什么？
4. connector 不支持指定 chainId 时，界面如何处理链不一致？
5. 连接失败的日志要记录到什么粒度？

评分标准

初级回答

• 知道 connection 失败的错误是结构化对象，可以按类型区分。
• 知道用户取消与系统故障要分开处理。

中级回答

• 能为不同失败类型设计文案与重试策略。
• 能说明 retry 默认值与按钮 pending 状态的配合方式。

高级回答

• 能设计连接失败的分流表，覆盖链不一致与 connector 未就绪等边界。
• 能说明日志粒度、脱敏要求与回归验证方式。

参考资料

• wagmi：错误处理指南（§Error Handling）
• wagmi：useConnect（§mutation 的 retry、§Return Type 的 status）