网页缓存跟着链上事件作废：ERC-7774 的 evm-events 指令

用 web3:// 直接把 NFT 页面渲染成网页的玩法，性能命门在 RPC 调用量：每次访问都去链上读数，节点费用和时间都撑不住。常规的解法是 HTTP 缓存，但链上数据又确实随时可能变。ERC-7774（Cache invalidation in ERC-5219 mode Web3 URL）给出的折中是：页面照常缓存，由智能合约在数据变化时发一个事件，把对应的缓存主动作废。按 ercs 仓库记录，该提案状态为 Draft，创建于 2024 年 9 月 20 日。

为什么标准 HTTP 缓存条件不够用

这套机制建立在 ERC-6860 的 web3:// 体系和 ERC-6944 的 resolve mode 之上：合约充当网页服务器，把链上状态组织成 HTTP 响应。问题出在请求方向——resolve mode 不把请求里的 HTTP 头转发给合约，于是 If-None-Match、If-Modified-Since 这类协商缓存头没有落点，合约没法回答”你要的东西变没变”。提案还指出第二层理由：即便将来能读请求头，让合约逐个请求去判断缓存条件也不划算，把失效逻辑从合约执行路径里挪出去，改由事件广播，成本更低。

evm-events 指令怎么声明、怎么失效

标准的做法是给响应加一个 Cache-Control 扩展指令 evm-events（按 RFC 9111 的扩展指令语法定义）。网站若要对某个路径启用事件驱动缓存，必须在响应里带上该指令，同时按传统规则带上 ETag 等头；合约端则在页面内容发生变化、认为该清缓存时发出定义好的失效事件 ClearPathCache。指令的值可以留空——留空表示”响应页所在合约对该路径发出失效事件即作废”；也可以给出”地址+路径”的清单，表示还要监听其他合约或其他路径上的事件。这样一张静态 CDN 缓存的页面，失效信号不再是超时猜测，而是链上的一次真实写入。

对 NFT 展示端意味着什么

排查一次”页面显示旧数据”的定位顺序

当用户报告 web3:// 页面显示的持有量或元数据明显滞后，排查顺序可以按这套机制的设计反向走。第一步看响应头：页面响应里有没有 evm-events 指令、有没有配套的 ETag——都没有的部署根本没启用事件失效，看到的只是普通超时缓存，滞后属于默认行为。第二步看事件：到对应合约按路径过滤 ClearPathCache 事件，确认状态变更那一笔交易确实触发了失效信号；有写入、无事件，说明合约端漏发，是项目方代码问题。第三步看中间层：事件确实发了但页面照旧，怀疑 CDN 或网关忽略了扩展指令——不同实现对未知指令的处理并不一致，这一步通常要靠带请求头转发的调试工具复核。第四步才是节点与解析：排除以上各项后，再查链上读取链路。这个顺序的价值在于把”数据不可信”这种模糊指控拆成四个各有证据的可查环节，让责任归属用日志说话，而不是在群里各执一词。

先看受益面：项目主页的持有量、白名单状态、元数据预览这类页面，若走 web3:// 渲染，接入这套机制后可以在不牺牲新鲜度的前提下把绝大多数请求挡在缓存层，节点账单和用户等待时间一起下降。再看边界。第一，它依赖中间层遵守指令：CDN 或网关若忽略 evm-events，机制形同虚设，用户端无从强制执行。第二，事件要发得准：合约开发者需要在每个影响页面输出的状态变更点记得发事件，漏发一次就是一次陈旧展示，这与写对业务逻辑是两回事。第三，它是 Draft：目前把它描述成已运行的公共基础设施不符合事实，核对相关工具时以 ercs 仓库文本和项目实现为准。对读者而言，它揭示的通用原则值得记住：任何”链上数据+缓存展示”的组合，都要回答”变了之后多久可见”这个问题，回答方式决定了页面可信的时效边界。本文为机制说明，不构成任何投资建议。