一个网址翻译成一笔链上调用的 web3:// 语法

浏览器地址栏里的网址，能不能直接触发一次链上读取？ERC-4804 定义了一门 web3:// 语法：URL 里的域名经名字服务（如 ENS）解析为合约地址，路径被翻译成函数名加参数，浏览器或客户端据此发起一次 EVM 调用并把返回值渲染出来。提案在 ercs 仓库的状态是 Final（最终），创建于 2022 年 2 月 14 日，依赖 ERC-137。它还有一串同族后续标准处理扩展：ERC-7087 管自动模式的 MIME 类型、ERC-7617 与 ERC-7618 管分块与内容编码、ERC-7744 甚至让“按字节码找到的合约”也能进这套寻址体系。

URL 的骨架

规范的语法可以读成：协议头（web3://、w3://、ethereum-web3://、eth-web3://）可省略用户段 userinfo@，然后是合约名（一段地址，或带 .eth 之类后缀的名字），可跟冒号加链 ID，再是路径 method/参数/参数，最后是问号查询串。用户段对应调用里的 From，不写则协议以零地址为发送者——因为只读，零地址身份是安全的。合约名对应 To：十六进制地址直接用，名字则按后缀交给名字服务解析。链 ID 不写时跟随名字服务所在的链，例如 .eth 默认主网；没有名字服务时默认链 1。

自动模式与手动模式

解析先问合约的 resolveMode。自动模式（默认，合约没有该方法时也走自动）把路径按 Solidity ABI 编译成 calldata：第一段是函数名，后续段是参数；每个参数可以先写类型前缀加感叹号再写值，不写类型则按规则顺序猜——纯数字当 uint256，0x 加三十二字节十六进制当 bytes32，0x 加二十字节当 address，0x 加其他长度当 bytes，都不是就再当域名解析。查询串里的 returns 属性告诉客户端怎么解析返回数据：不写按 bytes32 处理，写 () 按原始字节转 JSON，其他按指定类型转 JSON；多个 returns 取最后一个。手动模式则完全不做解释，路径加查询原样塞进 calldata，留给合约自定义协议。规范示例写得很直白：web3://w3url.eth/ 解析 ENS 后以 calldata 为 0x2F（斜杠的字节）调用；web3://cyberbrokers-meta.eth/renderBroker/9999 会拼出函数选择器加编码后的整数 9999。

只读语义与安全边界

三个容易踩的写法坑

实际使用这门语法，坑集中在书写细节。类型猜错是第一坑：web3://x.eth/f/0x1234 里参数既非三十二也非二十字节，按规则会被解析为 bytes 而非地址，合约若期望地址参数，结果以零或垃圾值调用，只读场景浪费一次查询，写场景绝不允许。链 ID 漏写是第二坑：省略时跟随名字服务的链，同一合约在测试网与主网可能数据完全不同，页面上标了链 ID 再动手是纪律。手动模式的误读是第三坑：目标合约声明手动模式后，路径不再按 ABI 切分，整段字符串直送 calldata，把自动模式习惯带过去必然出错。顺带说明同族标准的分工边界：本规范只定翻译规则，渲染相关的 MIME 与编码由 7087、7617、7618 处理，批量与缓存另有 7774 等草案在议。URL 是给人看的界面，链上调用的真实内容永远以解码后的 calldata 为准——养成先看解码再决策的习惯，比记住全部文法更重要。

再补一条排障线索：自动模式的类型推断会静默生效，遇到返回全零的查询先怀疑参数被猜成错误类型，显式写类型前缀是最稳的写法。

必须看清的第一条边界：规范只定义只读调用——Solidity 的 view 函数语义——任何改状态的函数不在这门语法的授权范围内，写操作被明确划为未来扩展。第二条：这条链上数据经由 URL 送达眼前，中间没有任何人替你担保内容真伪，合约返回什么就显示什么，钓鱼合约完全可以返回一段误导文本。对用户，实践含义是：URL 里的域名后缀、链 ID 段、参数写法都要按字面核对，尤其注意链 ID——同名合约在不同链上可能行为迥异。给开发者，Final 状态与 ERC-7588、ERC-7964 等家族扩展意味着这是少见的“真的能用”的链上内容协议，把 NFT 元数据页做成合约直读页有标准可循。本文为机制说明，不构成任何投资建议。