一条通道完成连接：ERC-7846 的 wallet_connect 把授权与登录合成一次弹窗

一个方法替代一串握手

网页要接进你的钱包，过去通常是好几段动作拼起来的：先请求看地址，如果网站还想让你登录，再单独发一条签名消息，有些钱包的附加功能还要各自协商。钱包接口标准 ERC-7846 提出一个名为 wallet_connect 的方法，目标很直接：把连接、身份验证和可选能力收进一次请求。它是一份 ERC，按仓库标注状态为草案（Draft），2024 年提出，尚未成为全行业必须实现的规则，读它时请把它当作一种正在演进的接口设计，而不是你钱包里已经保证存在的功能。

请求和返回里各有什么

按原文的参数结构，wallet_connect 的请求带一个版本号，外加一个可选的 capabilities 字段，网站想顺带办的事写在这里。规范示例里最常见的是登录场景：capabilities 里放入 signInWithEthereum，附上随机数 nonce 和链标识 chainId。返回则是一个 accounts 列表，每个条目包含地址，以及这次连接被授予的能力结果——登录场景下会带回待签的原文消息和签名字段。也就是说，网站一次问完，钱包一次答完，中间不用再来回三趟。

顺带说明示例里的链标识写法：0x1 是十六进制表示，换算成十进制就是我们熟悉的主网链号 1。这类写法在钱包接口里到处都是，看到 0x 前缀先做进制换算再下判断，是排查连接问题时最省时间的一招。

登出也是一等公民

这份 ERC 同时定义了 wallet_disconnect。原文用 SHOULD 表述：钱包在收到登出后，应当撤销该连接关联的账户信息访问权，以及连接时一并授予的能力。规范语言里的 SHOULD 是应当而非必须，意味着允许实现有出入。对你的实际意义是：在网站上点断开并不天然等于一切权限归零，断开之后还要按老规矩去检查代币授权和已连接站点清单，这部分盘查方法可以参考 钱包连接过的网站清单怎么清：断开连接和撤销授权是两件事，两件事各有各的入口，谁也不能替谁收尾。

一次弹窗的代价与好处

对普通用户，最直观的差别是弹窗数量。过去连接加登录会出现两次甚至更多次弹窗，每一次都是一次独立的核对机会，也每一次都是一次被打断的注意力消耗。合并成一次之后，你在同一个窗口里要同时看清三件事：这是哪个网站、它要哪个地址、它顺带要签什么。原文把签名原文放进返回值而不是替你预先消化，所以核对消息正文的责任仍然在用户侧——登录消息里通常有域名、随机数和有效期，随机数用来防重放，这些字段的分工可以参考 怎么证明地址是你的？消息签名验证工具的使用与边界 一类签名验证话题里的解释。

弹窗合并不等于风险合并。判断标准仍然是老三样：域名是否逐字符正确、请求的能力是否最小必要、消息正文有没有超出登录用途的内容。任何一次签名请求，只要内容超出你的预期，拒绝的代价只是这次操作没办成，而批准的代价可能是长期的。

实现差异与现状边界

草案阶段的现实是：有的钱包可能完整实现两个方法，有的只实现连接的合并，有的完全没有跟进，网站也往往同时保留旧通道兜底。你不需要为了判断某家钱包是否支持它去读代码，更实用的观察方法是看连接流程本身：如果连接和登录被压缩进一个弹窗、断开入口改名或合并，那多半与这类新接口有关；如果仍然是两三次弹窗，那是旧通道在工作。无论哪套接口在底下跑，链上行为没有区别——连接本身不发交易、不花手续费，这一点从旧的注入式接口到 wallet_connect 都没有变过。

还要划清一条边界：这套标准管的是身份和能力的握手，不碰资产动用的那一步。真要转资产、改授权，永远走的是交易签名那条通道，不会被 wallet_connect 顺带完成。如果哪天某个网站声称连接弹窗里就能把币转走，那本身就是反常信号，应当直接拒绝并复核域名。

风险提示

本文只解释接口标准机制，不构成任何投资建议或产品推荐。草案类标准可能被修改、合并或放弃，各钱包实现进度不一，任何以某接口为名诱导你输入助记词、私钥或授权全部资产的说法都不可信；签名请求请逐项核对内容后再决定是否批准。