火币WebSocket ticker订阅无法取消 发unsub请求后仍收推送数据

实际对接过火币WebSocket的开发者基本都踩过这个退订不生效的坑，你贴出的订阅、退订代码结构上是符合文档要求的，失效基本都是以下几个文档没写清楚的细节问题导致的：

• 字符串严格匹配校验不通过
  火币服务端对订阅、退订的匹配是逐字符校验的：
  • 交易对symbol必须全小写，如果你订阅时不小心传了大写（比如BTCUSDT而非btcusdt），退订时传小写的topic会直接匹配失败
  • 退订请求里的id字段必须和对应订阅请求里传的id值完全一致，不能订阅时传随机生成的请求ID、退订时直接传交易对字符串
  • topic字段必须和订阅时完全一致，不要多打空格、不要错写字段（比如把ticker写成detail或者其他业务topic）
• 退订请求发送时机不对
  发送订阅请求后，必须等服务端返回对应topic的订阅成功回执（带subbed字段的响应消息）之后再发退订请求，订阅流程没完成时发的unsub请求会被服务端直接丢弃，不会生效。
• 重复订阅计数问题
  火币服务端对同一个WebSocket连接上的重复订阅是按次数计数的：如果你代码逻辑因为重连、事件重复触发等原因，对同一个ticker topic发了2次及以上的sub请求，只发1次unsub只会抵消1次订阅，剩余的订阅关系还存在，服务端会持续推送数据，需要发对应次数的unsub直到收到退订成功响应为止。
• 跨连接/跨域名发退订请求
  退订请求必须在你发起订阅的同一个WebSocket连接上发送，如果你订阅连的是现货接入点、退订请求发到了合约/期权的ws地址，或者重连之后用新连接发旧连接的退订请求，完全不会生效。

退订生效判定标准 #

发送unsub请求后，只有收到服务端返回如下格式的响应，才代表退订真正生效：

{
  "id": "对应订阅请求传入的id值",
  "status": "ok",
  "unsubbed": "对应退订的topic字符串",
  "ts": "服务端返回的时间戳"
}

如果发完unsub长时间没收到上面的响应，直接对照前面的几个排查点打印实际发送的请求日志逐一定位即可，不需要等官方支持回复。

内容的提问来源于stack exchange，提问作者Melih Cihan GULER