ethereum: 开头的支付链接怎么读：ERC-681 交易请求 URL 拆解

商户页面或钱包 App 的“收款码”，扫开常常是一行以 ethereum: 开头的文本。给它定格式的是 ERC-681，2017 年 8 月 1 日创建，按 ercs 仓库记录状态为 Final。它的目标很朴素：让收款请求像 bitcoin: 链接一样，能被任何支持该协议的应用接住，弹出预填好的交易，只差用户确认。

语法骨架

标准给出的结构是：协议前缀 ethereum:（可以再加 pay-），紧跟目标地址；地址后可跟 @ 加十进制链 ID，可跟 / 加函数名，再可跟问号加一串用 & 连接的键值参数。地址要么是以 0x 开头的四十个十六进制字符，要么是一个 ENS 名。链 ID 是选填的：写了就限定网络，没写则沿用钱包当前网络设置——这正是跨链收错的第一道缝。参数键里 value、gas、gasLimit、gasPrice 的值必须是数字，其余键要用 ABI 类型名做键、按类型给值。

金额和函数怎么写

不带函数名时，链接请求的是以太币支付，金额放在 value 参数里，单位是 wei，并强烈鼓励用科学计数法。标准原文的例子是请求 2.014 个以太币时写成 value=2.014e18。请求 ERC-20 代币支付则走合约的 transfer 函数：/transfer?address=收款地址&uint256=数量，数量同样是最小单位。要理解这些数字的量级，指数对Ether 应为 18，对代币应等于其 decimals() 返回值，标准建议照这个规则写，方便人类目测核对。

哪些值只是建议

标准的措辞很关键：链接里给出的金额只是建议，用户有权修改；没给金额时，钱包应提示用户自己输入。gasLimit 和 gasPrice 同样是可编辑的建议值，gas 与 gasLimit 同义。换句话说，一条 URL 能替你预填表格，但不能替你按下确认键，任何要求“照原文签、不许改”的话术都违背这个设计初衷。

地址解析的优先级

用 ENS 名收款时，何时解析、怎么解析由付款人决定。标准定了一条硬规则：十六进制形式必须优先，即便恰好存在一个由 0x 加四十个十六进制字符组成的 ENS 名，也不得去解析它，必须直接按地址处理。钱包还可以对视觉上模仿十六进制地址的 ENS 名发出警告甚至直接拒绝，因为改收款地址或金额是有利可图的攻击——标准要求用户只使用来源可信、完整性有保障的链接。

兼容与边界

从 bitcoin: 到 pay- 前缀：几段来历与两条硬规则

这份标准的来历有两段值得交代。它的前身 ERC-67 想用一种低层语法表示任意交易，因太抽象而作废，ERC-681 收缩到“支付请求”这个高频场景才活了下来；语法刻意模仿比特币支付早已普及的 bitcoin: 链接，动机部分还点名 Android 用 URL Intent 拉起应用是系统级偏好，链接格式统一才有跨应用接住的Chance。协议里那个可选的 pay- 前缀是留给未来版本的插槽：标准规定不兼容的升级必须改用别的前缀，且前缀要用短横线和后文分隔。

两条硬规则再强调一遍。金额的指数写法有约束：数字允许科学计数法，但只接受整数，指数字必须大于等于小数点后的位数——2.014e18 合法，1.5e17 这种会落到非整数以太币单位的写法不合法。链 ID 的语义也有边界：URL 里不写 @链ID 时，钱包沿用当前网络设置，收款方想锁定主网就必须显式写全；ENS 名的解析时点完全由付款方掌控，从收到链接到发出交易的任何时刻解析都算合规。对做收款页的开发者，这两条决定链接能不能被各家钱包一致地读懂；对付款人，它们决定弹窗里的网络与金额量级该不该再核一遍。

这份标准取代了更早期的任意交易 URL 提案 ERC-67，只聚焦支付请求这个高频场景；未来不兼容的升级必须换用别的 pay- 之外前缀。它能说明的是“对方请求你在某链向某地址付某个建议金额”，不能说明收款方身份可信，也不能替代你对金额量级的肉眼核对。本文为机制说明，不构成任何投资建议。