wallet_addEthereumChain调用报错 网络已切换但错误无法捕获

错误日志参考：

这个未捕获错误不是wallet_addEthereumChain RPC调用本身返回的失败，而是ethers.js v5版本的provider内部机制抛出的网络状态异常：

• 发起RPC调用时，provider内部缓存的当前网络为链ID 137的Polygon主网（matic）
• MetaMask侧完成网络切换后，provider检测到实际连接的链变成了链ID 80001的Mumbai测试网（maticmum）
• ethers v5的provider默认会持续校验底层连接的网络和自身缓存的网络状态是否一致，一旦检测到不匹配，就会抛出code为NETWORK_ERROR的异常，这个异常的触发时机是MetaMask推送chainChanged事件给provider的时刻，和你发起wallet_addEthereumChain调用的RPC请求流程是相互独立的。

观察到MetaMask已经完成网络切换是符合预期的——因为RPC请求本身确实被钱包正常处理了，报错只是provider层的状态校验提示，不代表切换操作失败。

包裹provider.send()的try/catch只能捕获这个send调用对应Promise链上抛出的异常：

• 当MetaMask成功处理完添加/切换网络的请求后，会给provider.send()返回正常的resolve结果，这个调用本身没有触发reject，自然不会走到写好的catch分支。
• 上述网络校验错误是provider在内部独立的异步监听/轮询逻辑里抛出的，没有挂载到send调用的Promise链上，所以外层的try/catch根本无法捕获到这个独立抛出的异常，最终就会变成控制台里的未捕获Promise错误。

• 初始化provider后主动注册network事件监听器，接管网络变更的处理逻辑，从根源避免未捕获错误：

// 初始化provider之后立即添加监听
provider.on('network', (newNetwork, oldNetwork) => {
  // 这里写网络切换后的业务逻辑，比如更新当前链状态、重新初始化合约实例等
})

• 校验networkMaps中目标链的参数配置，重点核对chainId的十六进制值是否和目标链完全匹配：从错误日志看，切换前后的链ID分别是137和80001，如果预期切换的目标不是80001测试网，说明参数里的chainId配置有误。
• 优化网络切换逻辑：优先调用wallet_switchEthereumChain发起切换，只有当钱包返回chain not added类错误时，再调用wallet_addEthereumChain添加链后重试切换，不要直接用add接口承担切换逻辑，减少参数不匹配导致的状态不一致问题。
• 如果不需要ethers的内置轮询校验，可以在初始化provider时关闭轮询配置减少不必要的校验触发（非首选方案，优先推荐用事件监听处理）：

const provider = new ethers.providers.Web3Provider(window.ethereum, {
  polling: false
})

内容的提问来源于stack exchange，提问作者strangeQuirks