DApp 集成钱包：连接、签名与链切换

一句话结论

DApp 与浏览器钱包之间的事实标准是 EIP-1193 定义的注入提供者：钱包把一个提供者对象挂到页面上，DApp 通过统一的「请求」接口与它对话，而不是针对某个具体钱包写死代码。

提供者模型长什么样

EIP-1193 约定了提供者的最小接口：一个统一的方法用来发起请求，请求里带上方法名与参数，例如「请求账户」「请求签名」「请求发送交易」。这个模型的好处是：

• 钱包可替换：只要实现了同一套约定，DApp 不需要为每个钱包写一套适配。
• 职责清晰：钱包负责私钥、签名和广播，DApp 只负责组装意图和展示状态。
• 能力可探测：DApp 可以先问提供者支持哪些能力，再决定走哪条路径。

要注意提供者是注入到页面的全局对象，可能不存在。用户没装钱包、用的是手机浏览器、或者装了多个钱包争抢同一个全局对象，都会让连接失败。所以必须准备回退方案：引导用户去钱包的内置浏览器打开，或明确提示安装。

三种一定会遇到的状态

用户拒绝签名。这是正常操作，不是异常。把它当报错抛出，会让用户以为 DApp 坏了。

链不对。DApp 需要的链与用户当前所在链不一致时，要么引导用户切换，要么请求添加该网络。切换失败时要给出可复制的网络参数作为兜底。

会话中被改变。提供者会在账户切换、链切换时发出事件通知。不监听这些事件的 DApp，界面会长期停留在一个已经不存在的账户上。

签名该怎么设计

请求连接只代表用户交出了地址，不代表授权动他的资产——这一点用户常常误解，DApp 的文案要主动澄清。需要授权时，额度按需给，不要默认无限。需要用户签名时，能用 EIP-712 这类结构化签名就不要让用户盲签一串十六进制：用户能读懂自己在确认什么，才是最有效的防线。

给你的教训

• 不要把「用户拒绝」当异常，按取消处理，不弹错误弹窗、不重复弹窗。
• 连接后立刻监听账户与链的变化，随时同步界面状态。
• 每次签名都要说清签的是什么、会不会动资产，含糊的文案终会反噬信任。
• 把提供者能力当成「可能不存在」，未安装钱包、移动端、多钱包冲突都要有明确路径。

延伸阅读

• 认识 DApp 授权与额度
• 给钱包添加自定义网络
• 钱包基础认知