web3 网址的“5219”模式：ERC-6944 给 resolveMode 填的一个值

web3:// 这种写法让合约网址像普通网址一样被浏览器打开。负责这套寻址的 ERC-4804 在解析时先问合约一个问题：resolveMode()——你打算用哪种方式应答？常见的回答是 auto（自动模式，内容存在指定存储槽）或 manual（手动模式，合约自己处理）。2023 年 4 月 27 日创建的 ERC-6944 给这个问题添了一个新答案：返回 5219，把应答流程整个转交给 ERC-5219。按 ercs 仓库记录，这份标准状态为 Draft。

全部规格就是一个函数

ERC-6944 的正文极短。它要求想启用该模式的合约实现一个接口：继承 ERC-5219 的 IDecentralizedApp，并让 resolveMode 返回字符串 5219 右填充零到三十二字节后的值——注释里连十六进制都给了：以 0x35323139 开头（即字符 5、2、1、9 的 ASCII），后跟二十八个零字节，匹配时不区分大小写。除了这个值，标准没新增任何状态、事件或函数。参考实现三行代码，返回 "5219" 了事。

为什么值要长这样

ERC-4804 把 resolveMode 设计成 bytes32 而非小整数，就是为了把“模式名字”直接当值用：人读得懂，机器不用查表。ERC-6944 顺水推舟，取自身编号当模式名，一个数字串同时回答了“我是谁”和“我走哪条路”。这也解释了它设计说明里那句有点反常的话：不引入 ERC-165，因为互通性直接调 resolveMode 就能验证——模式名即能力声明，探测函数省掉了。

分工：一个管路由，一个管渲染

链上网页这条路从来是两层标准接力：ERC-5219 定义合约怎么应答一次 HTTP 风格请求（request 函数返回状态码、头部与正文），解决“合约返回网页”；ERC-4804 定义浏览器怎么从网址定位到合约并发出那次请求，解决“浏览器找上门”。ERC-6944 是两层之间的转接头：它不定义渲染、不定义安全，只声明一种衔接关系。写这份标准的人把胶水标准该有的克制做到了——正文里最长的部分是注释。

现状与阅读方式

模式值的工程含义：为什么是字符串而不是编号

要理解这份标准只有一行正文还值得一写，得看它挂靠的两种既有模式的处境。ERC-4804 的自动模式要求网页内容按约定格式躺在指定存储槽，合约写内容等于写存储，Gas 由字节数说了算；手动模式给合约开了后门，允许它在请求进来时临场决定返回什么。两种模式各有一批实现，但合约若已按 ERC-5219 那套“请求进、HTTP 响应出”的接口写好，接进 ERC-4804 时只差一个身份声明。ERC-6944 就是这张声明。

把模式值定成字符串的哈希填充而非递增整数，工程上有三层收益：链上读 resolveMode 的人肉眼就能认出 5219，不必查映射表；模式名取自提案编号，天然全局唯一，冲突问题不存在；不区分大小写的规定让实现少一类字节差错。标准的设计说明还解释了一个反直觉的选择——不接 ERC-165：互通性靠直接调 resolveMode 看返回值即可验证，多一层接口探测纯属浪费。参考实现则几乎是无代码：函数体返回字符串 5219，Solidity 会把它右填零成 bytes32。对读者，这份文件的全部实用价值可以压成一句：碰到 web3:// 页面渲染失败，第一件事是静态调用合约的 resolveMode，看看它承诺的是 5219、auto、manual 还是根本答不上来——答案本身就在合约里。

该提案状态仍为 Draft，是否落地取决于链上网页生态的实际采用。读它能带走三点：查 resolveMode 是判断合约网页走哪条解析路径的最快办法；bytes32 模式的字符串取值约定值得一记；“返回某个哈希”不等于“返回可读值”，把 ASCII 填充进三十二字节是这一族标准的通用手法。对读者而言，浏览器能否打开某个合约地址，取决于这几层标准是否同时就位，任何一环缺失页面就无法渲染。本文为机制说明，不构成任何投资建议。