不刷新也能知道有人出价：市场实时事件订阅的推送模型

写 NFT 数据工具的人迟早都会问同一个问题：怎么第一时间知道某集合有人挂单、成交或撤单？最直觉的答案是轮询——每隔几秒调用一次查询接口。能用，但它把成本摊在了错误的一侧：绝大多数轮询一无所获，而你为每一次“没有”也付了请求费、挨了限频。市场方给出的另一侧方案是推送：注册一条长连接，事件发生时由服务器主动把消息递给你。以 OpenSea 的 Stream API 为例，这套模型值得当作模板拆开看。

先看可订阅的事件清单。文档列出的事件方法覆盖市场的主要状态变化：新挂单、成交、藏品转移、元数据更新、列表或出价被取消、单件藏品收到出价等；订阅粒度做成“集合乘以事件类型”的组合——可以只听某个集合的成交，也可以用通配符订阅全市场某类事件，还能一个回调同时接多种事件、由服务器端过滤。每个订阅返回一个取消函数，用完即关，不留悬挂连接。

事件本身的结构也体现了“推送要自带上下文”的取舍。以成交事件为例，文档示例的载荷里带上了成交价、买卖双方的链上地址、计价代币（含小数位与价格字段）、数量与各类时间戳。这类设计的意图是让接收方不必再为每个事件反查详情接口——推送自带一份可用快照。但快照只保证“事件发生那一刻服务器看到的样子”，不保证与链上最终状态严格同步，重组、索引延迟都可能让推送里的字段与事后浏览器查询存在出入，关键场景仍应以链上确认为准。

配额规则是轮询党转推送党最实在的收益点。官方文档明确写着：流式推送的事件不计入常规 API 速率限制。翻译过来：轮询的成本是“问的次数”，推送的成本是“发生的事”。前者随你的焦虑增长，后者只随市场真实活动增长。对只想守十几个集合的场景，一条连接几乎免去了限频烦恼；但要注意这不等于无限——连接数、订阅集合总数与消息吞吐仍有服务条款约束，把“不占查询配额”读成“可以无脑开一万个订阅”是常见误读。

剩下的两个坑都在客户端自己身上。其一是乱序：长连接不承诺事件按链上顺序送达，先看到“转移”再补到“成交”完全正常。稳妥做法不是按到达顺序直接改本地状态，而是给每条事件带上时间戳与交易号，以幂等方式写入——同一事件重复推送不重复计数，旧事件晚到不回滚新状态。其二是断线：连接会掉，而掉线期间的事件不会自动补发；生产系统需要维护一条低频轮询的“补拉”通道，定期比对最后已知事件与查询接口结果，把漏网的消息找回来。推送提速、轮询兜底，两条腿走路，几乎是所有事件订阅系统的最终形态。

对普通读者，这套模型解释了为什么专业盯盘工具能在几秒内弹出“稀有件上新”，而网页列表慢半拍——它们取数的管道本来就不同。它也提醒所有拿事件数据做决策的人：推送里的价格与地址是快照不是终审，任何一步涉及资金的操作，都值得回到链上记录再确认一次。

接入之前还有两个现实前提要核对。其一是鉴权与准入：这类流式接口通常要求 API 密钥，接入前先确认你的密钥等级是否允许开流、允许多少并发订阅，别在代码写完后才发现配额档位不够。其二是环境的临时性：推送连接经过的是市场方的基础设施，服务升级、地域网络抖动、维护公告都会造成事件空洞，所以监控本身也要做进系统——连接存活指标、最近事件时间戳的滞后量，都该在告警面板上占一行。把推送当水电一样稳定的假设，是事故清单上出现频率最高的一条。

本文为机制说明，不构成任何投资建议。