当看到 NIP 2-1 WBG 这个比分时大多数观众只会记住胜负。但如果要把这个比分做成一个赛事应用页面事情就没有这么简单左边是 NIP右边是 WBG中间是 2:1 的比分下方还要展示两队选手评分、比赛状态、赛事名称用户还能对选手打分。这个场景非常适合用来练习一套完整的数据应用开发流程。本文从一个实际业务场景切入以 NIP 2-1 WBG 这场比赛为例从需求拆分、数据库设计、后端接口、前端展示到上线排查完整梳理一个“比赛结果 用户评分”系统的最小实现。文章不会分析比赛本身而是关注数据如何建模、接口如何设计、评分如何聚合、哪些地方最容易踩坑。适合正在学习后端开发、想理解一个业务需求如何落地成代码的读者也适合需要在内部系统里搭建类似“榜单、评分、结果展示”功能的开发者。1. 先拆解需求一场比赛的数据并不只包含比分1.1 从比赛结果页面拆出四类数据在 NIP 2-1 WBG 这个页面里用户能看到的信息可以拆成四个维度赛事信息比赛属于哪个联赛或阶段例如“示例联赛”“季后赛”。比赛信息主客队、比分、比赛时间、比赛状态。队伍和选手信息队伍名称、队徽、出场选手、位置。用户互动数据评分、评论、投票。前两类属于内容数据由赛事管理后台录入最后一类属于互动数据由用户在前端产生。两类数据的生命周期不同存储设计也要分开。很多初学者会把比分直接写成字符串比如score 2-1。页面展示时确实直观但后续要做统计就非常痛苦。想计算 NIP 主队胜率、WBG 近期大场胜负必须把两个队的比分拆开。更合理的做法是用两个字段home_score和away_score。1.2 评分应该落到哪一层类似虎扑评分的用户评分功能本质是用户对选手表现打分后台计算平均分、评分人数、最高分等指标。这里有两个关键设计点评分粒度和计算时机。评分粒度要落到“某个选手在某场比赛”而不是“某场比赛整体”。否则页面无法展示“本场评分最高的选手”也无法按队伍筛选选手。所以评分表需要同时关联比赛、队伍和选手。计算时机有两种选择。第一种是用户提交评分时同步更新一个汇总值第二种是查询时实时聚合。数据量小的时候实时聚合最简单逻辑也最不容易出错。数据量大之后再引入缓存或异步汇总。不要在早期就设计一套复杂的汇总表容易把评分明细和汇总结果搞混。1.3 架构选型单体 Demo 也可以把结构做清楚最小实现可以选择 Spring Boot MyBatis MySQL前端用原生 HTML JavaScript。如果你更熟悉 Python/Django、Node.js/Express可以把代码等价替换。这里选型的原则不是“哪个框架最强”而是“结构是否足够表达业务实体”。架构上分三层数据存储层MySQL 保存比赛、队伍、选手、评分。接口层REST API 提供比赛详情查询、评分提交、评分汇总查询。展示层页面调用接口渲染比分和评分。这样后续把页面换成小程序或 App后端接口不需要重写。数据库表结构也不会因为前端变化而频繁调整。2. 数据模型设计用四张表装下比分和评分2.1 表结构设计在 MySQL 中建立四张核心表team、match_info、player、user_score。如果后续要支持多个联赛可以再加tournament表。这里先不做过多扩展保持核心流程清晰。先看队伍表CREATE TABLE team ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, short_name VARCHAR(16), logo_url VARCHAR(255) );队伍表负责保存 NIP、WBG 这样的战队名称short_name存放简称logo_url存放队徽。这里不建议在比赛表里直接写队伍名字因为队伍可能改名、队徽会换直接写死会导致后续维护困难。比赛表结构如下CREATE TABLE match_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, tournament_name VARCHAR(128), home_team_id BIGINT, away_team_id BIGINT, home_score INT DEFAULT 0, away_score INT DEFAULT 0, match_status TINYINT DEFAULT 1, match_time DATETIME, FOREIGN KEY (home_team_id) REFERENCES team(id), FOREIGN KEY (away_team_id) REFERENCES team(id) );这里用home_team_id和away_team_id关联队伍表比直接存“NIP”“WBG”更规范。match_status表示比赛状态0 未开始、1 进行中、2 已结束。home_score、away_score是最终比分例如 NIP 2、WBG 1。选手表关联队伍CREATE TABLE player ( id BIGINT PRIMARY KEY AUTO_INCREMENT, team_id BIGINT, name VARCHAR(64), position VARCHAR(32), FOREIGN KEY (team_id) REFERENCES team(id) );用户评分表是最核心的一张表CREATE TABLE user_score ( id BIGINT PRIMARY KEY AUTO_INCREMENT, match_id BIGINT, player_id BIGINT, user_id BIGINT, score DECIMAL(3,1), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_match_player_user (match_id, player_id, user_id) );score使用DECIMAL(3,1)表示范围是 0.0 到 99.9能够覆盖 1 到 10 分或 1 到 5 分的评分场景。唯一键uk_match_player_user确保同一个用户对同一个选手在同一场比赛里只能评一次防止重复提交。2.2 主键为什么用 BIGINT评分为什么用 DECIMAL在赛事类应用里比赛和用户量增长很快。使用 INT 作为主键在极端情况下可能溢出使用 BIGINT 是更稳妥的选择。并发量上来后很多团队会改用雪花 ID 或分布式 IDBIGINT 也能直接容纳。评分不用 FLOAT 或 DOUBLE是因为浮点数在求和与平均时可能出现精度问题例如 0.1 0.2 得到 0.30000000000000004。评分展示需要稳定出现这种误差会影响用户体验。DECIMAL是精确数值类型适合金额、评分、百分比这类需要精确比较的场景。2.3 索引和查询性能的基本考虑比赛表建议建立以下索引ALTER TABLE match_info ADD INDEX idx_match_status_time (match_status, match_time);用户评分表建议建立组合索引ALTER TABLE user_score ADD INDEX idx_match_player (match_id, player_id);这样查询“某场比赛某选手的评分汇总”时可以快速定位到少量记录避免全表扫描。实时聚合接口在数据量小的时候不会成为瓶颈数据量增长后再考虑汇总表或缓存。2.4 一个常见的设计错误平均分直接存在比赛表里有些方案会在match_info表加一个avg_rating字段用户每次评分都去更新比赛表的平均分。这样查询确实快但存在三个问题多个用户并发评分时直接更新avg_rating可能丢失更新。想统计“哪些用户评过分”时没有原始数据。平均分的计算逻辑散落在业务代码里后期修改评分规则会很麻烦。建议保留独立评分明细表平均分通过聚合计算或者通过异步任务汇总到单独缓存中。明细数据是源汇总结果只是派生物。3. 后端接口提交评分和查询评分分开设计3.1 项目结构以下示例使用 Spring Boot MyBatis。实际项目需要根据自己的包名、路径和依赖版本调整。核心包结构如下src/main/java/com/example/esports ├── controller │ ├── MatchController.java │ └── ScoreController.java ├── entity │ ├── MatchInfo.java │ ├── Player.java │ ├── Team.java │ └── UserScore.java ├── mapper │ ├── MatchMapper.java │ └── ScoreMapper.java ├── service │ ├── MatchService.java │ └── ScoreService.java └── common └── Result.javaController 只负责接收请求和返回结果Service 处理业务规则Mapper 负责和数据库交互。不要把业务逻辑都堆在 Controller 里否则单元测试和后续维护都会很困难。3.2 统一返回结构接口最好统一返回结构让前端可以统一处理成功、失败和异常。示例public class ResultT { private int code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 0; result.message success; result.data data; return result; } public static T ResultT error(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }统一结构可以让前端在fetch回调里先判断code再处理data避免每个接口各自设计一套错误格式。3.3 查询比赛详情接口后端需要提供一个接口返回比赛信息、队伍信息和比分。JSON 结构可以设计为{ code: 0, message: success, data: { matchId: 1001, tournamentName: 示例联赛, homeTeam: { teamId: 1, name: NIP }, awayTeam: { teamId: 2, name: WBG }, homeScore: 2, awayScore: 1, matchStatus: 2 } }查询逻辑用 MyBatis 的关联查询实现Mapper public interface MatchMapper { MatchInfo selectMatchDetail(Param(matchId) Long matchId); }对应的 XMLselect idselectMatchDetail resultMapmatchDetailMap SELECT m.id AS match_id, m.tournament_name, m.home_score, m.away_score, m.match_status, ht.id AS home_team_id, ht.name AS home_team_name, at.id AS away_team_id, at.name AS away_team_name FROM match_info m LEFT JOIN team ht ON m.home_team_id ht.id LEFT JOIN team at ON m.away_team_id at.id WHERE m.id #{matchId} /select注意使用LEFT JOIN而不是INNER JOIN。虽然正常比赛都会关联主客队但历史数据可能存在脏数据或外键为空的情况LEFT JOIN可以保证比赛记录仍然被查出来只是队伍信息为空。3.4 提交评分接口用户提交评分时后端要做三件事校验参数、判断比赛是否已结束、检查是否重复评分。示例接口如下PostMapping(/api/scores) public Result? submitScore(RequestBody ScoreSubmitRequest request) { if (request.getScore() null || request.getPlayerId() null) { return Result.error(参数不完整); } if (request.getScore() 1 || request.getScore() 10) { return Result.error(评分范围必须在1到10之间); } MatchInfo match matchService.getById(request.getMatchId()); if (match null || match.getMatchStatus() ! 2) { return Result.error(比赛不存在或比赛未结束); } int exists scoreMapper.countByMatchPlayerUser( request.getMatchId(), request.getPlayerId(), request.getUserId()); if (exists 0) { return Result.error(该用户已经评过分); } scoreService.insert(request); return Result.success(null); }这里的userId应该从登录态获取而不是信任前端传来的值。否则用户可以伪造请求替别人评分。3.5 查询选手评分汇总展示页面需要“本场各选手得分”。这个接口要返回每个选手的平均分、评分人数和最高分。SQL 用聚合函数SELECT p.id AS player_id, p.name AS player_name, IFNULL(ROUND(AVG(s.score), 1), 0) AS avg_score, COUNT(s.id) AS score_count, IFNULL(MAX(s.score), 0) AS max_score FROM player p LEFT JOIN user_score s ON p.id s.player_id AND s.match_id #{matchId} WHERE p.team_id IN (#{homeTeamId}, #{awayTeamId}) GROUP BY p.id, p.name ORDER BY avg_score DESC如果某个选手暂时还没有人评分LEFT JOIN配合AVG会返回NULL。使用IFNULL可以把NULL转换成 0避免前端渲染出错。4. 前端展示让比分和评分在一个页面上联动4.1 页面结构为了演示接口联调这里使用纯 HTML JavaScript 页面不引入前端框架。页面左侧显示比赛比分下方显示两队选手评分列表。div idmatchHeader span idhomeName/span span idhomeScore/span : span idawayScore/span span idawayName/span /div div idscoreBoard/div页面加载时调用比赛详情接口和评分汇总接口把数据渲染到对应位置。4.2 调用接口假设后端启动在 8080 端口前端通过 fetch 调用async function loadMatchData() { const matchRes await fetch(/api/match/1001); const matchJson await matchRes.json(); document.getElementById(homeName).textContent matchJson.data.homeTeam.name; document.getElementById(awayName).textContent matchJson.data.awayTeam.name; document.getElementById(homeScore).textContent matchJson.data.homeScore; document.getElementById(awayScore).textContent matchJson.data.awayScore; const scoreRes await fetch(/api/scores/1001); const scoreJson await scoreRes.json(); renderScoreBoard(scoreJson.data); } function renderScoreBoard(list) { const board document.getElementById(scoreBoard); board.innerHTML list.map(player div classplayer-row span${player.playerName}/span span${player.avgScore}/span span${player.scoreCount}人评分/span /div ).join(); }如果页面和接口不在同一个域名需要后端开启 CORS或在开发环境配置代理。这里使用相对路径可以避免开发时的跨域问题。4.3 评分提交表单页面要允许用户给某个选手打分。最简单的实现是每个选手行内放一个输入框和提交按钮async function submitScore(playerId, score) { const payload { matchId: 1001, playerId: playerId, score: Number(score) }; const response await fetch(/api/scores, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify(payload) }); const result await response.json(); if (result.code 0) { loadMatchData(); } else { alert(result.message); } }提交成功后重新拉取评分汇总让平均分和评分人数自动刷新。这种“提交后回源查询”的方式虽然简单但对小规模应用是有效的。4.4 页面加载时序页面加载时比赛详情和评分汇总两个接口没有依赖关系可以并行请求。用Promise.all可以减少等待时间async function initPage() { const [matchRes, scoreRes] await Promise.all([ fetch(/api/match/1001), fetch(/api/scores/1001) ]); const matchJson await matchRes.json(); const scoreJson await scoreRes.json(); renderMatch(matchJson.data); renderScoreBoard(scoreJson.data); }如果其中某个接口失败页面需要有错误提示不能白屏。简单做法是try/catch后把错误信息展示在页面顶部。5. 运行验证从初始化数据到看到结果5.1 初始化示例数据向 MySQL 插入 NIP、WBG 两支队伍、一场比赛和几位选手。示例 SQL 如下INSERT INTO team (id, name, short_name) VALUES (1, NIP, NIP); INSERT INTO team (id, name, short_name) VALUES (2, WBG, WBG); INSERT INTO match_info (id, tournament_name, home_team_id, away_team_id, home_score, away_score, match_status) VALUES (1001, 示例联赛, 1, 2, 2, 1, 2); INSERT INTO player (id, team_id, name, position) VALUES (101, 1, PlayerA, Top), (102, 1, PlayerB, Mid), (201, 2, PlayerC, Top);这里使用 PlayerA、PlayerB 作为示例选手名因为原始资料中没有提供真实选手名单。真实项目中选手信息需要从赛事数据源同步不能在代码里写死。5.2 启动后端服务使用 Maven 启动 Spring Boot 应用mvn spring-boot:run启动成功后访问http://localhost:8080/api/match/1001应返回包含 NIP、WBG 和比分的 JSON。5.3 提交评分并验证聚合结果用 curl 提交两条评分curl -X POST http://localhost:8080/api/scores \ -H Content-Type: application/json \ -d {matchId:1001,playerId:101,userId:1001,score:9.5} curl -X POST http://localhost:8080/api/scores \ -H Content-Type: application/json \ -d {matchId:1001,playerId:101,userId:1002,score:8.5}再查询评分汇总接口PlayerA 的平均分应显示 9.0评分人数为 2。因为ROUND保留一位小数9.5 与 8.5 的平均值是 9.0。5.4 验证重复评分拦截同一个userId再次提交相同playerId的评分接口应返回“该用户已经评过分”。这是业务校验和数据库唯一键共同作用的结果。业务校验提供友好提示唯一键兜底并发情况。5.5 预期输出表场景操作预期结果查询比赛详情GET /api/match/1001返回 NIP 2:1 WBG第一次提交评分POST /api/scores返回 code0第二次提交同一用户评分POST /api/scores返回“该用户已经评过分”查询评分汇总GET /api/scores/1001PlayerA 平均分 9.0人数 2查询未评分选手GET /api/scores/1001平均分显示 0人数 06. 常见问题排查从数据库到接口再到前端6.1 JSON 中长整型精度丢失现象matchId为 1001 时前端显示正常但一旦 id 变成雪花 ID 或超过 2 的 53 次方的长整数前端拿到的最后几位变成 0。原因JavaScript 的 Number 类型无法精确表示所有 64 位长整数。处理方式有三种在 Jackson 序列化时把 Long 转为 String在 DTO 中把 ID 字段声明为 String前端在接口层不依赖 Number 类型处理 ID。示例JsonSerialize(using ToStringSerializer.class) private Long id;6.2 并发提交评分导致重复数据现象两个请求几乎同时到达业务层count都返回 0结果插入了两条记录。原因先查询后插入存在竞态窗口。两个事务可能都看到“不存在”的记录。处理方式在数据库层保留唯一键uk_match_player_user作为最终防线捕获DuplicateKeyException返回“该用户已经评过分”不要把业务校验当成唯一的防重手段。6.3 平均分显示为 null现象某个选手还没有评分前端显示null。原因LEFT JOIN后AVG对空集合返回NULL。处理方式在 SQL 中使用IFNULL(ROUND(AVG(s.score),1), 0)或者在 Service 层把null转换成 0。推荐在 SQL 层处理减少后端额外判断。6.4 查询比赛详情时队伍名称为空现象页面只有比分没有队伍名。原因比赛表里的home_team_id对应不到team表记录或者外键字段为null。排查步骤SELECT home_team_id, away_team_id FROM match_info WHERE id 1001; SELECT id, name FROM team WHERE id IN (1, 2);如果team表存在但名称仍为空检查查询 SQL 中 JOIN 字段名是否写错例如把home_team_id写成了home_id。6.5 开发环境跨域现象前端页面单独打开浏览器报CORS error。原因页面域名和接口域名不一致。处理方式开发环境可以通过 Spring Boot 的CrossOrigin或统一 CORS 配置允许指定来源。上线后建议使用 Nginx 反向代理同域访问不要把跨域配置放开到所有来源。6.6 请求参数校验不生效现象前端提交score为 0 或负数接口仍然返回成功。原因可能只在数据库层做了约束没有在接口层做参数校验。处理方式在 Controller 入口使用参数校验注解或在 Service 层显式判断范围。推荐使用 Spring ValidationNotBlank(message 评分不能为空) DecimalMin(value 1, message 评分不能小于1) DecimalMax(value 10, message 评分不能大于10) private String score;如果使用String接收评分再转换为BigDecimal可以避免浮点类型在 JSON 解析时出现精度异常。7. 生产环境改造从 Demo 到可上线7.1 数据来源自动化演示项目的数据是手工插入的。生产环境需要接入赛事数据源通过定时任务或消息队列同步队伍、比赛和选手数据。同步时要记录数据源的更新时间避免重复写入。比分更新应基于比赛状态变化触发而不是每次全量覆盖。同步任务至少要考虑三点幂等性同一场比赛重复同步不会产生重复记录。字段映射数据源的选手 ID 与本地 ID 如何对应。错误处理同步失败时是否能重试是否有日志和告警。7.2 缓存策略评分汇总接口在比赛结束后会被大量访问。如果每次都实时聚合数据库压力会很大。可以分两级处理短期缓存查询结果缓存 30 秒到 1 分钟适合刚结束阶段的频繁刷新。最终态缓存比赛完全结束后把最终汇总结果写入缓存或单独汇总表。缓存的 key 可以设计为match_score_summary:{matchId}。评分提交后要主动失效对应 key避免用户看到旧数据。7.3 反作弊和权限用户评分场景要重点检查以下几点未登录用户不能评分user_id必须从登录态获取不能直接接受前端传值。同一场比赛、同一选手、同一用户只能评一次这已经通过唯一键实现。如果评分对用户有激励还需要增加行为风控例如限制单用户在短时间内的评分频率。管理端要能修正错误评分不能把评分数据做成不可干预的纯用户数据。7.4 日志和监控评分提交属于写操作每次提交都应该记录操作人和请求时间。推荐输出结构化日志[score_submit] matchId1001 playerId101 userId1001 score9.5 time2025-01-01 12:00:00 ip127.0.0.1监控指标至少包括评分接口请求量和成功率。评分接口平均响应时间和 P99 响应时间。重复评分拦截次数。评分聚合缓存命中率。数据库慢查询数量。这些指标可以帮助定位“用户评分后平均分长时间不更新”“评分接口变慢”等生产问题。7.5 可复用检查清单上线前可以用这个清单核对检查项检查内容数据库唯一键是否包含 match_id、player_id、user_id数据库score 是否使用 DECIMAL 而不是 FLOAT数据库是否建立 match_status match_time 索引接口是否校验比赛状态和评分范围接口是否从登录态获取 user_id接口是否有统一返回结构并发是否捕获数据库唯一键冲突缓存评分后是否有失效或更新策略前端长整型 ID 是否按字符串处理前端无评分时是否显示 0 或“暂无评分”日志评分提交是否记录操作人和请求时间监控是否统计评分接口成功率、响应时间7.6 扩展方向这个项目还可以继续扩展增加多赛事维度把tournament抽成独立表。增加评论和点赞形成社区互动模块。使用 Redis 的 ZSet 维护选手评分排行。接入直播数据让评分页在比赛进行中实时刷新单局表现。增加后台管理页面支持管理员修正错误比分。如果想把 NIP 2-1 WBG 这类比赛数据做成数据可视化可以用 ECharts 展示两队近期胜负走势、选手雷达图等。这些扩展本质上都是在“比赛、队伍、选手、用户行为”这个数据模型上增加新的读取和计算维度。数据模型设计得足够稳定上层扩展才不会频繁推翻重建。