用 ENS 名字访问过站点的人，对”名字换地址”很熟悉；ERC-6860 把同样的思路搬到了合约调用上：一条 web3:// 开头的链接，理论上可以像网址一样直接打开一个合约的功能页面。这一篇讲它的翻译机制、和已有标准的关系，以及今天拿它交互前该守的边界。
一条 URL 怎么变成合约调用
按 ERC-6860 的定义，Web3 URL 的骨架是 web3://合约名或地址[:链id]/方法名/参数。浏览器或钱包拿到这条 URL 后做三步翻译：先用 ERC-6821 规则把 *.eth 这样的域名解析成合约地址（名字换地址这一步和 ENS 网站重定向同源，机制见 web3 网址里的 ENS 名字：ERC-6821 怎么把域名换成合约）；再检查合约声明的解析模式——合约要提供一个 resolveMode 方法，返回”manual”表示由合约自己决定返回什么内容，返回”auto”表示由协议把方法调用的原始返回值自动包装成页面；最后把路径与方法名拼成调用数据发给合约。URL 里不带链 id 时，默认落到名字服务的主链（以太坊主网用 1）。
关键分工：合约自己出页面
manual 模式是这个标准最有想象力的地方：合约返回的是一段自描述内容（可带 HTML 的 MIME 类型），等于把一小块前端逻辑搬到链上；渲染端拿到什么显示什么，而不是本地预先写死界面。auto 模式则相反，合约只提供 ABI 可读的返回值，页面长什么样由客户端决定。这带来一个直接的使用差异：同一条 URL 在不同客户端上渲染可能完全不同，因为”界面”不在标准管辖之内。地址与合约地址的区分基础见 钱包地址怎么看：格式、校验、合约地址与个人地址的区别。
现状：草案，且远未普及
如实说：ERC-6860 标注为 Draft 状态，主流浏览器没有原生支持 web3:// 协议，多数钱包也没有把它做成入口。目前的使用形态主要是实验性客户端、专用浏览器扩展和 dapp 内部的跳转约定。对普通读者，这篇的价值不是鼓励你去点这类链接，而是看懂两层信号：当某个页面用 web3:// 把你引向一个”官方合约页”时，它要求你信任的链条很长——URL 拼写、ENS 解析、合约 resolveMode 声明、当前客户端的实现质量，任何一环都可能被仿冒利用；而且点击不等于安全，页面里再发起的签名与交易请求，仍然要按普通弹窗逐项核对。
如果确实要交互
三条底线。第一，把 URL 里的合约名或地址抄出来，在浏览器上独立核对地址的创建记录、代码验证状态和持仓规模，与页面声称的身份一致再继续。第二，任何从这类页面弹出的签名请求，按与 dapp 完全相同的标准核对方法名、参数与 spender；URL 形式不降低任何风险等级。第三，客户端兼容性本身是安全属性——一个把 resolveMode 返回值直接当 HTML 渲染、不做任何隔离的实验客户端，本身就是攻击面；优先使用有安全审计、有明确权限模型的钱包内实现，而不是来路不明的”web3 浏览器”。总之：这个方向把链上数据变成可读页面的意图是好的，但今天把它当便利入口的人，实际是在给实验协议当测试员。
把它读成一堂”信任链”课
即便永远用不上 web3://，这个标准也值得了解，因为它把链上交互的信任结构摊开给你看：一条普通网址背后你信任的是 DNS、证书和网站服务器；一条合约 URL 背后，你信任的是名字注册合约、被指向的代码和渲染它的客户端，三样全部在链上或链上可验证，但也全部可以被抢注、替换和劣质实现。这也是所有链上身份共同的课题——名字可以伪造、界面可以自己画，唯一坚固的锚点是你亲手核对过的那个地址。以后无论页面包装成网址、二维码还是 App 卡片，把注意力固定在这条最底层的核对上，就不会被任何”更自然的入口”话术带偏。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。