ERC-5219 让合约返回网页：request 接口、external-body 与前端搬到链上的边界

一句话理解

ERC-5219（Contract Resource Requests，已定稿）给合约加了一个很像 HTTP GET 的查询口：客户端把路径拆成字符串数组、把查询参数写成键值对传给合约，合约返回三样东西——状态码、响应体、响应头。标准文档给出的动机很直白：要让去中心化应用完全脱离中心化网站的前端载体，否则访问 DApp 第一步就是去下载一个中心网站的代码，带来信任、审查、永久性与互操作性四类问题。

接口本身定义得很小：一个 request 函数，参数是资源路径数组和键值参数数组，返回一个无符号 16 位状态码、一个字符串响应体和一组键值响应头。标准建议实现方把应用逻辑与前端逻辑分开：前端逻辑放在实现该接口的合约里，真正的业务合约保持干净。

省 Gas 的那个技巧

标准给实现者的一条明确建议是：用 message/external-body 这个 MIME 类型，而不是把大文件塞进合约。它给的示例是状态码 200、响应体写一句“这不是真正的正文”、响应头里 Content-type 写成 message/external-body; access-type=URL; URL="ipfs://..."——意思是“内容在 IPFS，你自己去取”。这样合约只负责告诉客户端去哪儿取数据，避免把字节流写进链上。

方法被设计成只读的原因也写在文档里：为请求发一笔交易既贵又要等确认，体验太差；复杂前端逻辑本就该跑在用户机器上；状态变更类操作应当配合 307 临时跳转这类机制另外处理，而不是塞进这个 GET。

它把攻击面搬到了哪里

合约返回“可渲染内容”，等于把一部分原先属于钓鱼网站的风险搬进合约本身。标准自己的安全提示很简短：访问普通 URL 的常规安全考量在这里同样适用，例如跟随 3XX 跳转可能造成隐私泄露。落到实际使用上，三条边界值得讲清：

• 返回的 HTML 由合约代码控制，渲染端必须把它放进隔离环境，这与铭文生态处理 HTML 铭文的思路一致。
• 查询是只读模拟，不构成链上承诺；合约今天返回一个页面，明天可以返回另一个。
• 响应头里的外链指向站外资源，链上合约管不到那一侧的内容变化。

与 web3 URL 怎么配合

ERC-4804 定义了 web3:// 形式：把 URI 翻译成一次 EVM 调用，可以按合约地址或名字服务里的名字访问。ERC-6821（草案）则补上 ENS 名字到合约地址的映射规则：先查该链上 ENS 解析器的 contentcontract 文本记录，记录不存在时退回 ERC-137 的 addr 解析，解析结果为零地址则报错。它还特意说明为何用文本记录而不是 contenthash：文本可读，符合 ERC-4804 的设计原则，而且文本记录可以带 TTL 等额外字段。

配合起来的形态是：合约用 5219 式的接口对外提供展示资源，项目把常用路径登记成 web3://名字/路径 写进介绍文案，域名比裸十六进制好读，也能在后端合约迁移时只改解析不改引用。前提是域名的持有者保持诚实——谁控制解析记录，谁就控制这个名字指向哪份合约。

用户视角的三句提醒

支持这类接口的客户端是少数，看不到 HTML 展示不等于合约没有实现。任何来自合约的链接都可能指向站外页面，点击决策与普通网络链接一样按普通安全习惯处理。合约写错或被人改了返回内容，界面上没有“撤销”，只能看接口返回与事件历史自行判断。

响应长什么样

文档给的示例很具体：状态码 200，响应体写一句占位文本，响应头里 Content-type 取 message/external-body; access-type=URL; URL="ipfs://..."——客户端读到这一行，就该去那个地址取真正的数据。规范把这套设计解释得很克制：只保留 GET 这一个最相关的 HTTP 语义，查询参数编进资源路径，请求头大部分场景不必要；将来若要发起状态变更，配合 307 临时跳转这类机制另行处理，而不是把交易塞进查询里。

风险提示：本文为标准机制科普，不构成任何投资建议。合约返回的可渲染内容不具备可信默认值，渲染与跳转请以支持隔离沙箱的客户端为准。