簡(jiǎn)介知識(shí)競(jìng)賽系統(tǒng)是一套基于C/MFC開發(fā)的可運(yùn)行在線答題平臺(tái)面向高校學(xué)生、競(jìng)賽組織者及需要快速搭建答題場(chǎng)景的開發(fā)者覆蓋試題維護(hù)、參賽者管理、限時(shí)答題和自動(dòng)排名等核心需求。壓縮包共61個(gè)文件約7.68MB文件類型以cpp/h源碼為主另有exe可執(zhí)行程序、mdf/ldf數(shù)據(jù)庫(kù)文件、ico/bmp圖標(biāo)資源和rc資源腳本既能通過(guò)源碼學(xué)習(xí)MFC界面設(shè)計(jì)與交互邏輯也可直接運(yùn)行查看系統(tǒng)全貌。項(xiàng)目?jī)?nèi)置試題分類添加、刪除與修改支持基于答題正確數(shù)量和限時(shí)速度的多種排名維度計(jì)時(shí)器、自動(dòng)評(píng)分與答題進(jìn)度記錄均已實(shí)現(xiàn)數(shù)據(jù)庫(kù)腳本和關(guān)鍵源碼一一對(duì)應(yīng)還可學(xué)習(xí)MFC界面、數(shù)據(jù)庫(kù)及榜單排名的常見實(shí)現(xiàn)直接部署替換題庫(kù)即可用于正式比賽或課堂測(cè)試。已有391人學(xué)習(xí)尤其適合畢業(yè)設(shè)計(jì)、課程實(shí)踐或希望快速落地答題系統(tǒng)的開發(fā)者。1. 知識(shí)競(jìng)賽系統(tǒng)到底在解決什么問(wèn)題從一張計(jì)分表到一場(chǎng)完整的現(xiàn)場(chǎng)競(jìng)賽很多人在沒辦過(guò)現(xiàn)場(chǎng)搶答賽之前會(huì)覺得一套知識(shí)競(jìng)賽系統(tǒng)不過(guò)是個(gè)“在線答題小程序”。真正上場(chǎng)后才發(fā)現(xiàn)最大的難點(diǎn)不是題庫(kù)容量而是整場(chǎng)比賽的秩序感誰(shuí)能搶答、倒計(jì)時(shí)還剩多少、裁判改判后比分怎么恢復(fù)、大屏和計(jì)分臺(tái)是不是同一份數(shù)據(jù)。知識(shí)競(jìng)賽系統(tǒng)要做的就是把題型、賽制、計(jì)時(shí)、計(jì)分和仲裁串成一條有狀態(tài)的流水線讓主持人只專心問(wèn)下一題裁判只判斷答案對(duì)錯(cuò)選手不用反復(fù)追問(wèn)“我剛才是不是搶到了”。這篇文章面向想自己搭建這套系統(tǒng)的開發(fā)者和組織者用一套前后端分離的常見方案從題型建模講到狀態(tài)機(jī)從搶答并發(fā)講到斷線重連最后落在一份可復(fù)查的事件流存檔上。2. 拆解知識(shí)競(jìng)賽系統(tǒng)的核心模型題型、賽制與狀態(tài)機(jī)2.1 題型與計(jì)分規(guī)則必答題、搶答題、風(fēng)險(xiǎn)題怎么建?，F(xiàn)場(chǎng)賽制看起來(lái)五花八門但拆開之后核心要素就三樣題型、分值、答錯(cuò)策略。必答題通常按隊(duì)伍順序輪流作答答對(duì)加分答錯(cuò)不扣分或者扣分搶答題則是“先搶到先答”為了保證競(jìng)爭(zhēng)性答錯(cuò)基本都會(huì)扣掉同等分值風(fēng)險(xiǎn)題更特殊同一道題可以在 10、20、30 分之間選擇答對(duì)加所選分值答錯(cuò)扣所選分值。這三類題型對(duì)計(jì)分模塊的要求完全不同如果設(shè)計(jì)階段就把分值寫死在題目字段里后面每換一次賽制就要改一遍代碼。我一般會(huì)先定義一個(gè)題型枚舉和一個(gè)計(jì)分規(guī)則對(duì)象讓所有題目都按規(guī)則驅(qū)動(dòng)。這里用 Python 展示最核心的結(jié)構(gòu)from enum import Enum from dataclasses import dataclass class QuestionType(str, Enum): REQUIRED required # 必答題按隊(duì)伍順序輪流作答 BUZZER buzzer # 搶答題先搶到先答 RISK risk # 風(fēng)險(xiǎn)題自選分值 dataclass class ScoringRule: question_type: QuestionType base_score: int # 必答/搶答的固定分值 correct_change: int # 答對(duì)后的分值變化 wrong_change: int # 答錯(cuò)后的分值變化負(fù)數(shù)表示扣分 allow_pass: bool # 是否允許棄權(quán)不扣分邏輯說(shuō)明把“題型”和“計(jì)分規(guī)則”拆成兩個(gè)概念是為了讓程序不關(guān)心具體賽制只關(guān)心題型。風(fēng)險(xiǎn)題的 base_score 在這里只是默認(rèn)值真正分值會(huì)由選手在開題時(shí)選擇然后覆蓋 correct_change 和 wrong_change 的絕對(duì)值。allow_pass 這個(gè)字段很實(shí)用很多必答題允許隊(duì)伍說(shuō)“過(guò)”一旦把它設(shè)成 False搶答后不許棄權(quán)否則按答錯(cuò)扣分。參數(shù)說(shuō)明correct_change 和 wrong_change 雖然大多數(shù)時(shí)候正好是正負(fù) base_score但留下一對(duì)獨(dú)立字段后就能支持“答對(duì)加 20、答錯(cuò)只扣 5”這類偏向鼓勵(lì)參與的賽制。落庫(kù)時(shí)我會(huì)把規(guī)則展開成一張 match_rules 表字段包括 id、match_id、question_type、base_score、correct_change、wrong_change、allow_pass。開題時(shí)服務(wù)端根據(jù)題型讀取規(guī)則再把實(shí)際分值合并進(jìn)下發(fā)到前端的消息里。這樣現(xiàn)場(chǎng)臨時(shí)改賽制后臺(tái)配置改完就能生效不用發(fā)布新代碼。2.2 賽制流程的狀態(tài)機(jī)從候場(chǎng)到頒獎(jiǎng)系統(tǒng)該記住哪些狀態(tài)現(xiàn)場(chǎng)執(zhí)行時(shí)最怕的不是題目難而是“不知道該做什么”。主持人按下開題鍵大屏要進(jìn)讀題讀完題要進(jìn)搶答有人按鈕后要進(jìn)作答答完要計(jì)分計(jì)完分還要問(wèn)“下一題嗎”。這一連串動(dòng)作如果全靠人記一定會(huì)亂。我把整場(chǎng)流程抽象成一個(gè)狀態(tài)機(jī)后端所有接口只允許合法流轉(zhuǎn)發(fā)生。狀態(tài)轉(zhuǎn)移關(guān)系先寫在代碼里例如STATUS_FLOW { CREATED: [ACTIVE], ACTIVE: [QUESTION_OPEN], # 比賽開始進(jìn)入開題 QUESTION_OPEN: [BUZZER_OPEN, ANSWERING], # 搶答題打開搶答窗口必答題直接轉(zhuǎn)作答 BUZZER_OPEN: [ANSWERING, QUESTION_OPEN], # 有人搶到或超時(shí)無(wú)人搶 ANSWERING: [SCORING], # 作答結(jié)束進(jìn)入計(jì)分 SCORING: [QUESTION_OPEN, FINISHED], # 下一題或結(jié)束比賽 } def can_transition(current: str, target: str) - bool: return target in STATUS_FLOW.get(current, []) assert can_transition(BUZZER_OPEN, ANSWERING)邏輯說(shuō)明這個(gè)函數(shù)看起來(lái)簡(jiǎn)單卻是整套系統(tǒng)的骨架。后臺(tái)控制臺(tái)每一個(gè)按鈕都要先調(diào)用 can_transition 校驗(yàn)再真正修改狀態(tài)。比如在 BUZZER_OPEN 階段如果有人搶到調(diào)用方只能往 ANSWERING 走如果倒計(jì)時(shí)結(jié)束還沒人搶則回到 QUESTION_OPEN重新讀題或直接跳過(guò)。前端大屏按鈕是否可點(diǎn)也由當(dāng)前狀態(tài)決定前后端共用同一套邏輯能擋住大部分誤操作。狀態(tài)本身要存在哪里我一般把 Redis 作為熱狀態(tài)存儲(chǔ)用match:{match_id}:status、match:{match_id}:current_question_no、match:{match_id}:current_team_id三個(gè)鍵記錄當(dāng)前比賽位置。不用數(shù)據(jù)庫(kù)的原因是大屏端會(huì)頻繁查詢狀態(tài)每個(gè)搶答、倒計(jì)時(shí)都要讀數(shù)據(jù)庫(kù)扛不住這種頻率。但 Redis 必須能恢復(fù)每次開賽前把 match_sessions 表里的 status 重置成 CREATED服務(wù)器重啟后從表里讀回狀態(tài)再根據(jù) answer_records 里最后一條已經(jīng) SCORED 的記錄回填 current_question_no 和 current_team_id?；謴?fù)時(shí)回到“上一題已評(píng)分、下一題未開”的位置主持人繼續(xù)往下走就行。參數(shù)說(shuō)明狀態(tài)值建議用英文大寫不要用中文。日志、WebSocket 消息、埋點(diǎn)事件全用同一套枚舉排查問(wèn)題時(shí) grep 一下就能對(duì)齊。2.3 選型理由為什么是 WebSocket 而不是 HTTP 輪詢知識(shí)競(jìng)賽系統(tǒng)的實(shí)時(shí)性要求和普通后臺(tái)不一樣。倒計(jì)時(shí)要每秒更新?lián)尨鹨趲资撩雰?nèi)廣播比分變化要同時(shí)打到所有屏幕上。如果大屏用 HTTP 輪詢每 1 秒請(qǐng)求一次遇到現(xiàn)場(chǎng) Wi-Fi 抖動(dòng)就會(huì)出現(xiàn)倒計(jì)時(shí)卡頓搶答更矛盾輪詢間隔越短服務(wù)器壓力越大間隔太長(zhǎng)又搶不準(zhǔn)。所以比賽信令必須走 WebSocket長(zhǎng)連接建立后服務(wù)端主動(dòng)推送客戶端不需要反復(fù)發(fā)起請(qǐng)求。對(duì)比項(xiàng)HTTP 輪詢WebSocket倒計(jì)時(shí)精度受請(qǐng)求間隔限制誤差 1 秒以上服務(wù)端按狀態(tài)推送誤差可控在毫秒級(jí)服務(wù)端壓力無(wú)變化也要周期請(qǐng)求有事件才推送空閑無(wú)流量搶答反饋至少一個(gè)請(qǐng)求往返一次廣播覆蓋所有端實(shí)現(xiàn)復(fù)雜度低需要處理連接管理和斷線重連我選擇 FastAPI WebSocket 做信令層原因是 Python 的 async 模型適合大量長(zhǎng)連接代碼也容易讀。下面是最小可運(yùn)行的 WebSocket 廣播服務(wù)from fastapi import FastAPI, WebSocket, WebSocketDisconnect app FastAPI() class ConnectionManager: def __init__(self): self.connections: list[WebSocket] [] async def connect(self, ws: WebSocket): await ws.accept() self.connections.append(ws) async def broadcast(self, message: dict): for ws in self.connections[:]: try: await ws.send_json(message) except Exception: self.connections.remove(ws) manager ConnectionManager() app.websocket(/ws/match) async def match_socket(ws: WebSocket): await manager.connect(ws) try: while True: data await ws.receive_json() # 先收消息統(tǒng)一交給業(yè)務(wù)處理器避免客戶端直接改狀態(tài) await manager.broadcast({event: ack, payload: data}) except WebSocketDisconnect: manager.connections.remove(ws)邏輯說(shuō)明這是一個(gè)廣播中樞所有連進(jìn)來(lái)的大屏、主持人平板、裁判端都會(huì)收到同一份消息。receive_json 拿到消息后沒有直接執(zhí)行業(yè)務(wù)動(dòng)作而是把消息交給后端的 match service 統(tǒng)一處理處理完再由 manager.broadcast 把結(jié)果推送出去。這樣權(quán)限校驗(yàn)?zāi)芗衅饋?lái)客戶端偽造指令也無(wú)法直接改狀態(tài)。參數(shù)說(shuō)明實(shí)際項(xiàng)目中 WebSocket 路徑要帶上 match_id比如/ws/match/23這樣一臺(tái)服務(wù)器才能同時(shí)跑多場(chǎng)競(jìng)賽。ConnectionManager 里也應(yīng)按 match_id 分組把廣播范圍限制在同一場(chǎng)比賽內(nèi)。如果用的是 Spring Boot對(duì)應(yīng)的就是 WebSocketHandler 加會(huì)話管理用 Node.js 則用 ws 庫(kù)。選型不必糾結(jié)框架關(guān)鍵是消息協(xié)議和連接管理方式。3. 用 FastAPI PostgreSQL 落地知識(shí)競(jìng)賽系統(tǒng)后端答題與計(jì)分的核心實(shí)現(xiàn)3.1 數(shù)據(jù)庫(kù)表設(shè)計(jì)題庫(kù)、場(chǎng)次、答題記錄最少要這幾張表理解完?duì)顟B(tài)機(jī)就可以建表。先講一個(gè)常見誤區(qū)把全量題庫(kù)當(dāng)成某一場(chǎng)比賽的題目表結(jié)果比賽過(guò)程中題庫(kù)被其他人編輯現(xiàn)場(chǎng)題目跟著變。正確做法是“場(chǎng)次隔離”題目要么復(fù)制進(jìn)場(chǎng)次要么通過(guò)關(guān)聯(lián)表引用但引用時(shí)必須鎖定版本。下面是最小可用的一套表結(jié)構(gòu)。CREATE TABLE teams ( id SERIAL PRIMARY KEY, match_id INT NOT NULL REFERENCES match_sessions(id), name VARCHAR(64) NOT NULL, sort_no INT NOT NULL ); CREATE TABLE questions ( id SERIAL PRIMARY KEY, match_id INT NOT NULL REFERENCES match_sessions(id), qtype VARCHAR(16) NOT NULL, -- required / buzzer / risk content TEXT NOT NULL, options JSONB, -- 選擇題選項(xiàng)可空 correct_answer TEXT, risk_scores INT[] DEFAULT {} -- 風(fēng)險(xiǎn)題可選分值如 {10,20,30} ); CREATE TABLE match_sessions ( id SERIAL PRIMARY KEY, title VARCHAR(128) NOT NULL, status VARCHAR(16) NOT NULL DEFAULT CREATED, current_question_no INT NOT NULL DEFAULT 0, started_at TIMESTAMPTZ ); CREATE TABLE answer_records ( id SERIAL PRIMARY KEY, match_id INT NOT NULL, question_id INT NOT NULL, team_id INT, score_change INT NOT NULL DEFAULT 0, status VARCHAR(16) NOT NULL, -- SCORED / REJECTED / APPEALED reason TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT now() );邏輯說(shuō)明teams 表掛了 match_id一場(chǎng)比賽一組隊(duì)伍questions 表同樣掛 match_id保證每場(chǎng)比賽的題目是獨(dú)立副本。match_sessions 表里的 status 和 current_question_no 會(huì)在 Redis 里緩存熱數(shù)據(jù)這里保留一份用于賽后歸檔和異?；謴?fù)。answer_records 是計(jì)分流水score_change 允許負(fù)數(shù)status 區(qū)分正常計(jì)分、無(wú)效搶答和申訴記錄。參數(shù)說(shuō)明risk_scores 字段用 PostgreSQL 數(shù)組保存比如{10,20,30}風(fēng)險(xiǎn)題一般不會(huì)超過(guò) 10 檔用數(shù)組最簡(jiǎn)單。如果題目是選擇題options 用 JSONB 存選項(xiàng)數(shù)組判斷時(shí)再用 correct_answer 去比對(duì)。如果答案要支持圖片建議不要存二進(jìn)制把圖片放到對(duì)象存儲(chǔ)字段里存 URL。如果要支持多次復(fù)用同一題庫(kù)我建議再加一個(gè) question_bank 表和一個(gè) match_questions 關(guān)聯(lián)表比賽創(chuàng)建時(shí)批量把 question_bank 里的題目復(fù)制到場(chǎng)次。復(fù)制時(shí)保留 source_question_id這樣現(xiàn)場(chǎng)臨時(shí)加題能快速定位原題又不影響已經(jīng)開始的比賽。千萬(wàn)別讓引擎在運(yùn)行時(shí)去實(shí)時(shí)讀題庫(kù)賽題在開賽那一刻就應(yīng)該被“凍結(jié)”在比賽場(chǎng)次里。3.2 搶答模塊的并發(fā)控制Redis SETNX 與數(shù)據(jù)庫(kù)兜底搶答是知識(shí)競(jìng)賽系統(tǒng)里最不能出錯(cuò)的模塊。兩個(gè)選手同時(shí)按下按鈕網(wǎng)絡(luò)請(qǐng)求到達(dá)后端的先后可能有細(xì)微差別但最后只能有一個(gè)隊(duì)伍搶到。初學(xué)者的做法是“先查詢 current_team_id 是否為空再更新”這個(gè)操作在并發(fā)下必然翻車兩個(gè)請(qǐng)求都查到空然后都執(zhí)行更新結(jié)果后到的覆蓋先到的。常見做法是用 Redis 的原子寫入實(shí)現(xiàn)“只有第一次寫才成功”。import redis r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def try_buzz(match_id: int, team_id: int) - bool: key fmatch:{match_id}:buzzer # SET NX 保證 key 不存在時(shí)才能寫入EX 5 是兜底防止主持人沒及時(shí)處理鎖死 ok r.set(key, team_id, nxTrue, ex5) return bool(ok)邏輯說(shuō)明第一個(gè)請(qǐng)求執(zhí)行 SET 時(shí) key 不存在Redis 寫入成功并返回 True第二個(gè)請(qǐng)求執(zhí)行時(shí) key 已經(jīng)存在哪怕請(qǐng)求只晚 1 毫秒也會(huì)返回 False。這就是“先到先得”的可靠實(shí)現(xiàn)。EX 5 設(shè)置了過(guò)期時(shí)間防止搶答成功后主持人沒有在 5 秒內(nèi)切換到作答階段導(dǎo)致下一道題無(wú)法搶答。具體秒數(shù)可以調(diào)整常見是 3 到 5 秒。如果沒有 Redis也可以用數(shù)據(jù)庫(kù)行鎖做兜底UPDATE match_sessions SET current_buzzer_team_id 1 WHERE id 123 AND current_buzzer_team_id IS NULL RETURNING id;說(shuō)明這條語(yǔ)句利用 PostgreSQL 的行鎖只有一個(gè)事務(wù)能把 current_buzzer_team_id 從 NULL 變成非 NULL。但它的缺點(diǎn)是所有未搶到的請(qǐng)求都要等鎖判斷可能產(chǎn)生阻塞。所以生產(chǎn)環(huán)境建議 Redis 做入口數(shù)據(jù)庫(kù)只保存最終結(jié)果。搶答成功后系統(tǒng)把 team_id 寫進(jìn) answer_records并把狀態(tài)從 BUZZER_OPEN 推成 ANSWERING。另外要強(qiáng)調(diào)搶答鎖不代表答題有效?，F(xiàn)場(chǎng)經(jīng)常有選手搶早、誤觸所以 try_buzz 只是搶答資格裁判隨后還要在控制臺(tái)點(diǎn)“有效”或“無(wú)效”。如果無(wú)效要做兩步清 Redis 鎖并把這條搶答事件標(biāo)記為 REJECTED。如果直接清鎖可能導(dǎo)致同一道題下兩個(gè)隊(duì)都看到自己“搶到了”大屏很混亂。正確做法是保留“已搶到但無(wú)效”的狀態(tài)下一道題再重新開鎖。注意鎖的過(guò)期時(shí)間不要設(shè)置太長(zhǎng)現(xiàn)場(chǎng)一旦出現(xiàn)“選手搶到了但主持人沒看見”的爭(zhēng)議最有效的處理方式是立刻由裁判手動(dòng)復(fù)位而不是等鎖自動(dòng)過(guò)期。3.3 計(jì)分服務(wù)把裁判動(dòng)作變成可追溯的事件流計(jì)分模塊最容易做的就是“把某個(gè)隊(duì)伍總分加 10 分”看似簡(jiǎn)單實(shí)際后患無(wú)窮。比如裁判發(fā)現(xiàn)加錯(cuò)了要把總分減回去直接改總分字段那這個(gè)分?jǐn)?shù)是怎么來(lái)的就說(shuō)不清了。正確的做法是所有比分變化都追加一條事件記錄總分由事件流聚合出來(lái)。下面是一個(gè)最小的計(jì)分服務(wù)實(shí)現(xiàn)。def score_answer(match_id: int, question_id: int, team_id: int, score_change: int, reason: str) - int: # 1. 寫入計(jì)分流水 insert_answer_record(match_id, question_id, team_id, score_change, SCORED, reason) # 2. 聚合該隊(duì)當(dāng)前總分 total get_team_score(match_id, team_id) # 3. 更新展示用的分?jǐn)?shù)緩存 update_team_score_cache(match_id, team_id, total) return total def get_team_score(match_id: int, team_id: int) - int: return db.query( SELECT COALESCE(SUM(score_change), 0) FROM answer_records WHERE match_id %s AND team_id %s AND status SCORED, (match_id, team_id) )邏輯說(shuō)明score_answer 第一步寫流水第二步聚合第三步更新緩存。這樣改判時(shí)不需要修改任何歷史記錄只需插入一條 score_change 為負(fù)數(shù)的記錄比如之前加 10 分現(xiàn)在要改成不加分就插入 score_change -10reason 寫“改判重復(fù)計(jì)分”。總分自動(dòng)回到正確值現(xiàn)場(chǎng)觀眾也能從事件流里看到每一次變化。參數(shù)說(shuō)明status 字段要區(qū)分 SCORED 和 REJECTED。裁判判定搶答無(wú)效時(shí)不改變分?jǐn)?shù)但事件流要保持記錄。REJECTED 記錄不會(huì)進(jìn)入 SUM 聚合但也會(huì)被寫入流水方便復(fù)盤“為什么這道題沒有計(jì)分”。reason 字段不允許為空裁判填中文不要緊關(guān)鍵是強(qiáng)制填寫避免事后無(wú)法追溯。為什么不用 Redis 直接給隊(duì)伍加分因?yàn)?Redis 緩存可能丟失、可能過(guò)期一旦與數(shù)據(jù)庫(kù)不一致現(xiàn)場(chǎng)的分歧無(wú)法裁決。Redis 只作為熱數(shù)據(jù)展示最終分?jǐn)?shù)永遠(yuǎn)以數(shù)據(jù)庫(kù)聚合結(jié)果為準(zhǔn)。當(dāng)大屏比分和裁判手里的紙面記錄不一致時(shí)以 answer_records 為準(zhǔn)這是底線。4. 大屏端與選手端的實(shí)時(shí)同步WebSocket 消息格式與斷線重連4.1 消息協(xié)議設(shè)計(jì)這 5 類消息就夠覆蓋整場(chǎng)競(jìng)賽前后端通過(guò) WebSocket 傳遞消息時(shí)最怕的是沒有格式約定前端拼錯(cuò)一個(gè)字段后端就解析不到。我一般只定義 5 類核心消息復(fù)雜場(chǎng)景盡量在 payload 里擴(kuò)展避免每個(gè)功能都發(fā)明一種消息結(jié)構(gòu)。event觸發(fā)方作用match_status后端推送通知所有端當(dāng)前賽制階段比如進(jìn)入搶答窗口question_open后端推送下發(fā)當(dāng)前題目?jī)?nèi)容大屏展示題干buzzer_result后端推送廣播哪個(gè)隊(duì)搶到附帶服務(wù)端毫秒時(shí)間戳score_update后端推送廣播某個(gè)隊(duì)伍總分變化timer_sync后端定時(shí)推送校正大屏本地倒計(jì)時(shí)下面是一條 buzzer_result 的完整消息{ event: buzzer_result, payload: { match_id: 23, question_no: 4, team_id: 3, server_ts: 1720000000123, elapsed_ms: 287 } }邏輯說(shuō)明server_ts 是后端收到搶答請(qǐng)求那一刻的 Unix 毫秒時(shí)間戳elapsed_ms 是選手端從看到題目到按下按鈕的本地耗時(shí)僅作為現(xiàn)場(chǎng)展示參考不作為仲裁依據(jù)。前端大屏收到消息后把 team_id 的隊(duì)伍顯示在搶答第一位同時(shí)播放一聲短蜂鳴現(xiàn)場(chǎng)才看得清晰。參數(shù)說(shuō)明server_ts 必須由服務(wù)端生成不能信任客戶端上報(bào)。因?yàn)槭謾C(jī)端時(shí)間可能慢幾十毫秒如果按客戶端時(shí)間排序就會(huì)發(fā)生“先按的排到后面去”。question_no 用于前端確認(rèn)當(dāng)前題目編號(hào)防止消息亂序?qū)е麓箢}號(hào)對(duì)應(yīng)錯(cuò)。match_status 和 timer_sync 可以合并但分開更好排錯(cuò)?，F(xiàn)場(chǎng)主持人說(shuō)“大屏沒進(jìn)搶答”你一看日志只有 question_open 沒有 match_status基本就是后端狀態(tài)機(jī)沒切過(guò)去。4.2 大屏端渲染邏輯倒計(jì)時(shí)、搶答狀態(tài)、得分動(dòng)畫大屏端不應(yīng)該自己維護(hù)一套比賽狀態(tài)它只負(fù)責(zé)“收到消息后更新界面”。把所有 event 放進(jìn)一個(gè) socket.onmessage 回調(diào)里按類型分發(fā)。下面用 Vue 3 的組合式寫法示意import { reactive } from vue const state reactive({ phase: WAIT, // WAIT / READ_QUESTION / BUZZER / ANSWERING / SCORING currentQuestion: null, countdown: 0, teams: [], lastBuzzer: null }) socket.onmessage (e) { const msg JSON.parse(e.data) if (msg.event match_status) { state.phase msg.payload.phase } else if (msg.event question_open) { state.currentQuestion msg.payload state.phase READ_QUESTION } else if (msg.event buzzer_result) { state.lastBuzzer msg.payload state.phase ANSWERING } else if (msg.event score_update) { const team state.teams.find(t t.id msg.payload.team_id) if (team) team.score msg.payload.score } else if (msg.event timer_sync) { state.countdown msg.payload.seconds } }邏輯說(shuō)明phase 是大屏 UI 的總開關(guān)。開題后大屏收到 question_open切到讀題 phase后端廣播 match_status 進(jìn)入 BUZZER大屏才顯示搶答按鈕狀態(tài)有人搶到buzzer_result 把它置為 ANSWERING此時(shí)秒表停止開始讀選手的答案。所有狀態(tài)都以服務(wù)端推送為準(zhǔn)大屏本地不產(chǎn)生任何比賽狀態(tài)。這里有一個(gè)必須注意的點(diǎn)倒計(jì)時(shí)不要只靠 timer_sync 一條條推送。因?yàn)榫W(wǎng)絡(luò)延遲會(huì)導(dǎo)致倒計(jì)時(shí)看起來(lái)卡頓。常見做法是客戶端本地每秒減 1但每 30 秒或每次進(jìn)入新階段時(shí)用服務(wù)端推送的 timer_sync 校準(zhǔn)一次。如果本地剩余秒數(shù)和 timer_sync 偏差超過(guò) 2 秒直接以服務(wù)端為準(zhǔn)。參數(shù)說(shuō)明score_update 推送的是總分不是增量。為什么這樣設(shè)計(jì)因?yàn)閿嗑€重連后大屏拉取快照需要的是絕對(duì)值增量會(huì)讓重連后的頁(yè)面出現(xiàn)重復(fù)累計(jì)。雖然推送總分消息稍大但幾支隊(duì)伍的 JSON 體量可以忽略換來(lái)的是狀態(tài)的一致性。4.3 斷線重連與對(duì)時(shí)避免“我說(shuō)搶到了你沒顯示”的翻車現(xiàn)場(chǎng)網(wǎng)絡(luò)不會(huì)永遠(yuǎn)穩(wěn)定主辦方的 Wi-Fi 通常是一屋子手機(jī)搶帶寬。客戶端一旦斷線重連成功后必須第一時(shí)間和服務(wù)端對(duì)齊狀態(tài)否則會(huì)出現(xiàn)主持人平板已經(jīng)顯示 A 隊(duì)搶到大屏還停在搶答界面。我的做法是讓客戶端重連后先發(fā)一條 join 消息服務(wù)端把 snapshot 推給客戶端。{ event: snapshot, payload: { match_id: 23, status: ANSWERING, current_question_no: 4, current_team_id: 2, countdown: 12, scores: {1: 120, 2: 80, 3: 95} } }邏輯說(shuō)明snapshot 里的 status 和 current_team_id 能讓剛連上的大屏立刻回到正確畫面。如果客戶端重連時(shí)搶答鎖已經(jīng)被 Redis 占用current_team_id 不為空大屏就不會(huì)出現(xiàn)“所有人都可以搶”的錯(cuò)誤狀態(tài)。countdown 是當(dāng)前階段的剩余秒數(shù)防止重連后從頭倒計(jì)時(shí)。關(guān)于對(duì)時(shí)最干凈的方案是所有客戶端不做時(shí)鐘仲裁只顯示服務(wù)端給的時(shí)間戳。搶答按鈕按下客戶端上報(bào)一個(gè) local_ts但服務(wù)端廣播的是 server_ts。裁判判斷“是否搶跑”時(shí)只看 server_ts 與開題 question_open 消息里的 ts 差值。如果差值小于設(shè)定閾值比如 500 毫秒視為搶跑由裁判人工裁定是否取消資格。這個(gè)閾值要在配置里可調(diào)不同主持人的節(jié)奏不一樣。5. 知識(shí)競(jìng)賽系統(tǒng)現(xiàn)場(chǎng)執(zhí)行中的常見問(wèn)題排查這 5 個(gè)坑我基本每次都遇到5.1 搶答明明是先到的計(jì)分的卻是后隊(duì)時(shí)鐘偏差現(xiàn)象比賽現(xiàn)場(chǎng)最常見的一幕A 隊(duì)選手手速明顯更快大屏顯示的卻是 B 隊(duì)搶到現(xiàn)場(chǎng)觀眾立刻起哄。原因系統(tǒng)用客戶端本機(jī)時(shí)間來(lái)判斷先后就會(huì)出這種問(wèn)題。兩臺(tái)手機(jī)的系統(tǒng)時(shí)間不經(jīng)過(guò)同步可能相差幾十毫秒甚至數(shù)百毫秒而這個(gè)量級(jí)足以顛倒搶答順序。另一個(gè)隱藏原因是前端按鈕做了重試同一個(gè)選手快速按了兩下第二次請(qǐng)求因?yàn)榫W(wǎng)絡(luò)重發(fā)反而先到達(dá)后端。解決后端收到搶答請(qǐng)求時(shí)立即打上服務(wù)端時(shí)間戳 server_ts所有判斷都以這個(gè)時(shí)間為準(zhǔn)?？蛻舳松蠄?bào)的時(shí)間只存在事件里不作排序依據(jù)。同時(shí)給搶答按鈕加“請(qǐng)求中”狀態(tài)在服務(wù)端響應(yīng)前禁止第二次點(diǎn)擊如果確實(shí)因?yàn)榫W(wǎng)絡(luò)重發(fā)導(dǎo)致重復(fù)請(qǐng)求后端通過(guò) Redis 鎖的 SET NX 直接過(guò)濾掉第二次。這樣即使網(wǎng)絡(luò)亂序結(jié)果也能穩(wěn)定。5.2 風(fēng)險(xiǎn)題分值改完不生效緩存與權(quán)限邊界現(xiàn)象主持人把某個(gè)風(fēng)險(xiǎn)題的分值從 20 分改成 30 分選手答對(duì)后界面還是加了 20 分后臺(tái)日志里也找不到這次修改記錄。原因風(fēng)險(xiǎn)題的分值被配置在了“題型全局規(guī)則”里而不是“本道題”上。ScoringRule.base_score 只是全局默認(rèn)值選手開題時(shí)選擇的 30 分沒有傳進(jìn)計(jì)分服務(wù)或者計(jì)分服務(wù)優(yōu)先讀取了全局規(guī)則。解決風(fēng)險(xiǎn)題的分值應(yīng)該存到 questions.risk_scores 里開題時(shí)前端提交 selected_score后端校驗(yàn)這個(gè)值在 risk_scores 數(shù)組中再把它作為 score_change 的絕對(duì)值傳給計(jì)分服務(wù)。修改分值時(shí)要走“場(chǎng)次題目更新”接口同時(shí)刷新 Redis 緩存里的題目快照不能只改數(shù)據(jù)庫(kù)。每次修改都寫入操作日志現(xiàn)場(chǎng)一查就能知道是配置層還是展示層出了問(wèn)題。5.3 大屏卡死但后臺(tái)正常前端循環(huán)里做異步請(qǐng)求現(xiàn)象倒計(jì)時(shí)進(jìn)行到一半大屏停住不動(dòng)但主持人平板還能正常切題后臺(tái)也能看到答案記錄。原因大屏組件里寫了一個(gè) setInterval每秒鐘請(qǐng)求一次比分接口同時(shí) WebSocket 消息也在更新同一個(gè) state。頻繁的異步請(qǐng)求會(huì)讓瀏覽器不斷進(jìn)入渲染阻塞尤其是一次請(qǐng)求還沒返回下一次又發(fā)出界面就會(huì)越卡越死。另一個(gè)常見原因是 score_update 和 timer_sync 同時(shí)修改同一個(gè)對(duì)象觸發(fā)了 Vue 的無(wú)限循環(huán)更新。解決大屏原則上只使用 WebSocket 一條數(shù)據(jù)通道不在 setInterval 里輪詢 REST 接口。倒計(jì)時(shí)本地更新每 30 秒校準(zhǔn)一次如果業(yè)務(wù)上確實(shí)需要輪詢頻率不要低于 5 秒并且用 requestIdleCallback 避開渲染高峰期。把所有 UI 狀態(tài)統(tǒng)一放進(jìn)一個(gè) state 對(duì)象避免多個(gè)回調(diào)各改各的字段造成響應(yīng)式依賴混亂。5.4 導(dǎo)出成績(jī)亂碼CSV 的編碼問(wèn)題現(xiàn)象比賽結(jié)束后導(dǎo)出成績(jī)主辦方用 Excel 打開全是亂碼中文變成“”現(xiàn)場(chǎng)領(lǐng)導(dǎo)看著很尷尬。原因后端把 CSV 文件寫成了 UTF-8 無(wú) BOM。Excel 對(duì) CSV 編碼判斷很弱默認(rèn)按系統(tǒng)區(qū)域編碼解析在 Windows 上最常見就是亂碼。解決寫 CSV 文件時(shí)使用帶 BOM 的 UTF-8 編碼。Python 里直接用open(path, w, encodingutf-8-sig)Node.js 里在文件開頭寫入\ufeff。還有一個(gè)順手就能做的調(diào)整字段間的分隔符統(tǒng)一用逗號(hào)如果字段內(nèi)容包含逗號(hào)用雙引號(hào)包裹并轉(zhuǎn)義內(nèi)部引號(hào)。導(dǎo)出后先自己在 Excel 里打開檢查一遍再發(fā)給主辦方這個(gè)習(xí)慣能幫你躲過(guò)大部分低級(jí)投訴。5.5 現(xiàn)場(chǎng)臨時(shí)加題題庫(kù)與場(chǎng)次的關(guān)聯(lián)設(shè)計(jì)現(xiàn)象比賽快開始前一小時(shí)主辦方發(fā)來(lái) 10 道新題導(dǎo)進(jìn)去之后前排大屏顯示新題主持人后臺(tái)卻還是舊題開賽后題目順序也亂了。原因題目數(shù)據(jù)同時(shí)存在于全局題庫(kù)和場(chǎng)次題目表導(dǎo)入時(shí)只寫了題庫(kù)表沒有同步場(chǎng)次題目表或者同步了但場(chǎng)次里的 current_question_no 指針沒有校準(zhǔn)導(dǎo)致題目列表重排后正在答的那一題被推到后面。解決臨時(shí)加題必須統(tǒng)一走“場(chǎng)次題目導(dǎo)入”接口導(dǎo)入后校驗(yàn)場(chǎng)次題目列表并把所有重復(fù)題目的 question_id 也更新干凈。如果場(chǎng)次已經(jīng)進(jìn)行到一半重置題目順序時(shí)要記錄當(dāng)時(shí)的 current_question_no 在原順序中的題目 ID導(dǎo)入完成后把指針重新定位到同一個(gè)題目 ID。加題前最好先暫停比賽狀態(tài)機(jī)加完再恢復(fù)避免導(dǎo)入過(guò)程觸發(fā)狀態(tài)流轉(zhuǎn)。6. 進(jìn)階技巧把整場(chǎng)競(jìng)賽變成可復(fù)盤的“事件流”存檔前面所有模塊都在強(qiáng)調(diào)事件記錄其實(shí)它們本該是同一套東西。從比賽開始到結(jié)束每一次開題、搶答、計(jì)分、改判都是一個(gè)不可變的事件。把同一場(chǎng)比賽的全部事件按全局序號(hào)存下來(lái)賽后就能完整回放這是知識(shí)競(jìng)賽系統(tǒng)最有價(jià)值的進(jìn)階能力。我習(xí)慣在數(shù)據(jù)庫(kù)加一張 match_events 表字段很簡(jiǎn)單seq、match_id、type、payload、server_ts。seq 是這場(chǎng)比賽里的全局遞增序號(hào)不依賴數(shù)據(jù)庫(kù)自增主鍵因?yàn)榛胤艜r(shí)要按它排序。payload 直接用 JSONB把搶答、計(jì)分、狀態(tài)遷移的細(xì)節(jié)都塞進(jìn)去。舉個(gè)例子一次搶答事件是下面這個(gè)樣子{ seq: 17, type: buzzer_press, server_ts: 1720000000123, match_id: 23, team_id: 3, payload: {question_no: 4, valid: true} }回放邏輯很簡(jiǎn)單從 seq0 的空狀態(tài)開始按順序把每一條事件應(yīng)用到一個(gè)和線上完全相同的狀態(tài)機(jī)里就能還原出當(dāng)時(shí)每一個(gè)后臺(tái)頁(yè)面的顯示。誰(shuí)在第幾題搶答、裁判有沒有改判、比分在哪個(gè)時(shí)間點(diǎn)變化全部可以逐條核對(duì)。這個(gè)能力平時(shí)用不上一旦主辦方賽后質(zhì)疑“最后一輪分值怎么不對(duì)”它就是唯一的后悔藥。我在每次比賽結(jié)束后會(huì)導(dǎo)出一份 JSONL 存檔文件名帶上比賽 ID 和日期和成績(jī)表放在同一個(gè)目錄。這個(gè)習(xí)慣救過(guò)我很多次也讓我越來(lái)越相信知識(shí)競(jìng)賽系統(tǒng)真正值錢的不是炫酷的大屏動(dòng)畫而是讓每個(gè)現(xiàn)場(chǎng)決策都有據(jù)可查。把事件流歸檔變成標(biāo)準(zhǔn)動(dòng)作比多寫幾個(gè)功能模塊更值得投入。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取