Coinbase 行情接口序号跳号：是丢消息还是乱序？
Coinbase WebSocket 消息里的序号不连续，通常分两种情况理解：序号向前跳增超过 1，说明中间有消息被丢弃；序号比上一条小，则可能是乱序到达，也可能按文档口径直接忽略。两种情形都不能当作“网络卡了一下”就算了，因为你的本地订单簿状态可能已经和服务器不一致。以下依据 Coinbase Advanced Trade WebSocket 官方概述页的序号说明，解释判断思路；本文不展示实时行情，也不提供补单代码。
序号本来应该怎样递增
按 Coinbase 文档口径，大多数行情消息带有序号（sequence number）。序号是按产品（for each product）分别维护的递增整数，每一条新消息的序号应恰好比前一条大 1。这里的“按产品”很关键：ETH-USD 和 ETH-EUR 各自有独立的序号序列，不能拿不同产品的消息互相比较。适用对象是使用 Coinbase 行情接口 WebSocket 接收消息、并在本地维护状态（例如订单簿）的开发者。文档同时说明，即使 WebSocket 连接建立在 TCP 之上，WebSocket 服务器接收市场数据的方式仍可能导致消息被丢弃，因此消费端应按“可能丢消息、可能乱序”来设计。
跳增：说明中间有消息被丢掉
如果新消息的序号比上一条大出不止 1，文档明确表示这表示有消息被丢弃（a message has been dropped）。举例来说（此为说明性假设，不是实时数据）：某产品上一条序号是 100，下一条收到 103，那么中间若干序号对应的消息没有到达你的消费端。此时本地状态可能缺少若干次更新，不能假定“下一条会自然补上”。文档的措辞是需要你自行执行逻辑，确保系统处于正确状态。换句话说，跳增是“丢消息”的信号，而不是乱序的信号。
回退：小于上一条，可忽略或视为乱序
如果新消息的序号小于上一条，文档给出两种理解：可以忽略，或者代表一条消息乱序到达。这里要注意，文档并没有承诺“回退一定是乱序、等一等就会齐”，而是把处理责任交给消费端。实际判断时，可以把“回退”与“跳增”分开记录：回退更像到达顺序问题，跳增更像中间缺失。两种情况下，文档都要求消费端有必要逻辑来保证系统状态正确。至于具体如何重建状态，文档没有在序号一节给出补单算法，本文也不提供代码。
怎样判断消息是否丢了
可操作的判断标准就是文档给出的两条：相邻消息序号差大于 1，视为丢消息；序号小于前一条，视为可忽略或乱序。判断时必须按产品分别跟踪“上一条序号”，只对同一产品的行情消息比较，不要跨产品混用基线。文档还提示，若希望保证消息送达并与订单簿同步，可以考虑使用 level2 频道；该频道在文档中被描述为可保证消息送达。需要说明的是，这属于接口用途层面的说明，不代表本文展示或验证了任何实时行情。另一个边界是：文档原文为“大多数 feed 消息”带序号，并未承诺所有消息都一定带序号，因此消费端还应处理没有序号的消息，不能把序号逻辑强加到每一条消息上。
把序号当作状态校验信号
理解 Coinbase 行情接口的序号，重点不是“数字连不连续好不好看”，而是把它当作本地状态的校验信号：跳增提示缺失，回退提示顺序异常，两者都可能让本地订单簿偏离服务器状态。按文档口径，消费端应能处理序号缺口和乱序消息，或者改用保证送达的频道。具体到你的系统，先按产品维护序号基线，再决定忽略、等待还是重建状态；这些逻辑需要自行设计和验证。