L1
战报与球员数据
每场的最终比分、进球时段、换人记录与关键球员统计。首版先在终场后不久发布，随后还会经历一次复核修订，把临场判断与冷数据对齐。
内容体系说明 · 维护方式 · 演进记录
把散在各处的赛后信息，归到一条能回查的路径上
BSPORT体育做的不是发布消息，而是整理与核对：终场之后产生的战报、球员数据、裁判名单与补时对照，先被收进对应的联赛和轮次，再由各个模块标注自己的更新时间对外公示。
- 当前维护的赛事体系
- 12个
- 单赛季收录赛程与战报
- 3,800场以上
- 战绩留存跨度
- 5个赛季
02
内容主线
四条并行的内容线
四条线索各自维护、更新节奏不同，但都挂在同一套归类路径上，检索方式一致。
L2
裁判名单与补时对照
开赛前公布当值裁判组，终场后锁定各阶段实际补时长度，并与赛前第四官员给出的公示分钟数并排陈列，方便逐项比对。
L3
定位球效率
每队的场均角球与任意球直接得分，附前场任意球的落点区域分布。移动端可单独查询，是复盘比赛走势时用得最多的一类字段。
L4
收藏与跨赛季战绩
把关心的赛事收进本机列表，按赛季分组，核对一支球队的长期走势时不必每次重新查找。
移动端把定位球效率与收藏战绩放在首屏，桌面端则以索引与对照表为主，两边的入口在移动应用中心有更细的说明。
03
归类与检索
联赛 → 赛季 → 轮次 → 场次
四级路径是这个站点唯一的内容骨架。任何一条战报、一份裁判名单或者一组定位球数据，都能从这四个层级一路点下去。指针在路径图上停留，会显示该层级当前的口径说明。
按轮次归档而不是按发布时间排列，原因很直接：复盘的人脑子里想的是「第三十二轮」，不是「上周三」。同一轮的场次放在一起，横向比较场均角球、补时长度这类指标才成立；顺序流只能回答「什么时候发的」，回答不了「跟谁比」。
04
来源与复核
信息从哪来，中间过几道手
条目来源分三类：赛事组织方在公开渠道发布的正式口径、转播画面中可以直接读出的信息，以及编辑在场次记录模板中逐项填入的人工条目。三类内容进库后走同一条复核线，不因为来源不同而降低检查标准。
-
STEP 01
整理
编辑按联赛与轮次认领场次，把比分、时间、名单等字段填进模板，同时标注这批数据的采集时刻。
-
STEP 02
复核
重点场次由两人独立核对同一份条目，结论一致才放行；其余场次由单人整理后进入抽检，抽检比例约为三分之一。
-
STEP 03
公示
通过复核的条目对外可见，并写入该模块自己的更新时间，而不是全站共用一个时间点。
-
STEP 04
纠错
收到反馈后按顺序处理：账号与访问问题、数据字段错误、赛事组织信息错误。赛事高峰期优先处理字段错误。
06
团队与值班
按岗位分工，按赛季阶段排班
这里只介绍岗位，不介绍个人。四个岗位人数固定，但排班随赛季阶段调整：开局阶段与人手相对宽松的收官段侧重内容补齐，密集赛程段与杯赛淘汰段则把校对与客服侧的人手往前压。切换下面的标签可以看每个岗位具体做什么。
数据编辑
按联赛与轮次认领场次，负责原始条目的填写与初检。密集赛程段一天内要处理多轮比赛，因此模板字段做得尽量短，减少手填歧义。
数据校对
独立核对重点场次，并对其他场次做抽检。校对不依赖编辑的自述，而是重新走一遍来源比对，两者结论一致才进入公示。
可视化与前端
负责时间戳、四级路径图、定位球落点分布这类结构化呈现，以及移动端面板的信息排布。数据进入页面后怎么读，由这个岗位收口。
客服
接收数据纠错与账号访问问题，工作日 9:00-18:00 回复；赛事高峰期优先处理数据字段错误。邮件与电话渠道的说明在联系页面。
07
演进阶段
从赛程模块一路长到跨赛季台账
内容不是一次性搭好的。每一次扩展都发生在一个赛季阶段之内，先解决某类核对需求，再往下一层走。下面按阶段顺序列出，没有具体日期。
-
起步阶段
赛程与战报
最早只有赛程列表与赛后比分，服务的是「这场踢成什么样」这一个问题。
-
第二阶段
裁判名单与伤停补时对照
把当值裁判组与各阶段实际补时长度并入同一条目，核对比赛过程时不用再另找一处。
-
第三阶段
移动端定位球效率
角球与任意球得分进入独立查询，手机上打开就能看到落点分布，不再依赖桌面端表格。
-
第四阶段
收藏与跨赛季战绩
用户可以把关心的赛事收进本机列表，按赛季分组，把近 5 个赛季的战绩放平了看。
功能形态也在同步收敛：移动端主版本已经迭代到 v9，采用面板式结构，把定位球效率与收藏战绩提到首屏。想了解当前版本的模块分布，可以回到赛况首页或直接看移动应用中心的说明。