去年接了一个技能等级认定系统的开发需求客户那边跑的是很传统的Windows终端环境要求在无外网的鉴定机房离线部署还希望整个考务流程报名、编排、理论考试、实操评分、成绩合定、证书打印都能在一个客户端里闭环跑完。技术栈我直接定了Qt C前后端一起做下来大概四个月。这套系统现在已经在某地职业技能鉴定机构稳定运行了大半年中间踩了不少坑也有不少值得复盘的设计决策。这篇就把整个项目的需求拆解、架构设计、核心模块实现和上线后遇到的真实问题完整梳理一遍给准备做同类考评类系统的开发者做个参考。先说明一下这里说的“技能等级认定”本质上是围绕职业能力评价的整套业务流程不是单纯一个答题考试。它比普通在线考试系统复杂的地方在于涉及多角色考生、考评员、督导员、管理员、多类别的考核形式理论、实操、综合评审、还有证书和成绩的合规管理。所以开发前期的重心其实不在写代码而在于把业务流程吃透把系统边界和规则建模做清楚。下面从需求分析开始讲。1. 技能等级认定系统到底要做什么——不是“考试系统”那么简单1.1 从报名到发证的完整业务链路每一个环节都是需求技能等级认定系统的骨架是一条标准业务链机构发布认定计划、考生报名提交材料、审核资格、编排考场、组织理论考试、组织实操考核、考评员评分、成绩合定与公示、证书生成与发放。听起来很常规但每个环节拆开都有大量细节。报名环节涉及的常见需求包括批量导入考生信息、身份证件材料上传、历史成绩校验比如已有低等级证书才能报考高等级、免考或部分科目豁免的规则。审核环节又分初审和复审通常需要不同角色分开操作。考场编排这个环节很容易被低估。在我接的需求里理论考场要同时支持按行政区域或按报名单位分组实操考核要按工位和设备数量分配场次。编排结果需要导出成考场安排表和考生准考证准考证上要有二维码用于入场检录。实操环节比重很大。不同职业工种的实操考核方式千差万别有的用实物设备有的用软件仿真系统有的干脆是现场问答加操作演示。评分方式也不一样有的考评员本人站在旁边打分有的通过视频录像事后评分。这意味着评分模块不能做成死表单必须支持动态配置评分维度和权重。成绩合定环节的规则同样需要灵活配置理论成绩和实操成绩各占多少比例、是否要求双合格理论和实操都分别达到及格线还是总分达标即可不合格考生是否可以补考补考成绩按什么规则记录。证书生成要按不同等级使用不同模板要有唯一的证书编号规则还要考虑证书打印的排版和防伪标识。我建议真正动手设计之前花至少一到两周做业务流程访谈把上述环节对应的角色、状态流转、异常分支全部梳理成流程图和状态表。这个前期工作做扎实后面开发效率会高很多。我就是因为一开始对“实操评分”理解得太简单后期返工过一次评分模块的数据库设计。1.2 为什么用Qt C而不是Web或Electron这是个选型决策客户的环境很明确鉴定机房里的终端是Windows系统部分电脑配置老旧内网环境常年不连外网不允许后台跑一个常驻Web服务也不想依赖浏览器版本。这种场景下Web方案天然不合适——哪怕用本地Nginx部署前端也绕不开浏览器兼容、系统服务依赖、离线缓存策略这些麻烦。Electron同样是重依赖方案它打包体积大内存占用高在老终端上启动慢而且升级要覆盖整个安装目录。C配合Qt做桌面客户端则从底层绕开了上面这些障碍静态编译或依赖动态库都可以控制在极少文件部署就是拷贝一个目录进程数少资源占用低可以直接调用系统的硬件接口比如身份证读卡器、扫码枪、摄像头这些在Electron或浏览器里反而都要做复杂封装。Qt相对其他C界面库的优势也很明显Widgets组件体系成熟QSS可以轻松定制界面风格处理密集的表单交互场景效率很高还有完整的SQL数据库封装、网络访问模块、JSON解析、多线程支持。用Qt C做这类业务系统输入输出、数据库、网络通信、界面组件都能在同一个技术栈内解决不需要像传统MFC那样拼凑各种第三方库。有一点需要提醒Qt的版本和许可策略要提前确认清楚。商业闭源项目如果用开源版要注意实际使用的是LGPL还是GPL条款如果不打算开源项目代码要么确认你的使用方式符合LGPL动态链接要求要么买商业授权。我这次定了Qt 5.15 LTS配合Windows离线部署包这些决策都要在项目启动前定好。2. 整体架构设计客户端为主、服务端为辅的分层方案2.1 客户端的MVC分层和模块边界技能等级认定系统的业务逻辑大部分集中在客户端整体采用经典MVC分层我按功能模块划分了目录结构界面层View、业务逻辑层Controller/Service、数据访问层Repository/Database。业务逻辑层是核心所有规则都在这一层校验和流转禁止界面代码直接读写数据库。比如“考生报名是否通过初级审核”这个动作业务层要依次判断报名批次是否开放、材料是否齐全、身份证号是否已在本批次存在、是否满足等级报考条件全部通过才更新状态并写入操作日志。界面层只负责收集用户输入和展示结果。模块划分方面我分了以下这些相对独立的子模块系统管理用户、角色、权限、字典、认定计划管理、报名管理、资格审核、考场编排、题库管理、理论考试终端、实操评分、成绩合定、证书管理、统计报表。模块间通过Qt的信号槽机制保持低耦合跨模块调用统一走服务接口不在界面里直接互相操作。数据层单独提一下。全部业务表用SQLite存储但每个考核场次的考试数据答题记录、考试状态独立存放通过配置文件指向对应数据库文件。这么做的好处是考试终端的数据库文件小损坏影响面窄备份恢复也方便。2.2 通信协议与数据交换HTTP JSON 单向断点续传客户端虽然离线部署但成绩汇总、证书数据同步、考生名单下发这些动作都需要和总服务器交互。通信统一走HTTP接口数据格式用JSON。服务端不参与复杂的业务计算它更多承担数据汇聚和统一管理的职责。接口设计遵循几个原则。第一个原则是接口幂等尤其提交答题记录和成绩这种关键操作客户端会带唯一单据号UUID服务端收到后先判断单据是否已处理重复提交时只返回成功状态不重复落库。第二个原则是接口返回值统一全部用类似{ code, message, data }的三段式结构客户端封装一个统一的HTTP请求处理类来解析。断网情况下的数据同步链路需要专门做设计。考试过程中客户端完全不依赖网络本地写盘等到交卷时做一个网络探测如果连通就把数据包上传没连通就写进上传队列文件。运维人员后续在联网的机器上导入导出或者在下次开机联网时自动补传。上传队列持久化在本地SQLite表里采用先进先出策略而且支持断点续传——按分片上传服务端记录每片状态避免一张大表上传失败全部重来。2.3 SQLite在考评场景下的选型与优化为什么不引入MySQL或者SQL Server这类服务端数据库因为这套系统的部署环境大多没有专业运维人员总服务器也不一定装得了复杂的数据库服务。SQLite单文件部署、零配置、性能足够应付鉴定站这种量级的数据一场认定最多几百个考生几十万条答题记录就是上限了是性价比最高的选择。但SQLite也不是无脑用有几个关键的配置和习惯必须长期坚持。连接串里一定要开启WAL日志模式和合理的busy_timeout不然多个客户端线程同时写库时会频繁报“database is locked”。我这里统一在数据库初始化时执行了PRAGMA journal_modeWAL和PRAGMA busy_timeout5000从此锁冲突的报错率大幅下降。另外一个优化点是把高频率的Insert/Update操作合并成事务批量执行。比如理论考试答题记录每做一题都在答完时写盘一次但用事务包起来的话带宽开销基本可以忽略。如果有一百道题不要等到交卷才一次性写入每答完一题提交一个小事务既防止程序崩溃丢数据也不至于在交卷瞬间造成写盘高峰。数据处理层面大量使用预处理语句QSqlQuery的prepare接口不但能防SQL注入还让Qt和SQLite两边都能重用查询计划。统计报表查询时如果涉及多表关联和分组聚合我会先把结果缓存到内存表再在界面展示避免频繁查询文件型数据库造成卡顿。还有一个细节SQLite的数据库文件在Windows下容易被杀毒软件实时监控扫描导致首次访问较慢。我的一般做法是把数据库文件放在程序目录下的data子目录里并建议客户把整个程序目录加入杀毒软件的白名单。3. 核心功能实现公平抽题、动态评分、断网容错和证书生成3.1 公平抽题引擎按知识点和难度双重配额的随机策略理论考试模块最容易出现的问题是“看似随机实则不公平”。如果只是从题库里做纯随机抽取可能某张试卷的难题比例偏高某个重点章节的题覆盖率不足甚至出现相邻考生抽到同一套题的情况。我的抽题引擎把试卷生成分成了两步配置试卷蓝图然后基于蓝图执行带约束的随机抽题。试卷蓝图用JSON格式描述包括总分、题型分布、每个章节的知识点配额、每个知识点的难度比例。不同等级对应不同蓝图一个等级也可以配置多套同等难度的蓝图。抽题算法本身不复杂核心是“分层随机”先把题库按知识点和难度筛出候选集合再用洗牌算法在同等级题目内打乱顺序依次取够数量。关键约束有两条同一份试卷内不能出现内容完全相同的题目即使题目来自不同知识点也不允许原题重复同一考场的相邻考生不能抽到完全相同的试卷组合——这里我做了简单的哈希去重将已配发的题目组合记录在案如果新抽出的组合与相邻座位的已用组合重复就重新抽取。抽题时机放在服务端编排考场的时刻而不是客户端本地抽。因为客户端本地抽无法控制全局去重服务端统一抽完生成试卷包再分发到考试终端。每个考生拿到的试卷用一次性的试卷ID关联答题过程中的页面只显示题目不泄露任何试卷结构信息。3.2 实操评分模块用JSON配置动态评分表而不是写死控件实操评分是这个系统里最能体现“业务复杂度”的模块。每个工种的评分维度完全不同焊接可能关注焊缝成型、外观尺寸、缺陷情况电工可能关注接线工艺、安全操作、调试结果每个维度下又细分若干评分点评分点可能是扣分制也可能是得分制还可能包含一票否决的关键项。硬编码评分表意味着每来一个新工种就要改代码重新发布这绝对不可行。我把评分表设计成了“表单引擎配置驱动”的架构每个职业工种对应一个表单定义表单定义用JSON描述包含评分维度、评分项、分值、输入方式单选、多选、数值输入、备注数据库只保存表单实例的评分结果。评分表单引擎解析JSON后动态生成界面考评员在平板上操作完成后生成评分汇总。汇总规则也做成了可配置项总分是各项加权求和还是简单累加关键项是否一票否决审定成绩与考评员评分不一致时是否需要填写调整原因。这样做的好处是新增一个工种时只需要在后台维护一份表单定义不用动代码。这里有个容易被忽略的点评分的修改留痕。考评员打错分后要允许修改但每一次修改都必须在界面上弹出确认框并记录修改前值、修改后值、修改人和修改时间。实际操作中真的会遇到考评员误触平板导致分数被改的情况如果没有审计记录后期成绩纠纷会非常麻烦。3.3 考试终端的本地数据落地与断网续传考试终端是在无网环境下运行的因此数据落地策略要优先保证可靠性和可恢复性。每一次答题动作包括切题、上一题、下一题、修改答案都会实时写入本地数据库的答题明细表。大题状态进行中、已交卷、超时未交也随时更新。网络恢复后的数据同步流程上已经提过这里补充一个崩溃恢复细节客户端在本机保存一个当前考试场次的本地状态文件包括当前进行到哪个考生、考试当前阶段、已上传的试卷包编号。客户端异常退出后重启会依据这个状态文件恢复到上一次的考试界面而不是要求考生从头再来。考生完成交卷动作后系统立即生成一个完整性校验值对答卷内容做一次哈希即便后期数据被篡改或传输损坏也能通过校验发现异常。考评员和后台管理员在成绩公示阶段一旦发现校验值不一致可以立即定位是传输问题还是人为篡改。3.4 证书生成编号规则、模板设计和防伪要点证书模块在开发初期常常被当个“打印功能”带过实际做起来细节极多。编号规则我采用的是“等级标识年度机构代码流水号”的组合方式例如JG-2025-0001这种结构。流水号不能简单用自增ID需要在批量生成时保证不重复且连续可查。模板设计用了HTML渲染方案证书底图通过界面绘制成固定尺寸的背景图片然后在指定坐标动态填充考生姓名、身份证号、职业名称、等级、认定机构、发证日期等信息最后整体导出为PDF文件。字体问题是最容易踩的坑——Windows下的宋体在某些精简系统里不一定存在一旦字体缺失生成的PDF里中文可能变成乱码或方框。我这边统一把证书专用字体文件打包进程序资源渲染时按需加载不依赖系统字体。防伪层面除了编号可查还在证书角落生成了二维码。二维码内容包含证书编号和发证机构的加密校验信息扫描后可以跳转到机构官网的证书查询页面。查询页面只允许输入证书编号和身份证号后四位检索不暴露多余敏感信息。4. 上线后遇到的真实问题与完整排查过程4.1 考试结束瞬间SQLite数据库锁死的排查链路系统上线后第一次正式考试理论考试结束时大量终端同时提交答卷结果后台汇总时SQLite报了“database is locked”一部分答卷没能入库。这个问题的排查过程值得完整记录。第一步看现象报错只发生在交卷高峰时段的汇总程序里单独提交一条答卷时正常。第二步看日志Qt的数据库模块会记录详细的错误信息日志显示是SQLITE_BUSY也就是获取写锁超时。第三步看代码汇总程序启动时确实设置了busy_timeout但事务代码提交时没有重试机制一旦获取锁失败直接抛异常回滚。实际上SQLite在这种高并发场景下性能并不占优几十个终端同时写同一个库文件锁竞争不可避免。最终解决方案是双管齐下第一把汇总写入改成串行队列同一时刻只有一个线程在写库其余的放入内存队列等待第二每个写事务的失败重试次数设置为5次每次间隔200毫秒基本能消化掉绝大多数锁冲突。事后复盘磁盘IO也是一个因素把数据库文件从机械硬盘换到SSD上后锁等待时间明显缩短。4.2 相邻考生抽到重复试卷的均衡性问题第二次模拟考结束后我让助手对答卷数据做了一次重复率分析结果发现同场的相邻考生中约有8%抽到了重复的试卷组合。这个比例明显偏高说明抽题引擎的随机策略有缺陷。回到代码检查原来服务端分配试卷时用的是伪随机种子它直接取了当前系统时间。多台终端几乎同时向服务端请求试卷包每台终端获取到的时间戳高度相似生成的随机序列也就惊人地相似。查了半天才明白问题根源在这里。修复方法把随机源的构造改为“系统时间进程ID计数器”的组合并在同一个考场内增加已分配组合的缓存映射表限制同一考点的相邻座位号范围内不能出现重复试卷组合。重新跑压力测试后重复率降到了接近零且不同考场的试题分布离散度也正常了。4.3 考评员评分修改权限的审计盲区正式使用第二周负责督导的同事找我反馈考评员评分界面允许修改分数但修改后没有记录“为什么改”。如果考生对成绩提出质疑台账里只有最终分数查不到改动轨迹非常被动。其实评分修改留痕逻辑在开发期写过但只覆盖了“考评员提交评分后管理员调整”这种情况考评员本人在提交前多次修改初稿的过程没记录。后来我在评分表单里增加了一个score_revision_log表任何评分变动包括提交前的保存动作都记录修订记录。界面上的每次保存/提交都强制弹窗让考评员确认确认后的所有修订都带时间戳和操作人只有第一次录入不强制填写原因后续修订必须有原因才能保存。4.4 证书字体缺失导致的乱码问题证书PDF当时在开发机上渲染正常部署到鉴定站机房后有几台机器导出的证书中文字体全变成方框。排查后确认是目标机器未安装中文字体系统字体列表里找不到匹配项。这个问题属于典型的“开发环境正常生产环境环境差异”类故障。最终方案是证书渲染时强制使用打包在程序目录内的字体资源把字体文件注册到Qt的字体数据库中渲染PDF和显示预览都走同一套字体路径。从那以后证书模块再没有出现过乱码相关的工单。5. 运维层面的设计日志、备份、升级和容灾5.1 客户端日志分级与自动打包桌面系统上线初期客户报障时往往只能描述“点不了”“没反应”。我要求客户端把所有操作都记录进日志并按级别分为DEBUG、INFO、WARN、ERROR四类。DEBUG只记录关键参数和函数入口INFO记录业务节点准考证生成、试卷下发、交卷成功WARN记录网络超时和配置缺失这类异常但不致命的问题ERROR记录异常堆栈和数据库错误。日志文件按天切割保留最近30天上传汇总时按批次打包成zip。后台有个“日志回传”功能客户在出问题时点一下就能把当天的日志包上传我们立刻拿到完整的操作轨迹。这个功能在排查几个疑难问题时省了大量跑现场的时间。5.2 数据库备份的自动化策略数据安全这件事不能靠“人工想起才备份”。每个客户端在每天结束考试后自动把本地数据库文件复制到备份目录备份文件名带上日期和“before/after”标识。总服务器每天晚上定时执行全量备份并把备份文件保留90天。SQLite备份建议用其自身的online backup API避免直接复制文件产生不一致状态。Qt里可以利用快照机制边用边备份不需要停库。实操中我总是额外写一个小的自检程序备份完成后重新打开备份文件并执行一次完整性校验确保备份不是坏档。5.3 版本升级的灰度与回滚策略客户端升级最怕的是全量替换后新版本有问题一夜回到解放前。我把升级设计成一个独立的升级辅助程序主程序每次启动时检查约定目录里有没有新版本标识文件有就提示用户在当前考试结束后执行升级升级程序先备份旧版本目录再拷贝新文件完成后自动回写版本号。灰度发布是在总服务器配置里指定“允许升级的机构白名单”先用一两家中等规模的机构试点跑一周确认无异常后再放开全量。倘若试点期间出现严重Bug回滚操作就是让升级辅助程序从备份目录恢复旧版本。这套机制虽然简单但确实避免过至少两次潜在的全线事故。6. 给后来开发者的几句实在话技能等级认定这类系统的核心壁垒不在界面多漂亮、技术多前沿而在规则引擎的完善程度和数据可靠性。你越是把报名、成绩合定、证书编号这些看似琐碎的规则想清楚后面系统上线就越省心。排期上一定要给需求确认留足空间。业务流程访谈阶段如果草草了事后面改一个状态流转可能连数据库设计都要跟着动。我当时实操评分模块返工就是因为现场访谈时没有把“不同工种的评分维度差异化需求”听全。开发节奏上我建议先做一个包含全部主要功能的最小版本界面可以丑一点优先保证流程跑通拿到真实业务人员试用反馈后再进入界面美化阶段。很多流程设计问题不走到试用环节是发现不了的。另外多准备几套完整的模拟数据用于测试覆盖“多人同时交卷”“中途断网”“重复提交”这些异常场景能帮你提前暴露不少并发和幂等设计问题。最后再分享一个小技巧给这类系统加一个“数据体检”功能让维护人员一键检查各类关键数据是否存在异常例如某考生理论成绩缺失、试卷编号重复、证书编号断号。这种功能不复杂但在上线初期排查数据问题时的作用远超预期。