简介面向计算机专业毕业设计与课程设计场景这套面试系统项目以“面试系统-毕设.zip”打包聚焦企业招聘流程数字化转型覆盖简历管理、面试预约、多维度评价、结果通知与数据统计分析等核心功能适合作为学习软件工程实践、参考系统架构的完整案例。资源共225个文件压缩包约3.9MB前端以76个js逻辑脚本和50个css样式为主后端含24个java代码文件并补充xml/json配置、数据库ER图与SQL脚本及图标字体等体量轻巧而结构完整便于直接对照需求文档进行二次开发。已有80人浏览学习项目页面采用Bootstrap/AdminLTE等常见框架前台交互逻辑与后台管理一目了然代码结构清晰、注释详尽可帮助读者了解从需求分析到系统落地的全过程。无论是作为毕设参考模板还是用于企业招聘流程优化在此完整方案基础上均能快速上手使用也可进一步扩展视频面试、AI辅助评估等新能力具有一定的工程实践价值。1. 面试系统为什么不能只搭个视频聊天室拿到“面试系统-毕设.zip”这个压缩包标题很多人第一反应是做个视频聊天室再挂个简历上传就收工。等答辩评委问“候选人答完题之后代码怎么判”“两个面试官同时打分怎么汇总”“简历文件传上来怎么防止它是个木马”的时候才发现整个系统的骨架其实是状态机和数据边界。本文不介绍某个现成压缩包而是按一线项目里最常见做法把面试系统拆成可演示、可解释、可继续扩展的方向模块取舍、表结构、判题沙箱、音视频存档和安全边界。适合准备把毕设做成“能答辩”而不仅是“能运行”的开发者也适合想在团队里做内部招聘工具的人参考。2. 从毕业设计到可演示系统拆解核心模块与数据模型2.1 候选人端、面试官端、管理端权限边界怎么划面试系统的第一个坑是三个角色共用同一张用户表然后靠前端按钮来隐藏功能。这种做法在演示时看不出问题但你一调接口拿到返回体就会发现候选人能调用面试官端的管理接口。我一般会让后端对每个接口做角色校验而不是只依赖页面渲染。后端权限判断可以统一做成注解。下面是 Spring Boot 风格的拦截器实现放在拦签约中校验当前登录人的角色字段。Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RoleRequired { String[] value(); }Component public class RoleInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (!(handler instanceof HandlerMethod hm)) { return true; } RoleRequired role hm.getMethodAnnotation(RoleRequired.class); if (role null) { role hm.getBeanType().getAnnotation(RoleRequired.class); } if (role null) { return true; } LoginUser user (LoginUser) request.getAttribute(loginUser); for (String r : role.value()) { if (user.getRoles().contains(r)) { return true; } } response.setStatus(403); return false; } }逻辑说明首先判断是不是方法处理器不是直接放行静态资源。然后从方法上的RoleRequired注解读角色列表方法上没有再去类上读。controller 层获取会话后先放入request属性这里从属性取值最终遍历要求的角色只要命中一个就放行。注意LoginUser里的角色建议用SetString避免contains时出现重复角色导致的性能损耗。权限边界我会拆成三层候选人和面试官都能看到面试日历但候选人只能看到分配给自己的面试官只能看到自己的待面试列表管理端可以看全部管理端的接口除了角色校验外还要校验数据归属比如修改面试时间时必须带上interviewId对应的面试官 ID防止越权跨人改时间。这里有一个容易被忽略的点角色名不要散落在代码字符串里。建议定义常量类Roles.CANDIDATE / Roles.INTERVIEWER / Roles.ADMIN避免拼写错误。如果时间紧不做注解也可以用request.getRequestURI().startsWith(/api/admin/)做粗粒度拦截但答辩时这种写法容易被认为是“个人习惯”而不是“方案”建议至少用枚举或常量收口。2.2 核心表结构简历、面试、评估与三方消息面试系统要能支撑完整业务闭环最少需要五张核心表用户表、简历表、面试表、评估表、消息表。简历表不直接存文件二进制只存文件路径和解析出的文本评估表和面试表分开的原因是一个面试官可以多次评估一次面试也可以有多人评估。下面用 PostgreSQL 方言给出核心表结构主键用雪花 ID字段统一用 snake_case。CREATE TABLE candidate_profile ( id BIGINT PRIMARY KEY, candidate_id BIGINT NOT NULL, resume_file_path VARCHAR(512) NOT NULL, resume_text TEXT, status VARCHAR(20) DEFAULT PENDING, created_at TIMESTAMPTZ DEFAULT now() ); CREATE TABLE interview ( id BIGINT PRIMARY KEY, title VARCHAR(128) NOT NULL, candidate_id BIGINT NOT NULL, interviewer_id BIGINT NOT NULL, start_time TIMESTAMPTZ NOT NULL, end_time TIMESTAMPTZ, status VARCHAR(20) DEFAULT SCHEDULED, room_token VARCHAR(64) ); CREATE TABLE evaluation ( id BIGINT PRIMARY KEY, interview_id BIGINT NOT NULL, interviewer_id BIGINT NOT NULL, dimension_code VARCHAR(32) NOT NULL, score INTEGER NOT NULL CHECK (score 0 AND score 10), comment TEXT, created_at TIMESTAMPTZ DEFAULT now() ); CREATE TABLE message ( id BIGINT PRIMARY KEY, sender_id BIGINT NOT NULL, receiver_id BIGINT NOT NULL, message_type VARCHAR(20) NOT NULL, payload TEXT, read_flag BOOLEAN DEFAULT FALSE, created_at TIMESTAMPTZ DEFAULT now() );参数说明resume_text用来做关键词检索答辩演示时可以展示“从简历中提取 JVM、Redis 等关键词命中候选岗位”room_token是视频面试间的临时凭证不要用自增 ID 拼到 URL 上否则候选人 A 能猜到 B 的面试间evaluation表用dimension_code表示“技术深度、沟通表达、团队协作”等维度方便后续做雷达图。message表payload用 JSON 文本比如发送试题目时携带{questionId: 12, duration: 30}。时间字段一定要用TIMESTAMPTZ不要把本地时间字符串存进去。简历文件路径建议用相对路径而不是D:/xxx/resume/1.pdf否则换电脑演示直接 404我习惯在配置里定义storage.root数据库存resume/202501/xxx.pdf前端拼完整地址。这张表还有一个反直觉的设计面试表里冗余了interviewer_id看起来应该在面试界面上通过多对多关联候选人和多个面试官。毕设场景建议做成一对多或者简单的“主面试官 助理面试官”字段因为多对多关联在答辩时很难两三句话说清楚还会引入额外关联表。如果确实需要多轮面试额外做interview_round表更清晰。2.3 业务状态机从投递到Offer的7个状态跳转面试系统最核心的不是画页面而是状态流转。我把状态定义为PENDING待筛选、SCREENED简历筛过、SCHEDULED已排期、IN_PROGRESS面试中、COMPLETED面试完成、OFFERED已发录取、CLOSED流程结束。这里的一个关键规则是状态只能由服务端代码推进不允许前端按钮任意切换。常见做法是在后端维护一个MapCurrentState, ListTransition或者用状态枚举表。以下展示用 Java 枚举做状态机的核心判断避免 if-else 满天飞。public enum InterviewState { PENDING, SCREENED, SCHEDULED, IN_PROGRESS, COMPLETED, OFFERED, CLOSED; private static final MapInterviewState, SetInterviewState TRANSITIONS Map.of( PENDING, Set.of(SCREENED, CLOSED), SCREENED, Set.of(SCHEDULED, CLOSED), SCHEDULED, Set.of(IN_PROGRESS, CLOSED), IN_PROGRESS, Set.of(COMPLETED, CLOSED), COMPLETED, Set.of(OFFERED, CLOSED), OFFERED, Set.of(CLOSED), CLOSED, Set.of() ); public boolean canTransitTo(InterviewState target) { return TRANSITIONS.get(this).contains(target); } }逻辑说明枚举里用Map.of声明每个状态允许到达的下一个状态。CLOSED是终态没有出口。业务代码里先判断canTransitTo允许时才去更新数据库并写入一条流转记录不允许时直接抛业务异常。这里要注意Map.of是 JDK 9 之后才有的如果目标环境是 JDK 8请换成Collections.unmodifiableMap(new HashMap() {{ put(...); }})。状态推动的代码要放在一个事务里避免出现“修改了状态但没发消息”的中间状态先尝试更新UPDATE interview SET status ? WHERE id ? AND status ?影响行数为 1 才继续插入 message 表和发送通知。这里用乐观锁的思路比先读再判断更稳。第 5 章的并发章节会再展开。为什么状态跳转要这么严格因为面试系统的各个入口都会依赖状态候选人端展示的是下一场面试倒计时面试官端展示的是待结束的面试列表管理端要统计各状态人数。如果前端直接把某个状态改成COMPLETED统计数据乱了不说候选人还可能在晚上十点收到“你的面试已完成”的奇怪消息。血泪经验是状态机的测试不写在接口层写在枚举层用assertEquals(false, PENDING.canTransitTo(IN_PROGRESS))这种方式做单元测试防止后续加状态时把跳转关系写坏。另外所有状态变更在写入时都应该触发事件。比如从SCHEDULED变成IN_PROGRESS时要生成面试间 room_token从COMPLETED变成OFFERED时要生成 Offer 附件。这块逻辑用异步事件监听器做不要放在主流程里同步拼装邮件模板。3. 在线笔试与代码考核模块可复现的最小实现3.1 创建在线编程题题干、测试用例与判题容器在线笔试的演示重点通常是“代码提交后到底有没有执行”。常见的思路是在后端写一个SystemClient直接挂到宿主机上跑编译和java -jar这样做演示很快但一次并发就把机器打崩还会被简历上传漏洞联动攻击。正确的骨架是题目表存题干和模板代码测试用例表存输入输出提交记录表存源码和判题状态。下面是一道编程题的 JSON 结构我习惯用它作为接口入参便于前端一次性拿到所有展示信息。{ questionId: 10023, title: 两数之和, difficulty: MEDIUM, description: 给定整数数组 nums 和整数 target返回两个数的下标。, templateCode: { java: class Solution { public int[] twoSum(int[] nums, int target) { ... } }, python: class Solution: def twoSum(self, nums, target): ... }, testCases: [ {input: [2,7,11,15]\\n9, output: [0,1]}, {input: [3,2,4]\\n6, output: [1,2]} ], timeLimitMs: 1000, memoryLimitMb: 256 }逻辑说明templateCode里不存完整答案只存方法签名候选人进来先看到模板testCases的输入和输出都转义成字符串判题时拼成标准输入和期望输出这样能统一不同编程语言的处理方式。timeLimitMs和memoryLimitMb是提交给判题容器的资源上限毕设阶段可以只对提交代码的容器做限制另一份样例分析用的容器可以共享。这里有需要在答辩时专门讲的点题目表里不能把输出结果直接放明文因为候选人可能通过接口返回体直接看到测试用例输出。我一般会在创建题目时把测试用例加密存到单独表比如用SHOW_AFTER_DDL的开关控制只有判题服务在容器内部能读到解密后的用例普通查询接口只返回 case 数量。3.2 判题结果如何安全回收沙箱执行与超时限制判题服务是整个面试系统里最容易翻车的地方。网络上的教程会让你直接调用Runtime.getRuntime().exec(javac Main.java)这在本地单机没问题但面试系统要 demo 给别人看时一次死循环就能让 CPU 占满整个系统卡死。我推荐用 Docker 容器做隔离判题单元每次提交都新建一个临时容器运行完立即删除。docker run --rm \ --network none \ --memory 256m \ --cpus 1 \ --pids-limit 64 \ -v /tmp/judge/${submitId}:/workspace:ro \ -w /workspace \ --name judge-${submitId} \ judge-image java -jar Runner.jar timeout 15s docker wait judge-${submitId} || { docker kill judge-${submitId}; echo timeout; }参数说明--network none禁止容器联网防止提交的代码向外发送数据--memory 256m限制内存--cpus 1限制 CPU 核数--pids-limit 64防止开启大量线程挂载目录用只读方式候选人提交的资源只让容器读取不允许回写。最后一行是容器级别的超时如果 15 秒没有结束就 kill。不要只靠timeout命令因为 Java 进程可能收到 SIGTERM 后还在运行配合docker kill才是双保险。在客户端代码里调用这条命令时要保持日志完整。判题会有ACCEPTED、WRONG_ANSWER、TIME_LIMIT_EXCEEDED、RUNTIME_ERROR四种结果。我通常会在judge-result.json里额外记录容器退出码、实际耗时、内存峰值方便答辩时展示“这个系统不是黑匣子”。需要关注的是 Docker 镜像体积。每个提交都docker run镜像拉取是预先完成的不要等提交时再docker pull否则第一次提交会等几十秒。毕设阶段可以提前把镜像docker save成 tar部署脚本里docker load并把基础镜像固定为某个特定的 tag不要用latest否则不同的机器上行为不稳定这就是典型的“在我电脑上能判换个环境就报错”。3.3 实时协同现场coding用WebSocket做逐行记录编程题之外视频面试里常有一个“现场写代码”环节候选人写代码面试官在另一边同步看到。实现它的重点不是把编辑器里的内容每次全量发送而是记录编辑器变更事件用 WebSocket 推给面试官端。// 候选人端监听编辑器的 change 事件 editor.on(change, (change) { const payload { type: code-delta, roomId: currentRoomId, version: change.version, delta: { startRow: change.start.row, startCol: change.start.column, endRow: change.end.row, endCol: change.end.column, text: change.text } }; ws.send(JSON.stringify(payload)); });逻辑说明delta只携带变更的行列范围和插入文本而不是每次把全量代码发过去这样在网络抖动时不会瞬间打爆消息队列。version字段对应文档触发的版本号面试官端收到后按版本号逐个应用可以做到不丢更新。面试官端收到消息后要执行editor.updateDocument(delta)并且把光标移动到变更位置。最有意思的是很多实现会直接把 delta 应用到只读的 Editor导致面试官端光标乱跳。正确做法是维护一个独立的viewModel不跟随候选人光标只应用内容变更候选人的光标位置单独用cursor-update消息推送面试官可以选择是否打开“跟随候选人光标”开关。这套方案最大的坑是后端需要在内存里维护一个room - clientId - session的映射。如果只把 WebSocket 会话放在内存而没做心跳当候选人电脑休眠后服务端仍然认为在线面试官就会看到一个“已经断线但直播间状态还是进行中”的假象。我一般会让客户端每 30 秒发一次ping服务端 60 秒内没收到就标记离线同时通知面试官端。这也是第五章里并发面试间会展开的一个点。4. 视频面试模块信令、录制与简历同屏的坑4.1 音视频选型为什么毕设不推荐自己推流视频面试模块最大的误解是以为要从零写一套推流、拉流、丢包重传协议。毕设答辩要的是“能说清楚架构”而不是“我写了 2000 行 RTP 封装”。我建议直接用浏览器原生的 WebRTC 能力服务端只做信令转发媒体流走 P2P 模式。在纯局域网演示时两人视频加屏幕共享对带宽要求很低答辩现场完全够用。P2P 模式下服务端信令服务器最简实现是用 WebSocket 中转 SDP 和 ICE 候选。候选人端和面试官端各创建各自的 RTCPeerConnection交换 offer/answer 后浏览器会自己打通音视频通道。但这里有个风险一旦评委现场让“面试官和候选人不在同一局域网”P2P 的 ICE 可能找不到对方此时会黑屏。所以生产化的解决方案是部署一个 SFU 媒体网关让两端都只向网关推流。听上去很高深其实可以这样回答评委“我这里采用的是 WebRTC 点对点实时传输同时服务端设计了可替换的 SFU 网关接口当接入层数增长时把 PeerConnection 换成转发式网关不影响业务层。” 你甚至可以做一张简单的接口表把音视频相关接口定义成RtcGateway接口默认实现是 P2P预留 SFU 实现这就是一个很好的扩展性体现。要注意的是信令服务器不能只把 SDP 广播给房间里的所有人。面试间里最多有 3 到 5 个人但候选人和面试官的数据流是不同的候选人要共享屏幕面试官要收流、发麦克风。所以发消息时带targetClientId不要用广播。4.2 录制存档方案本地录音屏幕录制的双轨备份面试系统如果只做实时通话面试官说“刚才候选人答得不错”但没有证据答辩演示就会很虚。完整的方案是在前端做两路录制候选人端录制自己的屏幕和声音面试官端录制自己的麦克风两路文件都上传到后端后后台可以按时间轴对齐回放。用浏览器 MediaRecorder 可以拿到本地录制流以下代码示意候选人端在收到interview-start消息时启动录制。const combined new MediaStream([ ...screenStream.getVideoTracks(), ...micStream.getAudioTracks() ]); const recorder new MediaRecorder(combined, { mimeType: video/webm }); recorder.ondataavailable (e) { if (e.data.size 0) { uploadChunk(e.data, currentRoomId); } }; recorder.start(3000);参数说明start(3000)表示每 3 秒生成一个分片并上传避免长时间录制时内存占用过大。mimeType用video/webm因为 Chrome 下默认录制 mp4 支持不稳定。上传接口需要带roomId和sessionId字段后端用minio或者本地磁盘存储文件路径由时间戳分目录比如record/202501/xxx/screen1.webm。如果是纯面试录音而不录屏可以把video/webm改成audio/webm文件更小但丢失了候选人写代码的画面。这里容易踩的一个坑是 MediaRecorder 在面试官端如果只录麦克风会出现录音里掺杂扬声器回放的声音。更好的做法是面试官端只录自己的的身份麦克风同时把候选人上传的屏幕录制作为主回放轨后台房间回放页用两个video标签分别摆在不同位置。回放时不要用前端拼接音频直接用两个文件同步播放是 demo 里的最优解省得转码。4.3 面试官看候选人简历的同步视角维护视频面试时面试官往往一边看候选人回答一边翻看简历。如果两头各看各的面试官问“你简历里这个项目为什么用 Redis”时候选人端完全不知道面试官在看哪一行。更好的做法是面试官端主动分享简历浏览位置候选人端可以打开“跟随”按钮让简历自动滚动到面试官正在看的位置附近。// 面试官端滚动事件防抖后发送位置 container.addEventListener(scroll, () { const percent container.scrollTop / (container.scrollHeight - container.clientHeight); ws.send(JSON.stringify({ type: resume-scroll, roomId: currentRoomId, percent: Number(percent.toFixed(4)) })); });逻辑说明percent是一个 0 到 1 的小数代表滚动位置占整份简历的比例。候选人端收到后如果开启了“跟随”就执行container.scrollTop percent * (scrollHeight - clientHeight)。注意这里要防抖否则每次滚动都触发消息带宽和 UI 更新压力都很大我在实际写法里会用 throttle 函数每 200 毫秒发送一次。这个模块还有两个细节第一简历图片不要在 WebSocket 消息里携带 base64只传 percent图片本身通过 HTTP 加载第二同步滚动要在候选人端设置“跟随开关”有效期为当前面试场次面试结束后自动关闭。如果不做开关面试官翻到第三页候选人端简历也会乱跳候选人边看题边跟着滚动很影响注意力。答辩时把这个功能称为“同步视图”比单独展示视频通话更有记忆点。5. 面试系统避坑指南安全、并发送审与本地环境5.1 文件上传漏洞简历里的“图片”可能不是图片现象候选人上传一个photo.jpg服务端返回成功但数据库里存的文件路径打开是个 502更严重的情况这个文件实际上是个 JSP 或 PHP 脚本攻击者通过访问上传路径拿到执行权限。原因文件上传只校验了扩展名和 Content-Type这两个都能被伪造。浏览器给出的multipart/form-data中文件名是photo.jsp.jpg服务端没有做白名单校验也没检查文件真实内容。解决第一校验扩展名白名单只允许pdf, docx, jpg, png等第二校验文件魔数读文件头几个字节PDF 是%PDFJPG 是FF D8 FF第三把上传目录设为不可执行并将文件名改为服务端生成的 UUID 加上白名单扩展名。最小演示可以用下面的 Java 片段。byte[] header new byte[4]; fileInputStream.read(header); if (!isAllowedMagic(header, extension)) { throw new BizException(file type not allowed); } String safeName UUID.randomUUID() . extension;这里要特别提一句不要用new File(uploadDir / originalFilename)直接拼接路径路径穿越会被../../写成别的目录。正确的做法是自己生成文件路径然后用Paths.get(uploadRoot).resolve(safeName).normalize()并检查最终路径仍然在 uploadRoot 内。5.2 面试间并发测试WebSocket连不上先查Nginx现象本地直接跑后端服务多人同时打开面试间HTTP 接口正常但 WebSocket 一直提示连接失败关掉 Nginx 反向代理直连后端端口又是好的。原因Nginx 默认对升级后的连接只给 60 秒空闲超时而 WebSocket 长时间空闲不发消息就会被proxy_read_timeout切掉。解决在 Nginx 服务的 location 配置里显式调大超时并关闭 HTTP 代理缓冲增加 WebSocket 心跳保持连接。心跳本身就是 30 秒一次超时设为 75 秒。location /ws { proxy_pass http://backend-server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 75s; proxy_send_timeout 75s; proxy_buffering off; }参数说明proxy_http_version 1.1是 WebSocket 升级的必要条件proxy_set_header Connection upgrade告诉上游这个连接要升级协议proxy_buffering off避免 Nginx 缓冲消息导致实时性下降。另外如果系统里用了负载均衡需要配置ip_hash或使用独立 WebSocket 网关因为同一个房间的多人消息到达不同节点后内存里的 room 映射对不上这是另一个并发坑。5.3 代码执行接口千万别直接调宿主机的 shell现象候选人在编程题提交处输入import os; os.system(rm -rf /)本地开发机在几秒后变得异常缓慢数据库数据丢失。原因判题服务直接用了宿主机的命令行或 Java 的Runtime.exec()候选代码获得了和服务器同样的权限。解决按第 3.2 章讲的 Docker 容器隔离把候选代码运行在无网络、有内存和 CPU 限制、只读挂载的临时容器里容器内禁止写外部路径只在容器内输出结果。哪怕答辩环境不能装 Docker也要加一层白名单校验只允许候选代码调用不带参数的命令比如java Main.java而不是bash -c并且用ProcessBuilder传入代码而不是拼接 shell。但必须意识到这是权宜之计演示时可以说明生产环境必须容器化。实现判题容器时还要注意 Docker 命令本身的安全。命令里的${submitId}来自数据库不能直接把用户输入拼到镜像名或参数里要先用白名单校验该提交 ID 是否确实存在再docker wait不要用docker exec执行候选人代码。5.4 时间轴混乱时区、夏令时与考试倒计时现象候选人端显示“面试开始时间 10:00”面试官端看到的是“09:00”两个人同时进入面试间后状态不一致候选人提交的编程题耗时显示为 0 毫秒实际却等了三分钟。原因前后端、数据库分别用了不同的时区。前端 JS 拿到时间戳后按本地格式显示后端存的是datetime但没带时区数据库连接默认使用服务器时区而服务器可能是 UTC 或 CST 混着部署。解决前后端统一用 Unix 时间戳或 ISO 8601 带时区的字符串数据库列类型用timestamptz所有时间入参先转成 UTC 再存。展示时间时前端的dayjs(time).format(YYYY-MM-DD HH:mm)会按本机时区显示这样每个用户看到的是自己的本地时间。如果还涉及夏令时地区后端不要自己计算时差把原始时间传给前端让浏览器的操作系统去处理。还有一个隐藏问题面试倒计时用 setTimeout 计算的话页面切换标签会阻塞定时器。正确做法是每次setInterval计算“目标时间 - 当前系统时间”的差值而不是累积递减。5.5 打包交付前最后检查清单现象在开发机上一路通畅部署到评委电脑上就出现上传文件失败、WebSocket 连不上、Docker 镜像不存在三个问题。原因开发时用了硬编码的localhost:8080、依赖本机的环境变量、Docker 镜像没有打包进部署目录。解决打包前设置一个环境配置文件区分dev和prod前端构建时用 webpack 的DefinePlugin注入接口地址后端所有外部资源路径改为配置项不硬编码。需要提交给评委的压缩包里至少要包含源码、数据库脚本、部署说明、Dockerfile 或构建命令。这里给一个检查清单数据库脚本建库建表 初始数据执行两次不会报错前端构建产物dist目录是否已生成资源路径是否为相对路径后端启动脚本start.sh里是否包含 wait 数据库和初始化表Docker 镜像docker save成 tar 后是否随包带上上传目录服务启动时是否能自动创建时区JVM 启动参数加-Duser.timezoneAsia/Shanghai最后一步我会跑一遍docker compose up -d后用同一个浏览器无痕窗口打开三条流程候选人投简历、面试官改考试时间、管理端发起面试。这个三条流程跑通Viva 演示基本稳了。6. 让评委眼前一亮从“能跑”到“能答辩”的几个进阶细节6.1 用Redis ZSet做面试官评分排行榜评估表里有多位面试官给同一位候选人打分但面试系统通常还要展示“某位面试官本周已面试人数、平均分”以及让管理者快速看到哪个候选人综合评分最高。用 Redis ZSet 把candidateId作为 memberavgScore作为 score可以做到实时排名答辩时展示秒级刷新比 SQL 查询更抢眼。6.2 把面试过程重放提取“关键帧”视频面试的回放很长评委很难全看。我习惯在候选人端记录每次屏幕共享中“编辑代码超过 10 秒没有继续”的片段把它打上possible-keypoint标记回放页面提供“只看关键帧”按钮。这个设计能直接回应面试系统的实际价值不是所有录像都要逐秒看而是让面试官更快定位候选人的代码停顿和思考过程。6.3 数据看板从导表到可视化管理端导出 Excel 是毕设标配但只能展示静态数据。进阶做法是做一个admin/dashboard页面用ECharts展示在线面试总数、候选人状态漏斗、面试官平均评分。后端只需要提供两个聚合接口一个按日期统计面试数一个按状态统计人数前端使用柱状图和漏斗图。答辩时评委一定会问数据来源你直接说“由状态机表里的updated_at字段聚合生成统计结果用 Redis 缓存五秒”即可。6.4 答辩演示时的固定数据种子真实项目里数据是不断变化的但答辩演示半小时需要可控。我会在部署脚本里准备一个演示数据集五个候选人、三个面试官、两轮面试、一份成绩划分合理的评分记录。种子数据可以重置每次演示前先执行demo-reset.sh清空库并导回快照。这样演示时不用临时造数也不会让评委看到空荡荡的看板。我印象最深的一次翻车是我在演示前不小心把数据库里的面试状态全部改成了CLOSED导致候选人端没有可展示的“待面试”列表最后只能现场重新造数。从那以后我坚持把演示数据写成 SQL 脚本并纳入打包清单每次演示前跑一遍重置宁可多花一分钟也不在台上紧张。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/22 5:23:10 · 阅读 1.2k 面试系统核心设计：权限、状态机、判题沙箱与安全边界
简介面向计算机专业毕业设计与课程设计场景这套面试系统项目以“面试系统-毕设.zip”打包聚焦企业招聘流程数字化转型覆盖简历管理、面试预约、多维度评价、结果通知与数据统计分析等核心功能适合作为学习软件工程实践、参考系统架构的完整案例。资源共225个文件压缩包约3.9MB前端以76个js逻辑脚本和50个css样式为主后端含24个java代码文件并补充xml/json配置、数据库ER图与SQL脚本及图标字体等体量轻巧而结构完整便于直接对照需求文档进行二次开发。已有80人浏览学习项目页面采用Bootstrap/AdminLTE等常见框架前台交互逻辑与后台管理一目了然代码结构清晰、注释详尽可帮助读者了解从需求分析到系统落地的全过程。无论是作为毕设参考模板还是用于企业招聘流程优化在此完整方案基础上均能快速上手使用也可进一步扩展视频面试、AI辅助评估等新能力具有一定的工程实践价值。1. 面试系统为什么不能只搭个视频聊天室拿到“面试系统-毕设.zip”这个压缩包标题很多人第一反应是做个视频聊天室再挂个简历上传就收工。等答辩评委问“候选人答完题之后代码怎么判”“两个面试官同时打分怎么汇总”“简历文件传上来怎么防止它是个木马”的时候才发现整个系统的骨架其实是状态机和数据边界。本文不介绍某个现成压缩包而是按一线项目里最常见做法把面试系统拆成可演示、可解释、可继续扩展的方向模块取舍、表结构、判题沙箱、音视频存档和安全边界。适合准备把毕设做成“能答辩”而不仅是“能运行”的开发者也适合想在团队里做内部招聘工具的人参考。2. 从毕业设计到可演示系统拆解核心模块与数据模型2.1 候选人端、面试官端、管理端权限边界怎么划面试系统的第一个坑是三个角色共用同一张用户表然后靠前端按钮来隐藏功能。这种做法在演示时看不出问题但你一调接口拿到返回体就会发现候选人能调用面试官端的管理接口。我一般会让后端对每个接口做角色校验而不是只依赖页面渲染。后端权限判断可以统一做成注解。下面是 Spring Boot 风格的拦截器实现放在拦签约中校验当前登录人的角色字段。Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RoleRequired { String[] value(); }Component public class RoleInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (!(handler instanceof HandlerMethod hm)) { return true; } RoleRequired role hm.getMethodAnnotation(RoleRequired.class); if (role null) { role hm.getBeanType().getAnnotation(RoleRequired.class); } if (role null) { return true; } LoginUser user (LoginUser) request.getAttribute(loginUser); for (String r : role.value()) { if (user.getRoles().contains(r)) { return true; } } response.setStatus(403); return false; } }逻辑说明首先判断是不是方法处理器不是直接放行静态资源。然后从方法上的RoleRequired注解读角色列表方法上没有再去类上读。controller 层获取会话后先放入request属性这里从属性取值最终遍历要求的角色只要命中一个就放行。注意LoginUser里的角色建议用SetString避免contains时出现重复角色导致的性能损耗。权限边界我会拆成三层候选人和面试官都能看到面试日历但候选人只能看到分配给自己的面试官只能看到自己的待面试列表管理端可以看全部管理端的接口除了角色校验外还要校验数据归属比如修改面试时间时必须带上interviewId对应的面试官 ID防止越权跨人改时间。这里有一个容易被忽略的点角色名不要散落在代码字符串里。建议定义常量类Roles.CANDIDATE / Roles.INTERVIEWER / Roles.ADMIN避免拼写错误。如果时间紧不做注解也可以用request.getRequestURI().startsWith(/api/admin/)做粗粒度拦截但答辩时这种写法容易被认为是“个人习惯”而不是“方案”建议至少用枚举或常量收口。2.2 核心表结构简历、面试、评估与三方消息面试系统要能支撑完整业务闭环最少需要五张核心表用户表、简历表、面试表、评估表、消息表。简历表不直接存文件二进制只存文件路径和解析出的文本评估表和面试表分开的原因是一个面试官可以多次评估一次面试也可以有多人评估。下面用 PostgreSQL 方言给出核心表结构主键用雪花 ID字段统一用 snake_case。CREATE TABLE candidate_profile ( id BIGINT PRIMARY KEY, candidate_id BIGINT NOT NULL, resume_file_path VARCHAR(512) NOT NULL, resume_text TEXT, status VARCHAR(20) DEFAULT PENDING, created_at TIMESTAMPTZ DEFAULT now() ); CREATE TABLE interview ( id BIGINT PRIMARY KEY, title VARCHAR(128) NOT NULL, candidate_id BIGINT NOT NULL, interviewer_id BIGINT NOT NULL, start_time TIMESTAMPTZ NOT NULL, end_time TIMESTAMPTZ, status VARCHAR(20) DEFAULT SCHEDULED, room_token VARCHAR(64) ); CREATE TABLE evaluation ( id BIGINT PRIMARY KEY, interview_id BIGINT NOT NULL, interviewer_id BIGINT NOT NULL, dimension_code VARCHAR(32) NOT NULL, score INTEGER NOT NULL CHECK (score 0 AND score 10), comment TEXT, created_at TIMESTAMPTZ DEFAULT now() ); CREATE TABLE message ( id BIGINT PRIMARY KEY, sender_id BIGINT NOT NULL, receiver_id BIGINT NOT NULL, message_type VARCHAR(20) NOT NULL, payload TEXT, read_flag BOOLEAN DEFAULT FALSE, created_at TIMESTAMPTZ DEFAULT now() );参数说明resume_text用来做关键词检索答辩演示时可以展示“从简历中提取 JVM、Redis 等关键词命中候选岗位”room_token是视频面试间的临时凭证不要用自增 ID 拼到 URL 上否则候选人 A 能猜到 B 的面试间evaluation表用dimension_code表示“技术深度、沟通表达、团队协作”等维度方便后续做雷达图。message表payload用 JSON 文本比如发送试题目时携带{questionId: 12, duration: 30}。时间字段一定要用TIMESTAMPTZ不要把本地时间字符串存进去。简历文件路径建议用相对路径而不是D:/xxx/resume/1.pdf否则换电脑演示直接 404我习惯在配置里定义storage.root数据库存resume/202501/xxx.pdf前端拼完整地址。这张表还有一个反直觉的设计面试表里冗余了interviewer_id看起来应该在面试界面上通过多对多关联候选人和多个面试官。毕设场景建议做成一对多或者简单的“主面试官 助理面试官”字段因为多对多关联在答辩时很难两三句话说清楚还会引入额外关联表。如果确实需要多轮面试额外做interview_round表更清晰。2.3 业务状态机从投递到Offer的7个状态跳转面试系统最核心的不是画页面而是状态流转。我把状态定义为PENDING待筛选、SCREENED简历筛过、SCHEDULED已排期、IN_PROGRESS面试中、COMPLETED面试完成、OFFERED已发录取、CLOSED流程结束。这里的一个关键规则是状态只能由服务端代码推进不允许前端按钮任意切换。常见做法是在后端维护一个MapCurrentState, ListTransition或者用状态枚举表。以下展示用 Java 枚举做状态机的核心判断避免 if-else 满天飞。public enum InterviewState { PENDING, SCREENED, SCHEDULED, IN_PROGRESS, COMPLETED, OFFERED, CLOSED; private static final MapInterviewState, SetInterviewState TRANSITIONS Map.of( PENDING, Set.of(SCREENED, CLOSED), SCREENED, Set.of(SCHEDULED, CLOSED), SCHEDULED, Set.of(IN_PROGRESS, CLOSED), IN_PROGRESS, Set.of(COMPLETED, CLOSED), COMPLETED, Set.of(OFFERED, CLOSED), OFFERED, Set.of(CLOSED), CLOSED, Set.of() ); public boolean canTransitTo(InterviewState target) { return TRANSITIONS.get(this).contains(target); } }逻辑说明枚举里用Map.of声明每个状态允许到达的下一个状态。CLOSED是终态没有出口。业务代码里先判断canTransitTo允许时才去更新数据库并写入一条流转记录不允许时直接抛业务异常。这里要注意Map.of是 JDK 9 之后才有的如果目标环境是 JDK 8请换成Collections.unmodifiableMap(new HashMap() {{ put(...); }})。状态推动的代码要放在一个事务里避免出现“修改了状态但没发消息”的中间状态先尝试更新UPDATE interview SET status ? WHERE id ? AND status ?影响行数为 1 才继续插入 message 表和发送通知。这里用乐观锁的思路比先读再判断更稳。第 5 章的并发章节会再展开。为什么状态跳转要这么严格因为面试系统的各个入口都会依赖状态候选人端展示的是下一场面试倒计时面试官端展示的是待结束的面试列表管理端要统计各状态人数。如果前端直接把某个状态改成COMPLETED统计数据乱了不说候选人还可能在晚上十点收到“你的面试已完成”的奇怪消息。血泪经验是状态机的测试不写在接口层写在枚举层用assertEquals(false, PENDING.canTransitTo(IN_PROGRESS))这种方式做单元测试防止后续加状态时把跳转关系写坏。另外所有状态变更在写入时都应该触发事件。比如从SCHEDULED变成IN_PROGRESS时要生成面试间 room_token从COMPLETED变成OFFERED时要生成 Offer 附件。这块逻辑用异步事件监听器做不要放在主流程里同步拼装邮件模板。3. 在线笔试与代码考核模块可复现的最小实现3.1 创建在线编程题题干、测试用例与判题容器在线笔试的演示重点通常是“代码提交后到底有没有执行”。常见的思路是在后端写一个SystemClient直接挂到宿主机上跑编译和java -jar这样做演示很快但一次并发就把机器打崩还会被简历上传漏洞联动攻击。正确的骨架是题目表存题干和模板代码测试用例表存输入输出提交记录表存源码和判题状态。下面是一道编程题的 JSON 结构我习惯用它作为接口入参便于前端一次性拿到所有展示信息。{ questionId: 10023, title: 两数之和, difficulty: MEDIUM, description: 给定整数数组 nums 和整数 target返回两个数的下标。, templateCode: { java: class Solution { public int[] twoSum(int[] nums, int target) { ... } }, python: class Solution: def twoSum(self, nums, target): ... }, testCases: [ {input: [2,7,11,15]\\n9, output: [0,1]}, {input: [3,2,4]\\n6, output: [1,2]} ], timeLimitMs: 1000, memoryLimitMb: 256 }逻辑说明templateCode里不存完整答案只存方法签名候选人进来先看到模板testCases的输入和输出都转义成字符串判题时拼成标准输入和期望输出这样能统一不同编程语言的处理方式。timeLimitMs和memoryLimitMb是提交给判题容器的资源上限毕设阶段可以只对提交代码的容器做限制另一份样例分析用的容器可以共享。这里有需要在答辩时专门讲的点题目表里不能把输出结果直接放明文因为候选人可能通过接口返回体直接看到测试用例输出。我一般会在创建题目时把测试用例加密存到单独表比如用SHOW_AFTER_DDL的开关控制只有判题服务在容器内部能读到解密后的用例普通查询接口只返回 case 数量。3.2 判题结果如何安全回收沙箱执行与超时限制判题服务是整个面试系统里最容易翻车的地方。网络上的教程会让你直接调用Runtime.getRuntime().exec(javac Main.java)这在本地单机没问题但面试系统要 demo 给别人看时一次死循环就能让 CPU 占满整个系统卡死。我推荐用 Docker 容器做隔离判题单元每次提交都新建一个临时容器运行完立即删除。docker run --rm \ --network none \ --memory 256m \ --cpus 1 \ --pids-limit 64 \ -v /tmp/judge/${submitId}:/workspace:ro \ -w /workspace \ --name judge-${submitId} \ judge-image java -jar Runner.jar timeout 15s docker wait judge-${submitId} || { docker kill judge-${submitId}; echo timeout; }参数说明--network none禁止容器联网防止提交的代码向外发送数据--memory 256m限制内存--cpus 1限制 CPU 核数--pids-limit 64防止开启大量线程挂载目录用只读方式候选人提交的资源只让容器读取不允许回写。最后一行是容器级别的超时如果 15 秒没有结束就 kill。不要只靠timeout命令因为 Java 进程可能收到 SIGTERM 后还在运行配合docker kill才是双保险。在客户端代码里调用这条命令时要保持日志完整。判题会有ACCEPTED、WRONG_ANSWER、TIME_LIMIT_EXCEEDED、RUNTIME_ERROR四种结果。我通常会在judge-result.json里额外记录容器退出码、实际耗时、内存峰值方便答辩时展示“这个系统不是黑匣子”。需要关注的是 Docker 镜像体积。每个提交都docker run镜像拉取是预先完成的不要等提交时再docker pull否则第一次提交会等几十秒。毕设阶段可以提前把镜像docker save成 tar部署脚本里docker load并把基础镜像固定为某个特定的 tag不要用latest否则不同的机器上行为不稳定这就是典型的“在我电脑上能判换个环境就报错”。3.3 实时协同现场coding用WebSocket做逐行记录编程题之外视频面试里常有一个“现场写代码”环节候选人写代码面试官在另一边同步看到。实现它的重点不是把编辑器里的内容每次全量发送而是记录编辑器变更事件用 WebSocket 推给面试官端。// 候选人端监听编辑器的 change 事件 editor.on(change, (change) { const payload { type: code-delta, roomId: currentRoomId, version: change.version, delta: { startRow: change.start.row, startCol: change.start.column, endRow: change.end.row, endCol: change.end.column, text: change.text } }; ws.send(JSON.stringify(payload)); });逻辑说明delta只携带变更的行列范围和插入文本而不是每次把全量代码发过去这样在网络抖动时不会瞬间打爆消息队列。version字段对应文档触发的版本号面试官端收到后按版本号逐个应用可以做到不丢更新。面试官端收到消息后要执行editor.updateDocument(delta)并且把光标移动到变更位置。最有意思的是很多实现会直接把 delta 应用到只读的 Editor导致面试官端光标乱跳。正确做法是维护一个独立的viewModel不跟随候选人光标只应用内容变更候选人的光标位置单独用cursor-update消息推送面试官可以选择是否打开“跟随候选人光标”开关。这套方案最大的坑是后端需要在内存里维护一个room - clientId - session的映射。如果只把 WebSocket 会话放在内存而没做心跳当候选人电脑休眠后服务端仍然认为在线面试官就会看到一个“已经断线但直播间状态还是进行中”的假象。我一般会让客户端每 30 秒发一次ping服务端 60 秒内没收到就标记离线同时通知面试官端。这也是第五章里并发面试间会展开的一个点。4. 视频面试模块信令、录制与简历同屏的坑4.1 音视频选型为什么毕设不推荐自己推流视频面试模块最大的误解是以为要从零写一套推流、拉流、丢包重传协议。毕设答辩要的是“能说清楚架构”而不是“我写了 2000 行 RTP 封装”。我建议直接用浏览器原生的 WebRTC 能力服务端只做信令转发媒体流走 P2P 模式。在纯局域网演示时两人视频加屏幕共享对带宽要求很低答辩现场完全够用。P2P 模式下服务端信令服务器最简实现是用 WebSocket 中转 SDP 和 ICE 候选。候选人端和面试官端各创建各自的 RTCPeerConnection交换 offer/answer 后浏览器会自己打通音视频通道。但这里有个风险一旦评委现场让“面试官和候选人不在同一局域网”P2P 的 ICE 可能找不到对方此时会黑屏。所以生产化的解决方案是部署一个 SFU 媒体网关让两端都只向网关推流。听上去很高深其实可以这样回答评委“我这里采用的是 WebRTC 点对点实时传输同时服务端设计了可替换的 SFU 网关接口当接入层数增长时把 PeerConnection 换成转发式网关不影响业务层。” 你甚至可以做一张简单的接口表把音视频相关接口定义成RtcGateway接口默认实现是 P2P预留 SFU 实现这就是一个很好的扩展性体现。要注意的是信令服务器不能只把 SDP 广播给房间里的所有人。面试间里最多有 3 到 5 个人但候选人和面试官的数据流是不同的候选人要共享屏幕面试官要收流、发麦克风。所以发消息时带targetClientId不要用广播。4.2 录制存档方案本地录音屏幕录制的双轨备份面试系统如果只做实时通话面试官说“刚才候选人答得不错”但没有证据答辩演示就会很虚。完整的方案是在前端做两路录制候选人端录制自己的屏幕和声音面试官端录制自己的麦克风两路文件都上传到后端后后台可以按时间轴对齐回放。用浏览器 MediaRecorder 可以拿到本地录制流以下代码示意候选人端在收到interview-start消息时启动录制。const combined new MediaStream([ ...screenStream.getVideoTracks(), ...micStream.getAudioTracks() ]); const recorder new MediaRecorder(combined, { mimeType: video/webm }); recorder.ondataavailable (e) { if (e.data.size 0) { uploadChunk(e.data, currentRoomId); } }; recorder.start(3000);参数说明start(3000)表示每 3 秒生成一个分片并上传避免长时间录制时内存占用过大。mimeType用video/webm因为 Chrome 下默认录制 mp4 支持不稳定。上传接口需要带roomId和sessionId字段后端用minio或者本地磁盘存储文件路径由时间戳分目录比如record/202501/xxx/screen1.webm。如果是纯面试录音而不录屏可以把video/webm改成audio/webm文件更小但丢失了候选人写代码的画面。这里容易踩的一个坑是 MediaRecorder 在面试官端如果只录麦克风会出现录音里掺杂扬声器回放的声音。更好的做法是面试官端只录自己的的身份麦克风同时把候选人上传的屏幕录制作为主回放轨后台房间回放页用两个video标签分别摆在不同位置。回放时不要用前端拼接音频直接用两个文件同步播放是 demo 里的最优解省得转码。4.3 面试官看候选人简历的同步视角维护视频面试时面试官往往一边看候选人回答一边翻看简历。如果两头各看各的面试官问“你简历里这个项目为什么用 Redis”时候选人端完全不知道面试官在看哪一行。更好的做法是面试官端主动分享简历浏览位置候选人端可以打开“跟随”按钮让简历自动滚动到面试官正在看的位置附近。// 面试官端滚动事件防抖后发送位置 container.addEventListener(scroll, () { const percent container.scrollTop / (container.scrollHeight - container.clientHeight); ws.send(JSON.stringify({ type: resume-scroll, roomId: currentRoomId, percent: Number(percent.toFixed(4)) })); });逻辑说明percent是一个 0 到 1 的小数代表滚动位置占整份简历的比例。候选人端收到后如果开启了“跟随”就执行container.scrollTop percent * (scrollHeight - clientHeight)。注意这里要防抖否则每次滚动都触发消息带宽和 UI 更新压力都很大我在实际写法里会用 throttle 函数每 200 毫秒发送一次。这个模块还有两个细节第一简历图片不要在 WebSocket 消息里携带 base64只传 percent图片本身通过 HTTP 加载第二同步滚动要在候选人端设置“跟随开关”有效期为当前面试场次面试结束后自动关闭。如果不做开关面试官翻到第三页候选人端简历也会乱跳候选人边看题边跟着滚动很影响注意力。答辩时把这个功能称为“同步视图”比单独展示视频通话更有记忆点。5. 面试系统避坑指南安全、并发送审与本地环境5.1 文件上传漏洞简历里的“图片”可能不是图片现象候选人上传一个photo.jpg服务端返回成功但数据库里存的文件路径打开是个 502更严重的情况这个文件实际上是个 JSP 或 PHP 脚本攻击者通过访问上传路径拿到执行权限。原因文件上传只校验了扩展名和 Content-Type这两个都能被伪造。浏览器给出的multipart/form-data中文件名是photo.jsp.jpg服务端没有做白名单校验也没检查文件真实内容。解决第一校验扩展名白名单只允许pdf, docx, jpg, png等第二校验文件魔数读文件头几个字节PDF 是%PDFJPG 是FF D8 FF第三把上传目录设为不可执行并将文件名改为服务端生成的 UUID 加上白名单扩展名。最小演示可以用下面的 Java 片段。byte[] header new byte[4]; fileInputStream.read(header); if (!isAllowedMagic(header, extension)) { throw new BizException(file type not allowed); } String safeName UUID.randomUUID() . extension;这里要特别提一句不要用new File(uploadDir / originalFilename)直接拼接路径路径穿越会被../../写成别的目录。正确的做法是自己生成文件路径然后用Paths.get(uploadRoot).resolve(safeName).normalize()并检查最终路径仍然在 uploadRoot 内。5.2 面试间并发测试WebSocket连不上先查Nginx现象本地直接跑后端服务多人同时打开面试间HTTP 接口正常但 WebSocket 一直提示连接失败关掉 Nginx 反向代理直连后端端口又是好的。原因Nginx 默认对升级后的连接只给 60 秒空闲超时而 WebSocket 长时间空闲不发消息就会被proxy_read_timeout切掉。解决在 Nginx 服务的 location 配置里显式调大超时并关闭 HTTP 代理缓冲增加 WebSocket 心跳保持连接。心跳本身就是 30 秒一次超时设为 75 秒。location /ws { proxy_pass http://backend-server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 75s; proxy_send_timeout 75s; proxy_buffering off; }参数说明proxy_http_version 1.1是 WebSocket 升级的必要条件proxy_set_header Connection upgrade告诉上游这个连接要升级协议proxy_buffering off避免 Nginx 缓冲消息导致实时性下降。另外如果系统里用了负载均衡需要配置ip_hash或使用独立 WebSocket 网关因为同一个房间的多人消息到达不同节点后内存里的 room 映射对不上这是另一个并发坑。5.3 代码执行接口千万别直接调宿主机的 shell现象候选人在编程题提交处输入import os; os.system(rm -rf /)本地开发机在几秒后变得异常缓慢数据库数据丢失。原因判题服务直接用了宿主机的命令行或 Java 的Runtime.exec()候选代码获得了和服务器同样的权限。解决按第 3.2 章讲的 Docker 容器隔离把候选代码运行在无网络、有内存和 CPU 限制、只读挂载的临时容器里容器内禁止写外部路径只在容器内输出结果。哪怕答辩环境不能装 Docker也要加一层白名单校验只允许候选代码调用不带参数的命令比如java Main.java而不是bash -c并且用ProcessBuilder传入代码而不是拼接 shell。但必须意识到这是权宜之计演示时可以说明生产环境必须容器化。实现判题容器时还要注意 Docker 命令本身的安全。命令里的${submitId}来自数据库不能直接把用户输入拼到镜像名或参数里要先用白名单校验该提交 ID 是否确实存在再docker wait不要用docker exec执行候选人代码。5.4 时间轴混乱时区、夏令时与考试倒计时现象候选人端显示“面试开始时间 10:00”面试官端看到的是“09:00”两个人同时进入面试间后状态不一致候选人提交的编程题耗时显示为 0 毫秒实际却等了三分钟。原因前后端、数据库分别用了不同的时区。前端 JS 拿到时间戳后按本地格式显示后端存的是datetime但没带时区数据库连接默认使用服务器时区而服务器可能是 UTC 或 CST 混着部署。解决前后端统一用 Unix 时间戳或 ISO 8601 带时区的字符串数据库列类型用timestamptz所有时间入参先转成 UTC 再存。展示时间时前端的dayjs(time).format(YYYY-MM-DD HH:mm)会按本机时区显示这样每个用户看到的是自己的本地时间。如果还涉及夏令时地区后端不要自己计算时差把原始时间传给前端让浏览器的操作系统去处理。还有一个隐藏问题面试倒计时用 setTimeout 计算的话页面切换标签会阻塞定时器。正确做法是每次setInterval计算“目标时间 - 当前系统时间”的差值而不是累积递减。5.5 打包交付前最后检查清单现象在开发机上一路通畅部署到评委电脑上就出现上传文件失败、WebSocket 连不上、Docker 镜像不存在三个问题。原因开发时用了硬编码的localhost:8080、依赖本机的环境变量、Docker 镜像没有打包进部署目录。解决打包前设置一个环境配置文件区分dev和prod前端构建时用 webpack 的DefinePlugin注入接口地址后端所有外部资源路径改为配置项不硬编码。需要提交给评委的压缩包里至少要包含源码、数据库脚本、部署说明、Dockerfile 或构建命令。这里给一个检查清单数据库脚本建库建表 初始数据执行两次不会报错前端构建产物dist目录是否已生成资源路径是否为相对路径后端启动脚本start.sh里是否包含 wait 数据库和初始化表Docker 镜像docker save成 tar 后是否随包带上上传目录服务启动时是否能自动创建时区JVM 启动参数加-Duser.timezoneAsia/Shanghai最后一步我会跑一遍docker compose up -d后用同一个浏览器无痕窗口打开三条流程候选人投简历、面试官改考试时间、管理端发起面试。这个三条流程跑通Viva 演示基本稳了。6. 让评委眼前一亮从“能跑”到“能答辩”的几个进阶细节6.1 用Redis ZSet做面试官评分排行榜评估表里有多位面试官给同一位候选人打分但面试系统通常还要展示“某位面试官本周已面试人数、平均分”以及让管理者快速看到哪个候选人综合评分最高。用 Redis ZSet 把candidateId作为 memberavgScore作为 score可以做到实时排名答辩时展示秒级刷新比 SQL 查询更抢眼。6.2 把面试过程重放提取“关键帧”视频面试的回放很长评委很难全看。我习惯在候选人端记录每次屏幕共享中“编辑代码超过 10 秒没有继续”的片段把它打上possible-keypoint标记回放页面提供“只看关键帧”按钮。这个设计能直接回应面试系统的实际价值不是所有录像都要逐秒看而是让面试官更快定位候选人的代码停顿和思考过程。6.3 数据看板从导表到可视化管理端导出 Excel 是毕设标配但只能展示静态数据。进阶做法是做一个admin/dashboard页面用ECharts展示在线面试总数、候选人状态漏斗、面试官平均评分。后端只需要提供两个聚合接口一个按日期统计面试数一个按状态统计人数前端使用柱状图和漏斗图。答辩时评委一定会问数据来源你直接说“由状态机表里的updated_at字段聚合生成统计结果用 Redis 缓存五秒”即可。6.4 答辩演示时的固定数据种子真实项目里数据是不断变化的但答辩演示半小时需要可控。我会在部署脚本里准备一个演示数据集五个候选人、三个面试官、两轮面试、一份成绩划分合理的评分记录。种子数据可以重置每次演示前先执行demo-reset.sh清空库并导回快照。这样演示时不用临时造数也不会让评委看到空荡荡的看板。我印象最深的一次翻车是我在演示前不小心把数据库里的面试状态全部改成了CLOSED导致候选人端没有可展示的“待面试”列表最后只能现场重新造数。从那以后我坚持把演示数据写成 SQL 脚本并纳入打包清单每次演示前跑一遍重置宁可多花一分钟也不在台上紧张。希望帮到你。本文还有配套的精品资源点击获取