篮球赛程、比分与比赛状态：从接口目录到清晰的展示设计

一、先明确接口分工，再设计页面

篮球赛程页面不只是两支球队与一个比分。用户还需要判断比赛何时开始、是否正在进行，以及当前数字是否可以视为最终结果。设计时应把赛程信息、比分信息和状态信息分开组织，避免用单一颜色或比分是否存在来推断比赛进度。

产品事实：百查数据体育 API 的已核验目录包含以下三个比赛相关接口，方法均为 GET。目录还列有国家、联赛、赛季、阶段、球队、球员和场馆列表。本文仅确认这些接口的名称、地址与方法，不据此推断具体字段、筛选参数、分页方式或更新频率。

• 比赛-赛程赛果：GET https://api.superscore.cn/basketball/change/matchList
• 比赛-即时比分：GET https://api.superscore.cn/basketball/change/live
• 赛季-比赛：GET https://api.superscore.cn/basketball/change/matchSeason

二、建立稳定的信息层级

工程建议：比赛卡片可按“赛事与时间—对阵双方—比分与状态”排列。球队名称占据稳定位置，比分区域保持固定宽度，减少数字变化造成的布局跳动。移动端优先保留对阵、开赛时间和状态，场馆等辅助信息可以进入详情页；具体内容须以实际响应及字段说明为准。

时间展示应明确所用时区，跨日比赛按统一规则分组，不要让列表日期与详情时间互相矛盾。比分缺失时显示占位符，而不是补成零分；零分是有效数值，未知则意味着信息尚不可用。状态除颜色外还应有文字说明，兼顾色觉差异和屏幕阅读器。

三、用展示模型隔离状态映射

工程建议：前端建立独立展示模型，由适配层把实际响应转换为页面所需内容。未开始、进行中、已结束等可以作为内部展示分类，但不能当作接口已提供的状态枚举。映射必须依据正式字段说明；遇到无法识别的状态，应显示“状态待确认”，不要自动归为已结束。

// 前端展示模型示例，不代表接口响应字段或状态枚举。
// 数据适配层需依据正式字段说明另行实现。
const viewModel = {
  homeName: '主队占位',
  awayName: '客队占位',
  homeScore: null,
  awayScore: null,
  statusLabel: '状态待确认'
};

function scoreText(value) {
  return value == null ? '—' : String(value);
}

const display = {
  score: `${scoreText(viewModel.homeScore)} : ${scoreText(viewModel.awayScore)}`,
  status: viewModel.statusLabel
};

四、刷新与异常也属于展示设计

工程建议：刷新策略应结合接口使用规则与页面需求制定，不能把“即时比分”名称直接理解为推送能力或固定秒级延迟。页面可保留上一次成功获取的数据，并标注本地获取时间；该时间不等同于比赛数据源的更新时间。请求失败时提示“更新失败”，不要把旧比分包装为最新比分。

上线前应测试未开赛、比分为零、数据缺失、未知状态、跨时区和请求失败等场景，并检查窄屏下的名称截断与数字对齐。最终目标不是让卡片看起来更热闹，而是让用户准确区分已知事实、暂缺信息与更新异常；所有产品字段和调用限制仍须以正式接口说明为准。

查看接口文档 · 了解数据产品