对接第一步不是写代码，是建字段映射表：源字段、目标字段、类型、转换规则、默认值，五列一张表。赛事数据API的字段量大——一场足球比赛的事件流就几十个字段，加上运动员数据、技术统计，全套下来两三百个字段。没映射表，联调时的扯皮能把工期拖长一周。
三个高频坑：时间戳时区不统一（有的源用 UTC 有的用本地，先统一成 UTC+ISO 8601 再入库）；赛事 ID 体系不兼容（供应商的 match_id 和内部 ID 的映射关系要落库，不能只写在代码里）；运动员同名处理（重名运动员靠 ID 不靠姓名，展示层的姓名只做显示）。
| 模式 | 适用 | 注意 |
|---|---|---|
| 推送（Webhook/WS） | 比分、事件流 | 要做幂等：同一事件重复推送很常见 |
| 拉取（定时轮询） | 赛程、积分榜、阵容 | 频率别超供应商限流，赛前 1 小时加密 |
多数供应商两种都提供，混合用：实时内容走推送，低频内容走拉取。推送链路的架构展开见赛事直播与实时数据方案。
比分误报后会回改，这是数据源的正常行为，不是故障。要设计补偿：所有比分事件带版本号，后到的修正事件覆盖旧值并触发界面刷新；积分榜、射手榜这类衍生数据不能实时算，要等终场修正窗口（通常 10-30 分钟）过了再结算。没做补偿的平台，积分榜算错是必然结果。
按顺序走省时间：第一周映射表评审加沙箱跑通，第二三周正式环境联调（覆盖一个完整比赛日），第四周异常场景与压线测试，第五周验收。最容易被打乱的是第二三周——供应商的正式环境名额经常要排队，项目启动时就把名额约好，能省一周干等。
对接做完只是及格，真正的考验在比赛日的峰值，见赛事峰值的高并发应对。数据源本身的选型方法，回看体育数据源接入与选型要点。