去中心化应用经常需要你在特定链上操作。与其让你手动打开钱包的网络下拉菜单，dapp 可以直接发起一个切换请求，钱包弹出”确定要切换到某链吗”的确认框——这个动作的标准名是 EIP-3326 定义的 wallet_switchEthereumChain。规范本身非常短，但它确立的几个概念构成了多链钱包交互的地基。
活动链：一个必须存在的前提
规范假定钱包有一个”活动链”概念，定义为钱包当前转发 RPC 请求的目标链。所有读余额、发交易的动作都打到这条链上。方法接受的对象参数只有一个字段：chainId，十六进制字符串，含义与 EIP-695 时代就存在的 eth_chainId 一致。三条拒绝义务直接从这里派生：目标链必须是钱包已知的链——钱包没法切到一条自己没登记的链；钱包必须确实具备切过去并向其转发请求的能力；如果钱包压根没有”活动链”这种设计（比如每个应用各连各的节点、互不串线的架构），它必须拒绝这个请求。成功时方法返回 null，失败返回错误。
为什么不携带链参数
与 EIP-3085 的添加请求形成鲜明对照，切换方法刻意拒绝携带 RPC 地址、链名、图标、货币符号等任何元数据。规范的设计理由写得很直白：这条方法只关心”把活动链换过去”这一件事，端点和其他信息以钱包自己登记过的版本为准。这个取舍有明确的防御意图——若切换请求能顺带改写链配置，等于给钓鱼开了后门：弹窗说去 A 链，配置却被同时换成恶意端点。把添加与切换拆成两个方法后，改写配置必经添加流程的完整校验，包括用 eth_chainId 实测端点这一步。两份规范都属于接口类别，当前状态同为 Stagnant，文本停滞但方法被主流钱包长期实现。
弹窗为什么不能省
规范的安全考量部分把话说得很重：如果活动链在用户没有察觉的情况下被切换，dapp 就能诱导用户在错误的链上执行签名——同一段授权在两条链上的语义可能完全不同。因此规范建议钱包在收到切换请求时展示确认界面，清楚地标明请求方身份与目标链，并参考 EIP-1102 的请求确认样式来消歧。也就是说，任何静默切换的实现都不符合规范的预期；用户在实践中也应把”来源标识”当作弹窗里最重要的信息来读，而不是只看链名。
与相邻机制的分工
一条完整的多链接入流程由三个环节拼成：wallet_switchEthereumChain 负责换链，wallet_addEthereumChain 负责登记新链，eth_chainId 负责让 dapp 查清钱包当前到底停在哪条链上。三者各司其职。排查”页面显示的网络和我想的不一样”这类问题时，顺序应当是先查当前活动链，再查目标链是否已被钱包登记，最后才轮到发起切换或添加请求，顺序颠倒会让弹窗越点越乱。
安全提示
切换弹窗是钓鱼者常态化利用的位置。值得养成的习惯有三条：确认框出现时先看请求方域名是否是你正在使用的应用；核对目标链 ID 与该链公开文档一致；对”先切到某链再回来”的连环请求保持警惕，因为每一次切换都意味着后续签名可能落在另一条链上。本文只解释接口规范，不构成投资建议，各钱包的具体提示样式以官方文档为准。
错误语义与钱包侧的兜底
规范对失败情形只笼统要求返回错误，但生态在长期使用中形成了事实上的错误码习惯：请求参数不合规范归为无效输入一类错误，用户点拒绝归为用户拒绝类错误，目标链未被登记则常以类似 4902 的自定义码返回，提示 dapp “这条链钱包里没有，请先走添加流程”。对 dapp 开发者，正确的处理链是：切换失败且链未知时，先发起添加请求，成功后再试一次切换；对”用户拒绝”则不应连环重发，那只会把弹窗变成骚扰。对普通用户，识别 4902 式弹窗同样有用——它意味着你正要被带往一条钱包从未见过的链，即使弹窗措辞多么温和，添加环节的核验义务都不应被催促语略过。
这套方法还预设了钱包必须展示确认界面的立场，与 EIP-1102 确立的”授权暴露账户需要用户确认”的传统一脉相承：凡是会改变后续签名语境的 RPC 请求，都不允许静默完成。回看这条规范诞生于 2021 年、当年即完成的背景，多链体验从”手动改配置”进化到”点一下弹窗”，正是这一小段文本与 EIP-3085、EIP-695 的分工配合的结果。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。