一个全局变量引发的排队
多数浏览器钱包向网页交付能力的方式，是往页面里注入一个全局对象 window.ethereum。单机时代这很顺手，但装第二个钱包扩展的那天问题就出现了：两个扩展注入的是同一个名字，后加载的把先加载的盖掉，网页”自动检测”到的往往是运气好的那个。用户侧的症状是：点了连接钱包，弹出来的却是你没打算用的那家，全程没有任何报错。这类”连错钱包、签错字”事故的根源不在钓鱼，而在 2016 年起沿用的单对象约定。2022 年 10 月 4 日提交的 EIP-5749 是对这个约定的一次正面修补，作者 MyEtherWallet 创始人 Kosala Hemachandra，提案状态已是 Final。
从单槽位到注册表
5749 的核心动作只有一步：把全局对象换成 window.evmproviders——一个把所有在场钱包登记进去的集合。每个钱包入驻时带一份资料卡：一个 UUIDv4 形式的唯一编号、显示名称、一张 base64 编码的 SVG 图标、一句描述，规范把这四个字段定义为只读。网页不再猜”现在这个 ethereum 是谁”，而是遍历注册表，把发现的钱包列成菜单让用户点。提案同时建议逐步废弃 window.ethereum，但兼容性一节写得很克制：新约定不要求踢掉旧对象，因此不会直接破坏现有应用；真正会破坏旧应用的”最终替换”只是建议的远期方向——这也解释了为什么现实中两个对象长期并存。
uuid 的两条规则值得单独看
规范对编号定了两条容易忽略的规则：同一个钱包在不同版本之间 UUID 必须保持不变，但在不同发行渠道之间必须不同。前半句让网页可以把”你上次用过 MetaMask”这类偏好安全地记在编号上，升级换版本不会误伤；后半句针对的是同类产品的分身——同一团队的扩展版与移动版、稳定渠道与测试渠道，必须是不同身份，否则网页端的选择记录会串门。这是接口规范里少见的、直接为”用户装了同名不同源的多个扩展”做防混淆设计的条款，比任何”认准官方”的文字提醒都更结构化。
它与 网页怎么在一堆钱包扩展里找对的那个：EIP-6963 与多钱包共存 是同一问题的两种答案
处理多钱包冲突还有一条更晚也更主流的路线：EIP-6963 的事件广播——每个钱包派发标准的公告事件，网页监听汇总。两条路线解决同一个”谁在场”的问题，差别在推拉方向：5749 是网页主动遍历注册表，6963 是钱包主动喊话。现实中钱包普遍双轨兼容，网页开发者则大多按 6963 的标准做选择菜单，5749 更多出现在”为什么旧站点偶尔连错钱包”的解释里。对普通用户，值得记住的结论没变：连接钱包前核对弹窗里的钱包名称与站点域名，任何自动检测出来的默认选项都不值得信任。
边界：注册表防不了假冒
要把 5749 的防线性质量说清楚：它解决的是”误连”，不是”假冒”。资料卡上的名称、图标、描述全部由钱包自报，恶意扩展完全可以填一个知名品牌名混进注册表——SVG 图标甚至可以做到肉眼难辨。注册表带来的真正收益是行为可预期：选择动作可见、每个钱包有稳定编号，事后审计和偏好记忆有了抓手，但识别责任仍然在人。配合钱包侧的域名展示与签名前的模拟预览（各产品能力以官网当期说明为准），才是完整的防线。一个自查小技巧：在新版浏览器里打开装了两个以上钱包的环境，看站点是否给出钱包列表让你选；列表菜单是这些标准落地后最直观的肉眼信号。风险提示：本文讲解浏览器接口机制，不构成投资建议；扩展安装请一律走官方渠道。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。