简介：面向计算机专业毕业设计与课程设计场景，这套面试系统项目以“面试系统-毕设.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里的角色建议用Set<String>，避免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（流程结束）。这里的一个关键规则是：状态只能由服务端代码推进，不允许前端按钮任意切换。
常见做法是在后端维护一个Map<CurrentState, List<Transition>>或者用状态枚举表。以下展示用 Java 枚举做状态机的核心判断，避免 if-else 满天飞。
public enum InterviewState { PENDING, SCREENED, SCHEDULED, IN_PROGRESS, COMPLETED, OFFERED, CLOSED; private static final Map<InterviewState, Set<InterviewState>> 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 是%PDF，JPG 是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.timezone=Asia/Shanghai
最后一步我会跑一遍docker compose up -d后，用同一个浏览器无痕窗口打开三条流程：候选人投简历、面试官改考试时间、管理端发起面试。这个三条流程跑通，Viva 演示基本稳了。
6. 让评委眼前一亮：从“能跑”到“能答辩”的几个进阶细节
6.1 用Redis ZSet做面试官评分排行榜
评估表里有多位面试官给同一位候选人打分，但面试系统通常还要展示“某位面试官本周已面试人数、平均分”，以及让管理者快速看到哪个候选人综合评分最高。用 Redis ZSet 把candidateId作为 member，avgScore作为 score，可以做到实时排名，答辩时展示秒级刷新比 SQL 查询更抢眼。
6.2 把面试过程重放提取“关键帧”
视频面试的回放很长，评委很难全看。我习惯在候选人端记录每次屏幕共享中“编辑代码超过 10 秒没有继续”的片段，把它打上possible-keypoint标记，回放页面提供“只看关键帧”按钮。这个设计能直接回应面试系统的实际价值：不是所有录像都要逐秒看，而是让面试官更快定位候选人的代码停顿和思考过程。
6.3 数据看板：从导表到可视化
管理端导出 Excel 是毕设标配，但只能展示静态数据。进阶做法是做一个admin/dashboard页面，用ECharts展示在线面试总数、候选人状态漏斗、面试官平均评分。后端只需要提供两个聚合接口：一个按日期统计面试数，一个按状态统计人数；前端使用柱状图和漏斗图。答辩时评委一定会问数据来源，你直接说“由状态机表里的updated_at字段聚合生成，统计结果用 Redis 缓存五秒”即可。
6.4 答辩演示时的固定数据种子
真实项目里数据是不断变化的，但答辩演示半小时需要可控。我会在部署脚本里准备一个演示数据集：五个候选人、三个面试官、两轮面试、一份成绩划分合理的评分记录。种子数据可以重置，每次演示前先执行demo-reset.sh清空库并导回快照。这样演示时不用临时造数，也不会让评委看到空荡荡的看板。
我印象最深的一次翻车，是我在演示前不小心把数据库里的面试状态全部改成了CLOSED，导致候选人端没有可展示的“待面试”列表，最后只能现场重新造数。从那以后，我坚持把演示数据写成 SQL 脚本并纳入打包清单，每次演示前跑一遍重置，宁可多花一分钟也不在台上紧张。希望帮到你。
本文还有配套的精品资源，点击获取
