先确定业务对时效的真实要求
很多团队一上来就默认要长连接，但真正需要秒级同步的往往只有正在直播的那几场核心赛事。建议先按页面类型分级：直播页、比分详情页属于高时效，赛程页、积分榜、战队资料属于低时效。分级之后，高时效走推送、低时效走轮询，整体架构会清晰很多，也避免为了少数页面把全部流量都压到长连接上。
调用说明 - 电竞比分网
调用说明栏目面向准备接入本站实时比分与赛事数据能力的开发者与业务方，系统梳理从接口选型到上线运维的完整链路。无论你关注的是 LOL 比分、DOTA2 比分、CSGO 比分还是王者荣耀比分，都可以在这里找到对应的接入方式说明。我们按照轮询调用、长连接订阅与混合模式三条技术路线，分别给出接入复杂度、时效表现、弱网适应、资源消耗与推荐场景的对照说明，帮助你在直播类页面、低频展示页面与多端并行业务之间做出合适取舍。栏目内容会持续补充签名鉴权、数据结构、字段含义、错误码处理与限流策略等细节，让第一次接触的团队也能按图索骥完成对接，减少反复试错的时间成本，把精力放在比分直播与赛事数据的产品呈现上。
接入前值得先想清楚的几件事
数据结构是否稳定、字段是否可预期
判断一套调用方式好不好用，第一看返回结构是否稳定。字段命名是否统一、赛事状态是否有明确枚举、比分变更是否带时间戳与版本号，这些决定了你在前端做增量更新时的难度。如果每次变更都要靠全量刷新来兜底，说明数据结构的增量能力不足，长期看会显著增加带宽与渲染开销。
断线与乱序的处理方案是否明确
这是第一次接触的人最容易忽略的一点。长连接一定会断，网络一定会抖，推送到达顺序也不一定与产生顺序一致。好的调用说明会明确告诉你：重连之后如何补数、如何用事件序号或时间戳判断新旧、重复事件如何幂等处理。如果这些没有约定清楚，上线后就会表现为比分跳变、比分回退甚至卡在旧数据上。
限流、鉴权与错误码是否可自解释
调用量上来之后，限流策略会直接决定你的重试逻辑怎么写。需要确认是否存在按账号或按 IP 的请求上限、超限后返回什么状态、是否给出建议的重试等待时间。鉴权方式同样重要，签名算法、时效窗口与密钥轮换规则都应写清楚。错误码最好能自解释，让开发者不必逐条对照文档就能判断是参数问题、权限问题还是临时故障。
降级与兜底是否有默认路径
线上环境不可能永远理想，推送通道故障时页面不能白屏。建议在接入阶段就约定好降级路径：推送不可用时自动切到轮询，轮询也不可用时展示最近一次成功获取的快照并标注数据时间。这套兜底逻辑写进调用说明里，能让业务方在故障期间依然保持可用的浏览体验，而不是把问题直接暴露给用户。
多端数据口径是否统一
当 App、小程序与 Web 大屏同时在线时，最容易出现的问题是同一场比赛在不同终端显示不同比分。判断标准很简单：所有终端是否消费同一份事件流、是否使用同一套赛事 ID 与状态枚举。若各端各自调用不同接口，短期看似省事，长期会在数据对账上花费大量精力。统一口径是混合模式能否真正落地的前提。
三种调用方式与对接要点
下表对照首页展示的同一批条目，逐项展开说明每种调用方式的适用边界与注意事项，方便你结合自身业务节奏挑选方案，也便于后续在混合部署时按场景拆分流量。
🔁
轮询调用
客户端按固定间隔主动发起 HTTP 请求拉取最新比分，实现门槛最低，任何语言和运行环境都能快速跑通。适合对时效要求不极端、请求频率可控的展示型页面，接入前需要先确认好轮询间隔与限流阈值，避免在赛事高峰期出现无谓的重复请求。
📡
长连接订阅
客户端与服务端建立持久连接，比分或赛事数据发生变化时由服务端主动推送，事件触发即到达，延迟明显低于轮询。适合直播类页面这类要求画面与比分同步的场景，代价是需要维护连接状态，并配套心跳保活、断线重连与增量补数逻辑。
🧩
混合模式
核心赛事走长连接推送保证时效，次要赛事与历史数据走轮询补齐，两条通道各司其职。适合多端并行业务，例如同时存在 App、小程序与 Web 大屏的场景，可以在带宽、连接数与数据新鲜度之间取得平衡，但需要一套统一的调度与降级策略来兜底。
📶
接入复杂度
轮询调用复杂度低，HTTP 即可完成，无需额外协议支持；长连接订阅复杂度中等，需要维护连接生命周期与心跳机制；混合模式复杂度较高，需要同时管理推送与轮询两条通道，并在两者之间做数据去重与顺序校验，对工程能力要求更高。
⏱️
时效表现
轮询调用的时效取决于轮询间隔，间隔越短越及时但请求量越大；长连接订阅由事件触发即推送，秒级甚至亚秒级即可感知比分变化；混合模式核心赛事走推送、边缘赛事走轮询，整体时效接近纯推送方案，同时把资源开销控制在可接受范围内。
🛡️
弱网适应
轮询调用在弱网下表现稳定，单次请求失败重试即可，不依赖长时连接；长连接订阅在弱网中容易掉线，需要重连与补数机制，重连后按时间戳补齐缺失事件；混合模式可自动降级为轮询，网络恢复后再切回推送，保证页面始终有比分可展示。
⚙️
资源消耗
轮询调用的请求次数偏多，尤其在多端同时在线时服务端压力会随客户端数量线性增长；长连接订阅的连接占用稳定，单连接可承载多次事件推送，总体流量更省；混合模式按场景分配资源，把高频核心赛事与低频赛事分开处理，整体开销更可控。
🎯
推荐场景
轮询调用适合低频展示页面，例如赛程列表、历史战绩与积分榜等更新不频繁的内容；长连接订阅适合直播类页面，比分与赛事数据需要与直播画面同步；混合模式适合多端并行业务，需要在不同终端之间统一数据口径并兼顾时效与成本。
常见疑问解答
第一次接入应该从哪种方式开始
建议先用轮询调用跑通全流程，把鉴权、数据结构解析与页面渲染都验证一遍，确认无误后再按需要升级到长连接订阅。这样即使后续推送逻辑复杂，底层的数据理解已经打好基础，排查问题也更容易定位是哪一层出了状况。
轮询间隔设成多少比较合适
没有统一答案，取决于页面类型与赛事密度。低频展示页面可以放宽到数十秒一次，直播类页面则需要更短的间隔。关键在于同时满足时效体验与限流要求，并预留高峰期余量，避免在赛事集中时段触及请求上限而被动降频。
长连接频繁掉线该怎么排查
先区分是网络侧还是服务侧问题：看掉线是否集中在特定运营商或特定时段，看心跳是否按约定间隔发送且被正常响应。若心跳正常仍掉线，需要确认是否存在中间代理的连接空闲超时。排查清楚后再调整心跳周期与重连退避策略，通常能明显改善稳定性。
混合模式会不会增加很多开发量
会增加，但主要集中在调度层：需要一套逻辑决定哪些赛事走推送、哪些走轮询，以及两条通道的数据如何合并去重。把这层抽象成独立模块后，业务页面无需感知差异，后续新增终端时也能直接复用，整体收益大于一次性投入。