概念范围：获取、匹配与推送
讨论区块链匹配推送技术涉及哪些技术概念，可以先将其理解为一种应用流程：系统获取链上信息，判断信息是否符合业务条件，再向接收端发送通知。这里解释的是通用组成方式，不能据此认定某个具体产品已经具备这些能力。
这三个环节各有职责。获取环节解决数据从哪里来，匹配环节解决什么信息值得通知，推送环节解决如何把结果送达页面。节点接口与浏览器通知接口之间，还需要应用服务衔接。
节点交互：JSON-RPC与数据状态
以太坊开发文档介绍，应用通过节点读取链上数据或提交交易，JSON-RPC为这些交互提供统一的方法约定，使用JSON表示数据。它不限定传输方式；查询状态时，区块参数可指定区块高度，也可使用latest、safe、finalized或pending等标记。
对匹配系统而言，数据对应哪个区块、属于何种状态，会影响条件判断的含义。例如，“待处理状态符合条件”与“已最终确定的状态符合条件”表达不同。业务规则应明确使用的状态范围，避免把不同阶段的数据混为一谈。
规则匹配：把数据转成通知条件
匹配可以理解为将获取的数据与预设条件作比较。例如，应用可以围绕某个账户的查询结果定义通知条件。这是业务层的设计示例，并不意味着JSON-RPC自带完整的匹配推送服务。
设计条件时，需要明确比较对象、数据格式和触发时机。首次符合条件时通知，还是每次查询符合条件都通知，会产生不同的消息量。条件是否持续成立，也应与一次查询的结果区分开来。
结果推送：SSE的适用条件
MDN介绍的SSE通过EventSource让浏览器接收服务器事件，属于单向通信。服务端使用text/event-stream响应，可为消息设置事件类型、数据、标识及重连间隔；连接中断后，浏览器默认尝试重连。
因此，当页面主要需要接收匹配结果时，SSE可以承担通知通道。若用户需要修改条件或提交操作，还需通过其他请求通道与服务端交互。SSE本身不负责读取区块链，也不负责判断匹配规则。
常见问题：连通是否意味着可靠送达
自动重连不等于自动补齐遗漏消息。应用若要求断线后继续接收，需要自行设计消息保留、进度记录与补发机制；若可能重复接收，还需设计去重处理。
收到通知也不能单独证明链上状态已最终确定。通知应说明其对应的数据状态，让接收端能够区分观察到的变化与已经最终确定的结果。接口连通、条件成立和通知送达，是需要分别处理的三个问题。