简介《局域网考试系统终版》面向学校教师与机房管理人员服务于局域网环境下的课堂测验、校园考试与电子化考核重点解决出卷耗时、阅卷繁琐、成绩统计分散及考试安全控制等问题。压缩包为 rar 格式约 7.58MB上游未提供有效文件总数与类型明细从描述可知包含系统安装部署及使用说明类内容便于在封闭网络内完成部署。该资源已有 207 人学习或下载。功能层面涵盖试题库管理、自定义试卷、客观题自动阅卷与成绩报告生成并支持考试时间、难度、题型和防作弊策略设置局域网运行可减少外部干扰答题数据还可用于学情分析。整体界面较简洁适合需要快速搭建在线考核环境、关注考试公平性与教学反馈的教师和机房管理员参考使用。1. 一套跑在断网机房里的局域网考试系统解决的是“老师不敢关机”这件事机房的外网一断很多在线考试平台就没法用了这套局域网考试系统反过来外网断了才是它真正能用的时候。教师机起一个服务学生机装一个客户端只要在同一个交换机下客户端自己就能找到服务端导入题库、组卷、开考、锁屏、实时看谁切了窗口、断线了接着答、交完自动判分、成绩导出表格。它面向的是没外网、机器数三十到一百五十台、监考老师只有一两个的校内机房和培训教室。对开发者来说这份源码的价值不在功能列表而在它把 C/S 项目里最容易含糊处理的三件事写清楚了局域网内怎么自动发现服务端、考试中途断线怎么把答案保存回来、客观题判分怎么做到选项顺序变了也不出错。一台电脑就能模拟服务端加两台客户端改题型和判分规则都有明确改动位置。2. 架构与目录三个进程怎么在一台教师机上跑起来这套系统的部署形态很朴素教师机同时扮演 Web 管理端和 API 服务端学生机只跑桌面客户端。没有 Docker没有 Redis也没有消息队列整套东西塞进一个文件夹拷到 U 盘就能带去机房。这种“故意做得简陋”的设计不是偷懒而是因为考场环境的约束比开发环境苛刻得多——没有运维没有外网装依赖出了问题得由监考老师自己重启。所以架构上的每一个选择都要能回答一个问题出问题时现场的人能不能自己处理2.1 技术选型Python 服务端 PySide6 客户端 浏览器管理端服务端用 FastAPI uvicorn数据落 SQLite实时通信用 WebSocket学生端用 PySide6 做全屏桌面窗口管理端是几个纯 HTML 页面用 fetch 调 API不开前端构建工具。这套组合的取舍很明确层次选型承担的事换掉的代价服务端FastAPI uvicorn组卷、答题收发、判分、WebSocket 推送换 Java 需要装 JDK机房重装系统麻烦存储SQLite 单文件题库、试卷、答卷、成绩换 MySQL 要多装一个服务现场没人会调学生端PySide6 桌面窗口全屏锁屏、切屏检测、本地缓存换纯浏览器做不了切屏检测AltF4 也拦不住管理端原生 HTML fetch导题库、开考、看实时状态、导成绩换 Vue 要 node 环境打包体积翻倍为什么要桌面客户端而不是纯 B/S这是很多人第一个会问的问题。浏览器里能做全屏但拦不住 AltF4、拦不住 Win 键、更拿不到“学生切到别的窗口”这个事件。机房里最常见的一种作弊就是切到记事本跟旁边的人对答案只有桌面端能用focusOut和窗口置顶把这条路堵住。而管理端反而是纯网页更合适——老师用自己的笔记本打开http://教师机IP:8000/admin就能看实时状态不用再装一份软件。2.2 目录结构一次拉起来要动的三个进程先把目录结构摆出来后面讲代码时就能对上位置lan-exam/ ├── server/ │ ├── app.py # FastAPI 入口挂路由和 WebSocket │ ├── exam_state.py # 考试状态机与状态守卫 │ ├── paper.py # 组卷、抽题、选项乱序 │ ├── grading.py # 客观题判分 │ ├── db.py # SQLite 连接与建表 │ ├── discovery.py # UDP 广播应答监听 25555 │ └── static/ # 管理端页面纯 HTML fetch ├── client/ │ ├── main.py # PySide6 客户端入口 │ ├── login.py # 登录与选择考试 │ ├── lockwin.py # 全屏锁定窗口 切屏检测 │ ├── answer_cache.py # 本地答题缓存断线续考靠它 │ └── discovery.py # 广播找服务端 ├── data/ │ ├── exam.db # SQLite题库/试卷/答卷都在这 │ └── paper_template.xlsx # 题库导入模板 └── requirements.txt启动只需要两条命令教师机一条、学生机一条# 教师机装依赖并起服务端。--host 必须是 0.0.0.0绑 127.0.0.1 学生机连不上 pip install -r requirements.txt python server/app.py --host 0.0.0.0 --port 8000 --db data/exam.db # 学生机-s 可省略省略时走 UDP 广播自动发现连不上时手动填 IP 兜底 python client/main.py -s 192.168.1.10:8000三个参数的含义值得单独说一遍。--host 0.0.0.0表示监听所有网卡如果写成默认的127.0.0.1服务端自己访问没问题学生机怎么都连不上这是新手最常遇到的第一个问题。--port 8000是 HTTP 端口UDP 发现服务固定监听 25555两者都要在教师机防火墙里放行入站。--db data/exam.db指定数据库文件路径换一场考试只要换一个 db 文件考完直接改名归档比在表里加exam_id隔离更省事也更不容易被误删。数据库文件在考试期间是独占写入的所以教师机上不要同时开两个服务端实例指向同一个 db。如果确实需要一边考试一边备份用 SQLite 的在线备份命令或者直接复制exam.db-wal和exam.db-shm三个文件别只拷主文件。2.3 考试状态机五个状态管住整场考试一场考试从建卷到归档中间会发生很多操作如果每个接口自己判断“现在能不能改卷”“现在能不能交卷”代码很快就会乱成一团。这套系统把这些判断收进一个显式状态机状态谁能推进允许的操作draft教师导入题库、编辑试卷、调整分值ready教师设置时长与开考时间等待开考running系统接收答题、下发剩余时间、记录切屏closed系统判分、导出成绩、只读查看archived教师打包归档可清理旧数据对应的守卫代码很短但把所有非法操作挡在了入口# server/exam_state.py from enum import Enum class ExamState(str, Enum): DRAFT draft # 组卷中允许改题 READY ready # 卷已定稿等开考 RUNNING running # 考试中拒绝任何改卷请求 CLOSED closed # 收卷完成答案只读 ARCHIVED archived # 归档可清理 # 只允许这几种迁移其余一律抛异常 ALLOWED { ExamState.DRAFT: {ExamState.READY}, ExamState.READY: {ExamState.RUNNING, ExamState.DRAFT}, ExamState.RUNNING: {ExamState.CLOSED}, ExamState.CLOSED: {ExamState.ARCHIVED}, ExamState.ARCHIVED: set(), } def transit(exam, target: ExamState): 任何改变考试状态的入口都必须先过这里 if target not in ALLOWED[exam.state]: raise ValueError(f非法状态迁移: {exam.state} - {target}) exam.state target exam.save()把这个表放在脑子里过一遍就能想明白它的价值考试进入 running 之后教师端“改试卷”的按钮即便被误点请求也会被transit拦下来而不是把正在考试的学生卷子改掉。这套逻辑比在每个路由里写if exam.state ! running可靠得多因为新增接口时你会本能地先调transit。提示状态机要和数据库事务放在同一层。transit里改完内存对象立刻落库别等到请求结束再统一提交否则服务端崩溃重启后会回到旧状态。3. 核心模块拆解从题库到交卷的一条完整链路这条链路是整个系统里改动最频繁的部分也是二次开发时最该先看懂的部分。它由三段组成题库怎么存、试卷怎么抽、答案怎么保存。三段之间没有强耦合改任何一段都不需要动另外两段这也是这套代码能被人反复改造的原因。3.1 数据表三张表撑起整个流程题库、试卷、答卷三张表就够没有多余的分表和中间表-- 题库一题一行选项存 JSON标准答案存字符串 CREATE TABLE question ( id INTEGER PRIMARY KEY AUTOINCREMENT, subject TEXT NOT NULL, -- 知识点组卷按它抽题 qtype TEXT NOT NULL, -- single/multi/judge difficulty INTEGER NOT NULL DEFAULT 3, -- 1-5组卷规则的权重依据 stem TEXT NOT NULL, -- 题干支持最简 markdown options TEXT NOT NULL, -- [{k:A,v:...}, ...] answer TEXT NOT NULL, -- 单选 A多选 ACD score REAL NOT NULL DEFAULT 2.0 ); -- 试卷记录考哪套、什么时候开考、考多久 CREATE TABLE exam ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, state TEXT NOT NULL DEFAULT draft, duration INTEGER NOT NULL, -- 分钟 started_at TEXT, -- 服务端时间倒计时只认它 seed INTEGER NOT NULL -- 组卷随机种子可复现同一套卷 ); -- 答卷一个学生一份answers 是 JSON增量覆盖写 CREATE TABLE answer_sheet ( id INTEGER PRIMARY KEY AUTOINCREMENT, exam_id INTEGER NOT NULL, student_no TEXT NOT NULL, answers TEXT NOT NULL DEFAULT {}, -- {12:A,15:ACD} score REAL, submitted INTEGER NOT NULL DEFAULT 0, updated_at TEXT, UNIQUE(exam_id, student_no) );answers用一整段 JSON 而不是拆成“每题一行”这个决定当时纠结过。拆行更符合范式判分时能直接按题查但代价是每次学生点一下选项就要写一行或者删一行三十台机器同时答题写入频率会高到 SQLite 扛不住。用 JSON 之后一次保存就是一次 upsert行数固定等于考生人数写入压力从“按题数”降到“按人数”这是这套系统能在单文件数据库上跑起来的关键。UNIQUE(exam_id, student_no)这个约束也不是装饰。它让 upsert 的冲突判断有索引可用同时从数据库层面挡住“同一个学号提交两份答卷”的情况——机房里真的会出现学生换机器重登、结果系统里冒出两份卷子的事故。3.2 组卷按知识点和难度抽题组卷不是随机抽一堆题而是按一个蓝图抽每个知识点、每个题型、每个难度各要几道。蓝图由教师在管理端配好存成 JSON 传给组卷函数# server/paper.py import random def build_paper(conn, blueprint, seedNone): blueprint: [{subject: 网络基础, qtype: single, difficulty: 2, count: 10}, ...] seed: 随机种子。同一个 seed 抽出来的卷子完全一样方便复现和重算 rnd random.Random(seed) picked_ids [] for rule in blueprint: rows conn.execute( SELECT id FROM question WHERE subject? AND qtype? AND difficulty?, (rule[subject], rule[qtype], rule[difficulty]), ).fetchall() ids [r[id] for r in rows if r[id] not in picked_ids] # 跨规则去重 if len(ids) rule[count]: # 题量不够就报错别静默少出题考完才发现卷子只有 47 分 raise ValueError( f{rule[subject]}/{rule[qtype]} 难度{rule[difficulty]} 题量不足 f需要 {rule[count]}实际 {len(ids)} ) picked_ids rnd.sample(ids, rule[count]) rnd.shuffle(picked_ids) # 打乱题序相邻考生拿到的题目顺序不同 return picked_ids三个细节决定这段代码在真实考场里好不好用。第一是跨规则去重如果蓝图里同时有“难度 2 抽 5 道”和“难度 3 抽 5 道”而某道题被两条规则同时命中不去重就会出现同一份卷子里重复出题。第二是题量不足直接报错而不是悄悄少抽——组卷时少两道题卷面总分就变了判分时会一堆学生分数不对查起来极其费劲。第三是shuffle打乱题序它不改变总分但能让左右两桌的学生第一题不是同一道监考压力立刻小一半。seed参数平时用不到但它是排查问题时的关键手段某场考试出问题了只要拿到当时的 seed 重新跑一遍build_paper就能复现出完全相同的卷子不用去翻日志猜当时抽了哪些题。3.3 答题落盘与断线续考每次改动都写本地断线续考是这套系统里最值得抄的一段。思路很简单答案先无条件写本地文件再异步推服务端网络恢复后只补传没成功的部分。服务端的落盘用 upsert一次短事务搞定# server/app.py节选 app.post(/api/sheet/{exam_id}/{student_no}) def save_answer(exam_id: int, student_no: str, body: AnswerIn): # 用 upsert 而不是先查后写避免两个包同时到达时插出重复行 conn.execute( INSERT INTO answer_sheet (exam_id, student_no, answers, updated_at) VALUES (?, ?, ?, datetime(now,localtime)) ON CONFLICT(exam_id, student_no) DO UPDATE SET answersexcluded.answers, updated_atexcluded.updated_at , (exam_id, student_no, json.dumps(body.answers, ensure_asciiFalse))) conn.commit()客户端那半边更关键它决定了断电时会不会丢答案# client/answer_cache.py import json, os class AnswerCache: 答题先写本地再异步推服务端。断网时本地照写网回来全量补传。 def __init__(self, path): self.path path self.data self._load() def _load(self): if os.path.exists(self.path): with open(self.path, encodingutf-8) as f: return json.load(f) return {answers: {}, synced: {}} # synced 记录已成功提交的值 def put(self, qid, value): self.data[answers][str(qid)] value self._flush() # 每次改动立刻落盘不给断电留窗口 def pending(self): # 只补传没成功过的题避免整卷重发把服务端打满 return {k: v for k, v in self.data[answers].items() if self.data[synced].get(k) ! v} def mark_synced(self, answers): self.data[synced].update(answers) self._flush() def _flush(self): tmp self.path .tmp with open(tmp, w, encodingutf-8) as f: json.dump(self.data, f, ensure_asciiFalse) os.replace(tmp, self.path) # 先写临时文件再原子替换断电不会留半截文件os.replace那行是整个文件里最不能省的一行。直接open(path, w)写正好写到一半机房跳闸文件就变成了半截 JSON下次启动解析报错学生的答案全废。先写.tmp再原子替换最坏情况是丢掉最后一次改动而不是丢掉整份答卷。pending()用值比较而不是打时间戳是为了处理另一种情况学生先选了 A、提交成功后来又改成 C、提交失败此时synced里是 A、answers里是 C两者不同补传会正确带上 C。如果改用时间戳判断边界条件会多出一堆。注意本地缓存文件放在用户目录而不是客户端安装目录。机房机器往往有还原卡或者权限限制往 Program Files 下写文件会失败而失败是静默的考完才发现一份都没存下来。4. 客户端与监考把“防作弊”做成可配置的开关客户端要做的事只有三件找到服务端、把考试界面钉在屏幕上、把答案安全送出去。三件事都不难难的是每件都有大量例外情况——找不到、钉不住、送不出。这一段把三块代码拆开看顺便说说哪些做法在真实机房里会出事。4.1 UDP 广播发现服务端让学生手动输 IP 是不现实的一个班五十个人光报 IP 就能耗掉十分钟。所以服务端起一个 UDP 应答器客户端往广播地址发一句暗号谁应答就连谁# server/discovery.py import socket, json def serve_discovery(port25555, http_port8000): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.bind((, port)) # 空字符串表示所有网卡都收 while True: data, addr sock.recvfrom(1024) if data.strip() bLAN_EXAM_WHO: # 应答里带上 HTTP 端口客户端不用把端口写死 resp json.dumps({service: lan-exam, port: http_port}).encode() sock.sendto(resp, addr)客户端这边要处理一个容易被忽略的问题教师机如果是双网卡一个接机房交换机一个接办公网只往255.255.255.255发广播包可能从错误的那张网卡出去学生机永远收不到应答。稳妥的写法是遍历本机所有网卡的广播地址各发一次# client/discovery.py import socket, json def find_server(timeout2.0): sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.settimeout(timeout) # 常见做法是按网卡枚举广播地址逐个发一轮避免多网卡只走错的那张 for target in (255.255.255.255, 192.168.1.255): try: sock.sendto(bLAN_EXAM_WHO, (target, 25555)) except OSError: pass try: data, addr sock.recvfrom(1024) info json.loads(data) return fhttp://{addr[0]}:{info[port]} # 用包的源 IP别用应答里的 IP except socket.timeout: return None返回地址用的是addr[0]也就是数据包的源 IP而不是应答体里的字段。原因是 NAT 或者多网卡环境下服务端自己认为自己叫某个 IP客户端却只能通过另一个 IP 访问它用源 IP 永远是对的。4.2 锁屏窗口与切屏上报锁屏窗口的核心不是“全屏”而是“关不掉”和“抢得回来”# client/lockwin.py from PySide6.QtCore import Qt, Signal, QTimer from PySide6.QtWidgets import QWidget class LockWindow(QWidget): switch_away Signal(int) # 切屏次数交给主窗口上报服务端 def __init__(self): super().__init__() # 无边框 置顶 不进任务栏普通 AltF4 关不掉 self.setWindowFlags(Qt.FramelessWindowHint | Qt.WindowStaysOnTopHint | Qt.Tool) self.setWindowState(Qt.WindowFullScreen) self._away 0 self._watch QTimer(self) self._watch.timeout.connect(self._check_focus) self._watch.start(1000) # 一秒一次够用且不吃 CPU def _check_focus(self): if not self.isActiveWindow(): self._away 1 self.switch_away.emit(self._away) self.activateWindow() # 立刻抢回前台别让学生在上面点东西 def closeEvent(self, e): e.ignore() # 交卷前不允许关闭Qt.Tool这个标志的作用是不在任务栏留图标学生没法通过任务栏右键关掉它代价是它对某些系统级快捷键依然无解所以真要锁死还得挂键盘钩子。我的建议是别在源码里默认挂全局钩子——很多安全软件会把键盘钩子当可疑行为直接拦掉甚至卸载客户端机房里五十台机器一起弹窗场面很难收拾。更实际的做法是把“是否启用严格锁屏”做成教师端的一个开关按考场严格程度自己选。切屏次数通过信号往外抛主窗口拿到后立刻往服务端发一条记录同时在本地留一份。教师端页面上按次数排序谁切了七八次一目了然。这里要注意的是别把上报做成同步阻塞——网络卡一下界面就跟着卡一下学生会以为程序死了。4.3 交卷、判分与实时监考判分只做客观题逻辑集中在grading.py。这段代码看着简单但多选判分规则是最容易和老师吵起来的地方所以规则要写死并且可解释# server/grading.py def grade_one(question, user_answer): 客观题判分多选错选不得分少选给一半可按考试要求改 std set((question[answer] or ).replace(,, ).strip()) got set((user_answer or ).replace(,, ).strip()) if not got: return 0.0 if question[qtype] in (single, judge): return question[score] if got std else 0.0 # 多选全对满分少选且没选错给一半错选 0 分 if got std: return question[score] if got std: return round(question[score] * 0.5, 1) return 0.0用set而不是字符串直接比较解决的是“标准答案是 AC学生选了 CA”被判错的问题。这个问题在选项乱序之后会集中爆发——乱序改变了选项的显示顺序学生的答案串和标准答案串天然不同序字符串比较必挂。实时监考走 WebSocket学生端每次作答、切屏、心跳都往服务端推服务端再广播给所有在线教师端。教师端页面上就是一张表学号、进度、切屏次数、在线状态五秒刷新一次就够不用做得多花哨。真正有用的信息只有两条谁掉线了谁切屏了。5. 避坑与排查只在真机房才会炸的五个问题开发环境里跑通不代表考场里能用。下面这五个问题全是把系统搬到真实机房之后才暴露出来的每一个都值得在部署前先检查一遍。5.1 交卷高峰与数据库锁现象考试最后三分钟服务端日志开始刷sqlite3.OperationalError: database is locked部分学生界面显示“交卷失败”重试还是失败。开发时两三台机器测试完全正常。原因SQLite 默认同一时刻只允许一个写事务。三十台机器同时交卷每个请求各开一个连接、各自去抢写锁抢不到的就等等过busy_timeout默认 5 秒直接抛异常。而交卷恰恰是写入最密集的时刻所有人都在最后几分钟点提交。解决三件事一起做。第一建库时开 WAL 模式读写不再互斥第二写操作收口到一个全局写连接加一个队列请求只负责把写任务塞进队列然后返回“已受理”前端轮询结果第三判分从交卷接口里拆出去交卷只落答案判分由后台线程按 exam_id 批量跑。# server/db.py节选 conn sqlite3.connect(data/exam.db, check_same_threadFalse) conn.execute(PRAGMA journal_modeWAL) # 读写不再互斥 conn.execute(PRAGMA busy_timeout10000) # 抢不到锁等 10 秒再抛 conn.execute(PRAGMA synchronousNORMAL) # WAL 下这个级别够用写入快一截5.2 部分机器搜不到服务端现象一个机房五十台机器四十多台自动发现成功剩下七八台一直停在“正在查找服务端”手动填 IP 又能连上。原因两种情况占绝大多数。一是教师机上装了安全软件把入站 UDP 25555 拦了那几台机器只是运气不好被分到了不同的交换机端口二是教师机双网卡广播包从办公网那张网卡出去了机房网段根本没收到。解决部署前在教师机的防火墙里显式放行入站 UDP 25555 和 TCP 8000客户端按网卡枚举广播地址逐轮发最后保留一个“手动填 IP”的输入框自动发现失败时能兜底。这个兜底入口看着土但它是现场唯一能让考试准点开始的手段。5.3 断电重启后最后几道题是空的现象机房跳闸恢复供电后学生重新登录续考前面答得好好的最后三五题全是空白学生坚持说自己答了。原因答案只在内存里攒着每 30 秒批量提交一次。跳闸那一刻最近 30 秒内的答案连同内存一起没了。批量提交在开发时是为了减少请求数在考场里变成了丢答案的元凶。解决把提交频率从“定时批量”改成“每次改动立即写本地文件”服务端提交降级为尽力而为失败了无所谓因为本地有。续考时先加载本地缓存渲染界面再把pending()里的差异补传上去。这个改动把最坏情况下的损失从“30 秒的答案”压到“最后一次点击”。5.4 倒计时在两端对不上现象学生端显示还剩 12 分钟教师端已经点了收卷或者反过来学生端显示已结束服务端还在收答案。原因客户端拿本机时间减开始时间算剩余时长。机房机器的系统时间本来就参差不齐有的差几分钟有的年份都不对用它算倒计时必然错。解决倒计时只认服务端。开考时服务端下发remaining秒数客户端用单调时钟time.monotonic()递减每 30 秒心跳时用服务端返回值校正一次。收卷也以服务端时间为准客户端到点只是把界面锁住真正的截止判断在服务端做。5.5 多选题判分结果对不上现象学生坚称自己选的是 AC标准答案也是 AC系统判 0 分。抽查几份答卷发现出错的全是选项被乱序过的题。原因答案用了字符串直接比较。选项乱序之后学生在界面上看到的 A 其实是原始题目的 C提交上来的AC和标准答案CA字符串不相等判错。解决一是判分统一走set比较顺序无关二是乱序时把“显示选项 → 原始选项”的映射关系一并存进答卷判分前先按映射还原。第二点很多人会漏只做 set 比较能解决顺序问题但解决不了“学生看到的 A 到底是哪个 A”这个更根本的问题——一旦后续要人工复核卷子没有映射关系就没法还原学生当时看到的是什么。注意这五个问题里有三个和网络无关全是时间、并发和顺序问题。上线前拿三台机器压一遍是不够的至少要按真实人数的一半做一次并发交卷演练。6. 二次开发把它改成能进真实考场的版本这份代码是个能跑的骨架不是能直接卖给客户的产品。想往真实考场推我建议按下面的顺序改从影响面小的改起改造点改动位置大致工作量加判断题、填空题的判分grading.py加分支question.qtype加枚举半天题库加密防止学生直接打开 dbdb.py加解密层或改用加密的题库文件一到两天成绩分析与导出static/加页面服务端加一个聚合查询一天客户端自动更新服务端加版本接口客户端启动时比对两天主观题人工阅卷新增阅卷表和页面answer_sheet加manual_score三到五天如果只做一件事我建议先加“判分版本”这个字段。做法很简单answer_sheet加一列grade_versiongrading.py里维护一个常量GRADE_VERSION 2判分时把它写进答卷。以后判分规则一改比如多选从“少选给一半”改成“少选不给分”只要把版本号加一就能筛出所有旧版本的成绩批量重算而不用去猜哪些卷子是老规则判的。这个字段加上去只花十分钟省下的是考完被打回来重判一整场考试的麻烦。验证改造是否有效的办法也很朴素写个脚本模拟五十个客户端并发交卷加断线重连跑三轮看答卷条数、总分分布、updated_at是否都合理。真机房里出问题九成不是因为代码写得不够巧而是因为没人按真实规模跑过一遍。我刚接手这套东西的时候觉得功能都通了就算完事结果第一次真机房演练五十台机器同时交卷数据库锁死最后是靠一份份手工对答案救回来的。从那以后我每次改完交卷链路都强制先用脚本压一遍五十并发再进机房一次没落下。希望帮到你。本文还有配套的精品资源点击获取
