WalletConnect/web3modal 项目中登录后签名操作失效的技术分析

问题背景

在WalletConnect/web3modal项目的实际应用中发现了一个值得注意的技术问题：当用户通过电子邮件或社交账号登录后，签名操作(signMessage)会出现异常失效的情况。这个问题在钱包登录方式下表现正常，但在非钱包登录方式(如电子邮件、GitHub、Google等)下出现概率较高，大约有80%的复现率。

问题现象

1. 首次登录行为：用户首次登录时，签名模态框会正常显示，等待用户点击"签名"按钮完成整个认证流程。登出功能也表现正常。

2. 二次登录异常：当用户尝试再次连接时，签名模态框会快速闪现后自动关闭，控制台会显示以下错误信息：

   Error: Request was aborted
   Error: Internal error: User denied account access
   

3. 智能账户默认问题：即使用户在配置中明确设置了defaultAccountTypes: { eip155: 'eoa' }，系统仍然会默认连接智能账户而非外部拥有账户(EOA)。

技术分析

签名流程异常

从技术实现角度看，问题可能出在以下几个环节：

1. 状态同步问题：当使用电子邮件或社交账号登录时，前端状态(isConnected)与实际连接状态可能存在不同步现象。在钱包登录方式下，一旦Reown模态框打开，isConnected就会立即变为true，即使用户尚未完成钱包连接。这种状态管理机制可能在非钱包登录方式下产生了副作用。

2. 签名请求时机：当前实现中，签名请求是通过useEffect钩子在检测到isConnected状态变化后立即触发的。这种设计在快速状态变更场景下可能导致竞争条件，特别是在非钱包登录流程中，后端连接可能尚未完全建立时就触发了签名请求。

3. 账户类型处理：系统未能正确处理defaultAccountTypes配置，始终优先选择智能账户而非配置的EOA账户，这表明在账户类型选择逻辑上存在缺陷。

解决方案探讨

1. 状态管理改进：需要确保所有登录方式下的连接状态同步机制一致。可以考虑引入额外的状态检查，确保只有在后端连接完全建立后才触发签名请求。

2. 签名请求优化：对于自动签名场景，建议增加重试机制和超时处理，避免因瞬时状态不一致导致的操作失败。

3. 账户类型选择：需要检查账户类型选择逻辑，确保配置参数能够正确覆盖默认行为。特别是在混合账户环境(同时支持EOA和智能账户)中，类型选择应该更加明确和可靠。

开发者建议

1. 临时解决方案：在等待官方修复的同时，开发者可以考虑：

   • 为签名操作添加手动触发机制，而非自动触发
   • 增加错误处理和重试逻辑
   • 明确验证连接状态后再执行签名操作

2. 版本选择：虽然问题在1.7.2版本声称已修复，但实际测试表明问题仍然存在。建议开发者密切关注后续版本更新。

3. 测试策略：由于问题不是100%复现，建议在测试阶段对电子邮件/社交登录流程进行充分测试，确保各种边界条件下的稳定性。

总结

WalletConnect/web3modal作为重要的Web3连接解决方案，其稳定性和可靠性对DApp开发至关重要。这个特定的签名问题揭示了在混合认证场景下状态管理和流程控制方面的挑战。开发者在使用时需要特别注意非钱包登录方式的兼容性测试，同时关注项目的官方更新以获取最终解决方案。