尧图网站建设 
EIP-6963多钱包共存如何实现test-dapp Provider检测机制完整解析【免费下载链接】test-dappThe sample dapp used for e2e testing and metamask-extension QA项目地址: https://gitcode.com/gh_mirrors/te/test-dapptest-dapp 是 MetaMask 官方用于 e2e 测试与 QA 的示例 DApp其中基于EIP-6963实现了多钱包 Provider 检测与共存机制页面上可以同时出现多个钱包用户一键切换当前使用的 Provider。本文将带你完整拆解这套检测机制的实现细节。为什么需要 EIP-6963window.ethereum 的单车道问题在传统方案中所有 EVM 钱包都争抢全局变量window.ethereum同一时间只能有一个钱包占住这个位置。用户如果装了多个钱包DApp 也不知道它们的存在。EIP-6963 通过事件广播解决了这个问题钱包安装后主动向页面举手报名DApp 可以收集所有钱包并让用户自主选择。test-dapp 在 7.3.0 版本正式引入了这套机制见 CHANGELOG 中的记录Implement EIP6963 (Multi) provider detection。核心入口EIP-6963 检测的两个事件名整个机制的核心逻辑集中在 src/index.js 的detectEip6963函数中只需要理解一对事件事件名谁发起作用eip6963:requestProviderDApp 发出向所有钱包喊话有钱包吗请报名eip6963:announceProvider钱包发出钱包响应我来了并附上身份信息流程非常直观DApp 先派发eip6963:requestProvider事件主动请求钱包露面DApp 同时监听eip6963:announceProvider事件每个钱包报名时会携带一个ProviderDetail包含uuid唯一标识、name、icon、rdns以及实际的provider对象页面收到报名后隐藏未检测到 Provider的警告横幅展示钱包列表对应 src/index.html 中的eip6963Warning与eip6963区块。如果一直没有钱包响应页面会持续显示 No EIP-6963 Provider Detected 的提示——这也是 QA 测试时验证钱包是否正确报名的直观依据。Provider 检测四步走从检测到激活第 1 步window.ethereum 兜底页面加载完成后initialize函数会先把window.ethereum当作默认 Provider 激活对应常量WINDOW_ETHEREUM_PROVIDER_UUID window.ethereum保证即使没有 EIP-6963 钱包基础连接功能依然可用。第 2 步按 UUID 去重收集每收到一个ProviderDetail都会先经过existsProviderDetail校验用uuid判断是否已收到过同一个钱包如果同一uuid却带着不同的name/rdns/image会在控制台记录错误防止信息被篡改重复的报名直接忽略新钱包则加入providerDetails列表并触发重新渲染。第 3 步渲染钱包列表renderProviderDetails会为每个钱包生成一张名片卡片展示其info信息并配一个Use xxx按钮点击即切换为该钱包。第 4 步一键切换活跃 ProvidersetActiveProviderDetail是切换的核心它先做严格校验——uuid必须存在、provider.request必须是函数——然后执行三步动作调用closeProvider()彻底清理旧 Provider 的状态与事件监听把新 Provider 写入全局上下文并执行初始化查询eth_chainId、订阅chainChanged/accountsChanged等事件、拉取eth_accounts更新页面右侧的 Active Provider 信息卡片UUID、Name、Icon让用户明确知道现在连的是谁。安全切换的关键closeProvider 如何防止脏状态多钱包共存最容易踩的坑是切换钱包后旧监听器残留导致事件错乱。test-dapp 的closeProvider函数给出了教科书式的答案依次清空账户、网络、链 ID 及所有合约实例移除旧 Provider 上挂载的chainChanged、accountsChanged、networkChanged全部监听器兼容不同钱包的 API 差异优先尝试removeListener不存在则回退到off。这种先拆干净、再装新的模式是任何实现 EIP-6963 切换逻辑时都值得照抄的设计。多渠道共存SDK、WalletConnect、Connect EVM除了浏览器扩展钱包通过 EIP-6963 自动报名test-dapp 还支持三种主动连接方式它们全部走同一套ProviderDetail数据结构实现殊途同归连接方式实现文件Provider 名称MetaMask SDKsrc/connections.jssdk-connectWalletConnect (Web3Modal)src/connections.jswallet-connectConnect EVMsrc/connect-evm.jsconnect-evm以 MetaMask SDK 为例连接成功后handleSdkConnect会用 SDK 返回的 provider 和channelId构造一个ProviderDetail然后调用setActiveProviderDetail激活、handleNewProviderDetail登记入列表。断开时则通过removeProviderDetail从列表移除——如果被移除的正是当前活跃 Provider页面会自动重置表单状态。动手实践在你的 DApp 中实现 EIP-6963综合 test-dapp 的实现落地 EIP-6963 只需记住 5 个关键点发出请求页面加载时派发eip6963:requestProvider事件监听广播监听eip6963:announceProvider收集钱包的ProviderDetailUUID 去重以uuid为唯一键忽略重复报名并校验信息一致性;UI 展示 用户选择渲染钱包列表让用户主动点击使用而不是默认抢占切换即重置切换前移除旧 Provider 的全部事件监听与状态切换后再初始化新 Provider。想要本地跑起来亲手体验可以克隆仓库https://gitcode.com/gh_mirrors/te/test-dapp安装依赖后启动静态服务打开主页面即可看到 Provider 检测区块用多个钱包分别验证报名与切换效果。常见问题 FAQQEIP-6963 钱包和 window.ethereum 会冲突吗不会。test-dapp 的策略是window.ethereum作为默认兜底EIP-6963 钱包报名后以列表形式共存用户可通过 Use window.ethereum 按钮随时切回。Q多个钱包同时报名页面会乱吗不会。每个钱包有独立uuid重复报名被去重逻辑拦截信息不一致会被记录到控制台。Q钱包被移除后当前连接会断吗如果移除的是非活跃 Provider连接不受影响如果是活跃 Provider页面会执行closeProvider清理状态等待用户选择下一个钱包。总结test-dapp 用不到百行的核心代码展示了 EIP-6963 多钱包共存的完整范式事件广播发现钱包 → UUID 去重 → 列表化展示 → 一键安全切换。这套机制不仅是 MetaMask 的 QA 利器也是所有希望多钱包友好的 DApp 可以直接参考的最佳实践。【免费下载链接】test-dappThe sample dapp used for e2e testing and metamask-extension QA项目地址: https://gitcode.com/gh_mirrors/te/test-dapp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-6963多钱包共存如何实现：test-dapp Provider检测机制完整解析
EIP-6963多钱包共存如何实现test-dapp Provider检测机制完整解析【免费下载链接】test-dappThe sample dapp used for e2e testing and metamask-extension QA项目地址: https://gitcode.com/gh_mirrors/te/test-dapptest-dapp 是 MetaMask 官方用于 e2e 测试与 QA 的示例 DApp其中基于EIP-6963实现了多钱包 Provider 检测与共存机制页面上可以同时出现多个钱包用户一键切换当前使用的 Provider。本文将带你完整拆解这套检测机制的实现细节。为什么需要 EIP-6963window.ethereum 的单车道问题在传统方案中所有 EVM 钱包都争抢全局变量window.ethereum同一时间只能有一个钱包占住这个位置。用户如果装了多个钱包DApp 也不知道它们的存在。EIP-6963 通过事件广播解决了这个问题钱包安装后主动向页面举手报名DApp 可以收集所有钱包并让用户自主选择。test-dapp 在 7.3.0 版本正式引入了这套机制见 CHANGELOG 中的记录Implement EIP6963 (Multi) provider detection。核心入口EIP-6963 检测的两个事件名整个机制的核心逻辑集中在 src/index.js 的detectEip6963函数中只需要理解一对事件事件名谁发起作用eip6963:requestProviderDApp 发出向所有钱包喊话有钱包吗请报名eip6963:announceProvider钱包发出钱包响应我来了并附上身份信息流程非常直观DApp 先派发eip6963:requestProvider事件主动请求钱包露面DApp 同时监听eip6963:announceProvider事件每个钱包报名时会携带一个ProviderDetail包含uuid唯一标识、name、icon、rdns以及实际的provider对象页面收到报名后隐藏未检测到 Provider的警告横幅展示钱包列表对应 src/index.html 中的eip6963Warning与eip6963区块。如果一直没有钱包响应页面会持续显示 No EIP-6963 Provider Detected 的提示——这也是 QA 测试时验证钱包是否正确报名的直观依据。Provider 检测四步走从检测到激活第 1 步window.ethereum 兜底页面加载完成后initialize函数会先把window.ethereum当作默认 Provider 激活对应常量WINDOW_ETHEREUM_PROVIDER_UUID window.ethereum保证即使没有 EIP-6963 钱包基础连接功能依然可用。第 2 步按 UUID 去重收集每收到一个ProviderDetail都会先经过existsProviderDetail校验用uuid判断是否已收到过同一个钱包如果同一uuid却带着不同的name/rdns/image会在控制台记录错误防止信息被篡改重复的报名直接忽略新钱包则加入providerDetails列表并触发重新渲染。第 3 步渲染钱包列表renderProviderDetails会为每个钱包生成一张名片卡片展示其info信息并配一个Use xxx按钮点击即切换为该钱包。第 4 步一键切换活跃 ProvidersetActiveProviderDetail是切换的核心它先做严格校验——uuid必须存在、provider.request必须是函数——然后执行三步动作调用closeProvider()彻底清理旧 Provider 的状态与事件监听把新 Provider 写入全局上下文并执行初始化查询eth_chainId、订阅chainChanged/accountsChanged等事件、拉取eth_accounts更新页面右侧的 Active Provider 信息卡片UUID、Name、Icon让用户明确知道现在连的是谁。安全切换的关键closeProvider 如何防止脏状态多钱包共存最容易踩的坑是切换钱包后旧监听器残留导致事件错乱。test-dapp 的closeProvider函数给出了教科书式的答案依次清空账户、网络、链 ID 及所有合约实例移除旧 Provider 上挂载的chainChanged、accountsChanged、networkChanged全部监听器兼容不同钱包的 API 差异优先尝试removeListener不存在则回退到off。这种先拆干净、再装新的模式是任何实现 EIP-6963 切换逻辑时都值得照抄的设计。多渠道共存SDK、WalletConnect、Connect EVM除了浏览器扩展钱包通过 EIP-6963 自动报名test-dapp 还支持三种主动连接方式它们全部走同一套ProviderDetail数据结构实现殊途同归连接方式实现文件Provider 名称MetaMask SDKsrc/connections.jssdk-connectWalletConnect (Web3Modal)src/connections.jswallet-connectConnect EVMsrc/connect-evm.jsconnect-evm以 MetaMask SDK 为例连接成功后handleSdkConnect会用 SDK 返回的 provider 和channelId构造一个ProviderDetail然后调用setActiveProviderDetail激活、handleNewProviderDetail登记入列表。断开时则通过removeProviderDetail从列表移除——如果被移除的正是当前活跃 Provider页面会自动重置表单状态。动手实践在你的 DApp 中实现 EIP-6963综合 test-dapp 的实现落地 EIP-6963 只需记住 5 个关键点发出请求页面加载时派发eip6963:requestProvider事件监听广播监听eip6963:announceProvider收集钱包的ProviderDetailUUID 去重以uuid为唯一键忽略重复报名并校验信息一致性;UI 展示 用户选择渲染钱包列表让用户主动点击使用而不是默认抢占切换即重置切换前移除旧 Provider 的全部事件监听与状态切换后再初始化新 Provider。想要本地跑起来亲手体验可以克隆仓库https://gitcode.com/gh_mirrors/te/test-dapp安装依赖后启动静态服务打开主页面即可看到 Provider 检测区块用多个钱包分别验证报名与切换效果。常见问题 FAQQEIP-6963 钱包和 window.ethereum 会冲突吗不会。test-dapp 的策略是window.ethereum作为默认兜底EIP-6963 钱包报名后以列表形式共存用户可通过 Use window.ethereum 按钮随时切回。Q多个钱包同时报名页面会乱吗不会。每个钱包有独立uuid重复报名被去重逻辑拦截信息不一致会被记录到控制台。Q钱包被移除后当前连接会断吗如果移除的是非活跃 Provider连接不受影响如果是活跃 Provider页面会执行closeProvider清理状态等待用户选择下一个钱包。总结test-dapp 用不到百行的核心代码展示了 EIP-6963 多钱包共存的完整范式事件广播发现钱包 → UUID 去重 → 列表化展示 → 一键安全切换。这套机制不仅是 MetaMask 的 QA 利器也是所有希望多钱包友好的 DApp 可以直接参考的最佳实践。【免费下载链接】test-dappThe sample dapp used for e2e testing and metamask-extension QA项目地址: https://gitcode.com/gh_mirrors/te/test-dapp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考