在线考试倒计时到底应该以前端还是服务器为准？浏览器时间漂移、断网与服务端校时设计

摘要

在线考试系统中，"还剩多少分钟"看起来只是一个简单的倒计时组件，但真正进入正式考试场景以后，时间控制往往比想象中复杂。

如果考试规定60分钟，考生刷新页面以后还能剩多少时间？

电脑本地时间被修改以后，倒计时会不会发生变化？

网络断开10分钟，这10分钟算不算考试时间？

浏览器倒计时已经归零，但最后一道题的保存请求还在网络中传输，系统应该接收还是拒绝？

如果应用服务器有多台，不同服务器之间存在几十毫秒甚至几百毫秒时间偏差，又应该以谁的时间为准？

因此，一个可靠的在线考试倒计时不能只依赖前端 setInterval()，也不能简单地每秒请求一次服务器。

更合理的思路应该是：

Server Time → Exam Session → StartTime → Deadline → 前端倒计时 → 周期校时 → 断线重连 → 服务端最终判定 → 自动交卷

其中最核心的一条原则是：

前端时间用于展示，服务器时间用于裁决。

本文结合企业在线考试实际场景，分析浏览器时间为什么不能作为权威时间源、网络延迟如何处理、刷新页面为什么不能重置倒计时、Redis中的Exam Session如何与数据库配合，以及考试到点以后究竟应该由前端还是服务器自动交卷。

一、一个常见问题：考试剩余时间到底是谁算的？

假设一场考试：

复制代码

考试时长：60分钟

考生开始时间：
10:00:00

理论结束时间：
11:00:00

最简单的前端实现可能是：

复制代码

let remaining = 60 * 60;

setInterval(() => {
    remaining--;

    if (remaining <= 0) {
        submitExam();
    }
}, 1000);

看起来没有问题。

但只要进入真实环境，就会立即出现很多问题。

例如：

复制代码

10:00
进入考试

10:15
刷新浏览器

10:15
JavaScript重新执行

如果前端重新初始化：

复制代码

remaining = 60 * 60;

那么考生相当于又获得60分钟。

这显然不正确。

所以考试时间不能理解成：

页面打开后开始倒计时。

而应该理解成：

服务器已经确定了一个考试Session，以及这个Session什么时候必须结束。

二、考试倒计时真正应该保存什么？

一个比较可靠的Exam Session至少应该包含几个时间字段：

复制代码

ExamSession

sessionId
userId
examId

startTime
deadline
serverTime
submitTime

status

例如：

复制代码

SessionID：
ES202608090001

StartTime：
2026-08-09 10:00:00

Deadline：
2026-08-09 11:00:00

Status：
RUNNING

前端刷新页面以后，不应该重新计算：

复制代码

当前时间 + 60分钟

而应该重新请求：

复制代码

ExamSession.deadline

然后根据：

复制代码

deadline - serverTime

重新显示剩余时间。

所以页面刷新本质上只应该：

重新加载考试Session。

而不应该：

重新创建考试时间。

三、第一条原则：不要信任浏览器本地时间

很多Web系统会直接使用：

复制代码

Date.now()

获取当前时间。

普通业务场景问题可能不大，但正式考试不能把它作为权威依据。

为什么？

因为浏览器时间来自：

考生电脑的操作系统时间。

而操作系统时间是可以修改的。

例如：

真实时间：

复制代码

10:50

考生把Windows系统时间修改为：

复制代码

10:20

如果前端使用：

复制代码

deadline - Date.now()

计算剩余时间，就可能突然从：

复制代码

10分钟

变成：

复制代码

40分钟

这就是典型的客户端时间不可信问题。

因此：

考试系统绝不能根据客户端当前时间决定考试是否结束。

四、修改Windows时间能不能延长考试？

如果系统设计正确：

不能。

因为真正的Deadline保存在服务器端。

例如：

复制代码

StartTime  = 10:00:00
Duration   = 60分钟

Deadline   = 11:00:00

当考生提交答案时，服务器检查：

复制代码

ServerNow <= Deadline

而不是：

复制代码

ClientNow <= Deadline

即使用户把Windows时间改成：

复制代码

09:00

服务器仍然知道：

复制代码

当前真实时间已经11:01

那么请求应该进入：

复制代码

EXAM_TIMEOUT

而不是继续允许答题。

所以：

客户端时间不能决定考试资格。

五、既然服务器最准，为什么不每秒请求服务器？

有些开发人员可能会想到：

既然不能相信浏览器时间，那就每秒调用一次接口：

复制代码

GET /exam/time

服务器返回：

复制代码

59:59
59:58
59:57
......

这种方式理论上准确，但工程上并不合理。

假设：

复制代码

30000人同时考试

每人：

复制代码

每秒请求一次

就意味着：

复制代码

30000 QPS

而这些请求只是为了显示倒计时。

完全没有必要。

更加合理的方法是：

服务器给前端一个可信的时间基准，前端在本地平滑倒计时，再定期与服务器校准。

六、推荐方案：服务器时间基准 + 前端相对计时

考生进入考试以后，服务器可以返回：

复制代码

{
    "sessionId": "ES202608090001",
    "serverTime": 1786240800000,
    "startTime": 1786240800000,
    "deadline": 1786244400000
}

前端收到数据以后，首先得到：

复制代码

remaining =
deadline - serverTime

例如：

复制代码

3600000ms

也就是：

复制代码

60分钟

然后前端开始本地显示倒计时。

但这里还有一个细节。

最好不要简单依赖：

复制代码

Date.now()

不断计算。

因为用户修改操作系统时间可能导致Date.now()跳变。

浏览器端更适合采用：

复制代码

performance.now()

这类单调递增时间源记录经过时长。

例如：

复制代码

const baseServerTime = response.serverTime;
const basePerfTime = performance.now();

function getEstimatedServerTime() {
    return baseServerTime
        + (performance.now() - basePerfTime);
}

然后：

复制代码

function getRemainingTime() {
    return deadline - getEstimatedServerTime();
}

这种方式有一个明显优势：

即使用户修改Windows系统时间，

performance.now()表示的仍然主要是：

页面生命周期中的相对经过时间。

因此倒计时显示不会因为系统时间突然被修改而明显跳动。

七、但performance.now()也不是最终裁判

需要特别强调：

即使使用：

复制代码

performance.now()

前端时间仍然只能作为：

UI显示依据。

不能作为最终考试规则。

因为：

浏览器页面可能被冻结；
电脑可能进入休眠；
JavaScript线程可能长时间阻塞；
浏览器可能崩溃；
用户可以修改前端代码；
开发者工具可以修改变量。

因此最终仍然必须执行：

复制代码

Server Validation

即：

浏览器负责告诉考生"还有多久"，服务器负责决定"你到底还能不能答"。

八、网络延迟会不会导致倒计时不准？

会。

例如：

服务器在：

复制代码

10:00:00.000

生成响应。

由于网络延迟，浏览器可能在：

复制代码

10:00:00.600

才收到响应。

如果前端直接认为：

复制代码

serverTime = 10:00:00.000

那么理论上就存在：

复制代码

600ms

误差。

对于普通企业考试来说，这个误差通常不是核心问题。

但如果希望更严谨，可以引入类似NTP的往返时间估算。

假设：

复制代码

T1：客户端发请求时间
T2：服务器返回时间
T3：客户端收到时间

网络往返时间：

复制代码

RTT = T3 - T1

可以近似认为单程网络耗时：

复制代码

RTT / 2

前端可以估计：

复制代码

EstimatedServerTime =
ServerTime + RTT / 2

例如：

复制代码

RTT = 400ms

那么可以把服务器时间向前补偿：

复制代码

200ms

这样显示会更加接近真实服务器时间。

九、不要为了200毫秒，把系统设计得过度复杂

工程实践中还需要注意：

考试系统和金融高频交易不是同一种业务。

通常没有必要为了几十毫秒误差建立非常复杂的时间同步体系。

企业考试更需要解决的是：

复制代码

页面刷新

断网

电脑休眠

系统时间修改

服务器重启

Session丢失

多服务器时间差

最后一秒交卷

而不是追求：

复制代码

±1ms

的计时精度。

真正重要的是：

规则一致。

例如所有考生最终都按照服务器Deadline判定。

这比让每台电脑的倒计时绝对精确到毫秒更加重要。

十、固定考试时段和个人考试时长必须区分

在线考试通常有两种时间模式。

模式一：固定考试窗口

例如：

复制代码

考试开放：
09:00---11:00

所有人必须：

复制代码

11:00前交卷

即使员工：

复制代码

10:50

才进入考试，也只能剩：

复制代码

10分钟

这种模式：

复制代码

Deadline = ExamEndTime

模式二：进入考试后独立计时

例如：

复制代码

考试开放：
09:00---18:00

个人考试时长：
60分钟

员工：

复制代码

10:00进入

则：

复制代码

Deadline = 11:00

员工：

复制代码

14:00进入

则：

复制代码

Deadline = 15:00

十一、如果同时存在"考试结束时间"和"个人时长"呢？

企业考试中经常存在：

复制代码

考试开放时间：
09:00---12:00

个人考试时长：
60分钟

员工：

复制代码

11:30

才进入考试。

这时候还能不能考到：

复制代码

12:30？

通常需要根据业务规则确定。

比较常见的设计是：

复制代码

Deadline =
min(
    StartTime + Duration,
    ExamEndTime
)

那么：

复制代码

StartTime：
11:30

Duration：
60分钟

个人理论结束：
12:30

考试统一关闭：
12:00

最终：

复制代码

Deadline = 12:00

剩余时间：

复制代码

30分钟

这类规则一定要在后端计算完成。

不要让前端自己决定。

十二、刷新页面为什么不能重新计时？

当考试Session第一次创建后：

复制代码

StartTime
Deadline

应该已经固定。

刷新页面只执行：

复制代码

GET ExamSession

服务器返回：

复制代码

{
    "status": "RUNNING",
    "startTime": "...",
    "deadline": "...",
    "serverTime": "..."
}

前端重新计算：

复制代码

RemainingTime =
Deadline - ServerTime

这样：

复制代码

刷新1次

刷新10次

关闭浏览器重新打开

只要还是同一个Exam Session，

考试Deadline都不会改变。

十三、断网以后，考试时间应该暂停吗？

这是用户非常容易搜索的问题：

在线考试断网以后，时间还会继续走吗？

答案不是技术问题，而首先是：

考试规则问题。

通常有两种模式。

模式A：断网不停表

大多数正式企业考试更适合这种模式。

例如：

复制代码

开始时间：
10:00

结束时间：
11:00

考生：

复制代码

10:20断网

10:30恢复

恢复后应该剩：

复制代码

30分钟

而不是：

复制代码

40分钟

因为Deadline没有改变。

这可以防止考生主动：

复制代码

断开网络

↓

暂停考试时间

↓

查资料

↓

重新连接

模式B：断网暂停计时

某些特殊内部练习可能允许。

但这种方案复杂得多。

因为系统必须可靠判断：

复制代码

是真的断网？

还是主动关闭页面？

是网络故障？

还是故意拔网线？

还需要记录：

复制代码

DisconnectTime

ReconnectTime

PauseDuration

并重新计算：

复制代码

Deadline += PauseDuration

对于正式考试，一般需要非常谨慎。

十四、断网10分钟后重新进入，系统应该做什么？

更合理的流程不是：

复制代码

页面重新初始化60分钟

而是：

复制代码

重新连接服务器

↓

验证Token

↓

读取Exam Session

↓

查询Server Time

↓

读取Deadline

↓

恢复Answer Snapshot

↓

重新计算剩余时间

↓

继续考试

例如：

复制代码

Deadline：
11:00

Reconnect ServerTime：
10:37

那么服务器返回：

复制代码

Remaining：
23分钟

前端继续显示：

复制代码

22:59
22:58
......

十五、如果恢复网络时已经超过Deadline怎么办？

例如：

复制代码

Deadline：
11:00

断网时间：
10:55

恢复时间：
11:03

此时系统应该判断：

复制代码

ServerNow > Deadline

考试已经超时。

不能因为考生页面上还停留在：

复制代码

剩余5分钟

就继续允许答题。

服务器可以直接返回：

复制代码

EXAM_TIMEOUT

并进入：

复制代码

自动交卷

↓

恢复最后一次成功保存答案

↓

生成最终成绩

这也是为什么：

服务端Deadline必须是最终裁判。

十六、前端应该多久和服务器校时一次？

不需要每秒。

可以采用：

复制代码

进入考试时校时一次

↓

每隔30秒或60秒校时

↓

页面恢复焦点时校时

↓

网络重新连接时校时

↓

提交答案异常时重新校时

↓

最后几分钟适当提高校时频率

例如：

复制代码

考试正常阶段：
60秒校时一次

最后5分钟：
20秒校时一次

当然，这不是固定标准。

具体频率要根据：

复制代码

并发人数

服务器容量

考试重要程度

网络质量

进行调整。

十七、校时以后发现偏差怎么办？

假设前端显示：

复制代码

剩余20:35

服务器重新校时以后发现实际应该：

复制代码

剩余20:30

偏差：

复制代码

5秒

如果立即把页面从：

复制代码

20:35

跳到：

复制代码

20:30

用户可能会感觉：

"考试系统突然少了5秒。"

更加友好的方式可以是：

小偏差：

复制代码

平滑修正

大偏差：

复制代码

立即校准

例如：

复制代码

|offset| < 2秒

可以慢慢消化误差。

如果：

复制代码

|offset| > 5秒

直接重新同步。

但需要强调：

这只是：

倒计时显示策略。

服务器Deadline从来没有改变。

十八、浏览器标签页切到后台会发生什么？

现代浏览器会对后台标签页进行：

复制代码

Timer Throttling

也就是说：

复制代码

setInterval(fn, 1000)

并不保证真的每隔：

复制代码

1000ms

执行一次。

后台标签页可能：

复制代码

几秒

几十秒

才执行。

因此这种写法：

复制代码

remaining--;

存在明显问题。

因为：

如果JavaScript暂停了10秒，只执行一次：

复制代码

remaining--

倒计时就会少走9秒。

正确思路应该是：

复制代码

剩余时间 =
Deadline
-
EstimatedServerTime

而不是：

复制代码

每执行一次Timer就减1秒

这是在线考试倒计时非常重要的一个前端设计差异。

十九、电脑休眠以后怎么办？

例如：

复制代码

10:00开始考试

10:20电脑休眠

10:40恢复

如果使用：

复制代码

remaining--

浏览器休眠期间JavaScript可能根本没有执行。

恢复以后可能仍然显示：

复制代码

40分钟

实际上应该剩：

复制代码

20分钟

因此恢复页面时应该立即：

复制代码

重新请求Server Time

↓

读取Deadline

↓

校准剩余时间

例如监听：

复制代码

document.addEventListener(
    "visibilitychange",
    syncServerTime
);

另外还可以监听：

复制代码

online

focus

pageshow

等事件进行校时。

二十、服务器时间本身会不会不一致？

如果在线考试系统只有一台应用服务器，问题相对简单。

但大型考试可能有：

复制代码

Load Balancer

↓

App Server 01
App Server 02
App Server 03
App Server 04

第一次请求：

复制代码

Server01

下一次请求可能：

复制代码

Server03

如果不同服务器时间存在：

复制代码

3秒

偏差，前端就可能出现倒计时跳动。

所以多节点考试系统必须保证：

服务器自身时间同步。

通常可以通过：

复制代码

NTP / Chrony

等时间同步机制，使服务器保持在一个足够小的误差范围。

在线考试系统不能只考虑：

复制代码

客户端校时

还必须考虑：

复制代码

服务器集群校时

二十一、数据库时间还是应用服务器时间？

这里还有一个常见问题：

到底使用：

复制代码

数据库NOW()

还是：

复制代码

应用服务器System.currentTimeMillis()

作为权威时间？

没有绝对唯一答案。

关键是：

一个考试业务链路必须保持时间源一致。

如果：

复制代码

创建Session

使用应用服务器时间；

而：

复制代码

判定超时

使用数据库时间；

同时两台机器又存在较大时间偏差，就可能出现边界问题。

因此首先应该保证所有服务器：

复制代码

统一NTP时间源

然后在业务逻辑层明确：

复制代码

Exam Time Authority

由哪个时间源负责。

二十二、Redis中的Exam Session怎么设计？

大型在线考试中，为了提高性能，经常会将正在考试的Session放入Redis。

例如：

复制代码

exam:session:ES202608090001

内容：

复制代码

{
    "examId": 1001,
    "userId": 20001,
    "startTime": 1786240800000,
    "deadline": 1786244400000,
    "status": "RUNNING",
    "lastHeartbeat": 1786242000000
}

Redis的优势是：

复制代码

读取快

适合高并发

支持TTL

方便维护考试Session状态

但是需要注意：

Redis最好是考试运行态数据，不应成为唯一不可恢复的数据源。

二十三、Redis和数据库如何协调？

一个更加稳妥的设计可以是：

复制代码

数据库

保存：
Exam Session核心数据
StartTime
Deadline
最终状态
SubmitTime

Redis：

复制代码

保存：
运行中的Session缓存
在线状态
Heartbeat
临时答题状态
快速超时判断

总体可以理解为：

复制代码

Database
=
System of Record

Redis
=
Runtime State / Cache

如果Redis发生：

复制代码

重启

故障

Key丢失

系统仍然可以根据数据库中的：

复制代码

StartTime
Deadline
Status

重新构建Exam Session。

二十四、为什么不能只依赖Redis TTL作为考试结束时间？

例如设置：

复制代码

Session TTL = 3600秒

看起来60分钟后Key自动消失，似乎就代表考试结束。

但这种设计不够可靠。

因为Redis Key消失以后：

你可能不知道：

复制代码

是正常过期？

被管理员删除？

Redis发生淘汰？

缓存重建失败？

而且TTL本身不应该代替业务Deadline。

正确逻辑仍然应该是：

复制代码

deadline = 11:00:00

Redis TTL只是辅助：

复制代码

帮助清理Session

而不是：

复制代码

考试唯一计时依据

二十五、宏远培训考试系统中的考试时间链路应该怎样理解？

以宏远培训考试系统这类企业级培训考试平台的应用场景为例，正式考试不仅需要显示一个倒计时，还需要把时间与：

复制代码

考试场次

考生身份

实际试卷

答题记录

断点续考

自动保存

最终交卷

操作日志

关联起来。

一个相对完整的流程可以理解为：

复制代码

员工进入宏远培训考试系统

↓

验证考试资格

↓

创建 / 恢复 Exam Session

↓

服务器确定 StartTime

↓

服务器计算 Deadline

↓

返回 ServerTime + Deadline

↓

前端显示倒计时

↓

答题过程自动保存

↓

周期Server Time校准

↓

断网后保留当前状态

↓

恢复网络重新读取Session

↓

按照原Deadline继续考试

↓

到点后服务器进行最终状态判断

↓

自动交卷 / 生成成绩

↓

考试日志留痕

这样设计以后：

刷新页面不会重新获得考试时间；

修改电脑时间不会改变Deadline；

断网重新连接不会创建新的考试Session；

多次进入同一场考试仍然按照原来的StartTime继续；

最终是否超时由服务器统一判断。

对于正式集团统考、岗位知识考试以及安全培训考试来说，这种时间控制明显比单纯的浏览器倒计时更加可靠。

二十六、考试到点到底应该由前端还是服务器自动交卷？

这是整套设计中最关键的问题之一。

答案应该是：

前端触发交卷，服务器兜底交卷。

也就是说：

不能只依靠前端；

也不应该完全不让前端处理。

二十七、为什么前端仍然需要自动交卷？

当倒计时变成：

复制代码

00:00

前端应该立即：

复制代码

停止继续编辑

↓

保存最后答案

↓

调用Submit API

↓

提示考试时间结束

这是为了：

良好的用户体验。

否则页面显示：

复制代码

00:00

但用户还能继续点击选项，会很奇怪。

所以前端需要：

复制代码

if (remaining <= 0) {
    lockExamUI();
    submitExam();
}

二十八、为什么不能只靠前端交卷？

因为前端可能：

复制代码

断网

浏览器崩溃

电脑关机

JavaScript报错

页面被冻结

用户关闭浏览器

如果系统只等：

复制代码

submitExam()

接口调用，那么这个考生可能永远处于：

复制代码

RUNNING

状态。

因此服务端必须存在：

复制代码

Timeout Finalizer

或者定时扫描机制。

例如：

复制代码

ServerNow > Deadline
AND
Status = RUNNING

则执行：

复制代码

AUTO_SUBMIT

二十九、推荐"双保险"自动交卷设计

完整链路可以设计成：

复制代码

前端倒计时到0

↓

立即锁定答题UI

↓

发送最终答案

↓

调用Submit API

同时服务端独立执行：

复制代码

Deadline到达

↓

扫描RUNNING Session

↓

自动关闭考试

↓

确认最后成功保存答案

↓

生成最终提交版本

↓

计算成绩

这样即使：

复制代码

前端Submit失败

服务器仍然能够：

复制代码

完成考试关闭。

三十、最后一秒提交，服务器到底算不算？

这是考试系统非常容易产生争议的地方。

例如：

复制代码

Deadline：
11:00:00.000

考生：

复制代码

10:59:59.800

点击答案。

但由于网络延迟，服务器：

复制代码

11:00:00.200

才收到请求。

到底算不算？

这需要提前定义规则。

不能考试结束以后临时决定。

一种较严格方案：

复制代码

服务器收到请求时间 <= Deadline

才有效。

另一种方案可以设计：

复制代码

Deadline + GraceWindow

例如允许：

复制代码

500ms

或者：

复制代码

1秒

的网络缓冲。

但需要注意：

Grace Window不是：

额外答题时间。

它只能用于处理：

已经在边界时刻发出的网络请求。

三十一、答案保存时间和前端点击时间不要混为一谈

如果前端发送：

复制代码

{
    "answer": "B",
    "clientTime": "10:59:59.700"
}

服务器不能简单相信：

复制代码

clientTime

因为客户端时间可以伪造。

真正有价值的是：

复制代码

ServerReceiveTime

AnswerVersion

SaveVersion

例如：

复制代码

AnswerVersion：35

ServerReceiveTime：
10:59:59.950

系统可以判断：

复制代码

该版本在Deadline前成功到达服务器

那么就应该作为最终有效答案之一。

三十二、到点自动交卷前应该先Flush答案

如果系统采用：

复制代码

前端缓存

Redis暂存

批量落库

那么自动交卷不能只是：

复制代码

status = SUBMITTED

还应该确认：

复制代码

最新Answer Version

已经进入最终成绩计算链路。

例如：

复制代码

Lock Session

↓

停止接受新答案

↓

读取Latest Answer Version

↓

Flush临时答案

↓

生成Final Answer Snapshot

↓

Submit Exam

↓

Calculate Score

这可以避免出现：

考生明明最后一分钟修改了答案，系统成绩却按照几分钟前版本计算。

三十三、考试时间控制还需要日志

管理员最终一定会遇到类似问题：

我还有一分钟，为什么系统突然交卷？

如果系统只保存：

复制代码

最终成绩

很难解释。

建议至少记录：

复制代码

ExamSession创建时间

Server StartTime

Deadline

前端首次进入时间

Heartbeat

DisconnectTime

ReconnectTime

最后Answer SaveTime

Submit RequestTime

Server SubmitTime

AutoSubmitReason

例如：

复制代码

10:00:03
创建Session

10:00:04
首次进入考试

10:25:12
网络断开

10:27:45
恢复连接

10:59:52
最后答案保存成功

11:00:00
Deadline到达

11:00:01
服务器自动交卷

管理员看到这一条时间线以后，就能够比较清楚地解释整个考试过程。

三十四、一个推荐的考试时间状态机

Exam Session可以设计成：

复制代码

CREATED

↓

RUNNING

↓

SUBMITTING

↓

SUBMITTED

异常状态还可能包括：

复制代码

DISCONNECTED

TIMEOUT

FORCE_SUBMITTED

CANCELLED

例如：

复制代码

RUNNING
+
ServerNow > Deadline

触发：

复制代码

TIMEOUT

↓

AUTO_SUBMIT

↓

SUBMITTED

这样考试时间就不只是：

复制代码

一个JavaScript倒计时。

而真正进入：

考试状态机。

三十五、推荐的整体技术架构

完整链路可以概括为：

复制代码

考生进入考试

↓

Load Balancer

↓

Exam API

↓

获取Server Time

↓

创建 / 恢复 Exam Session

↓

计算StartTime

↓

计算Deadline

↓

Database持久化

↓

Redis缓存运行Session

↓

返回ServerTime + Deadline

↓

浏览器performance.now()本地平滑倒计时

↓

定期Heartbeat / Time Sync

↓

答案自动保存

↓

断网

↓

重新连接

↓

恢复Exam Session

↓

重新校准Server Time

↓

继续按照原Deadline考试

↓

Deadline到达

↓

前端Submit + 服务端Timeout Finalizer

↓

Final Answer Snapshot

↓

成绩计算

↓

考试日志

三十六、几个容易踩坑的实现方式

错误一

复制代码

remaining--;

问题：

后台标签页、CPU卡顿、电脑休眠都会导致计时错误。

应该根据：

复制代码

Deadline - EstimatedServerTime

计算。

错误二

复制代码

deadline = Date.now() + 60 * 60 * 1000;

问题：

刷新页面重新获得60分钟。

Deadline应该由服务器创建并持久化。

错误三

复制代码

客户端时间 <= Deadline

问题：

修改系统时间即可影响判断。

最终必须：

复制代码

ServerNow <= Deadline

错误四

只设置Redis：

复制代码

TTL = 3600

问题：

Redis过期不等于完整的考试业务状态。

Deadline仍然需要进入数据库和Exam Session。

错误五

只靠浏览器自动交卷。

问题：

断网、浏览器关闭以后无人提交。

必须增加服务端兜底。

错误六

断线重连重新创建Session。

问题：

考试时间可能被重新计算。

应该优先：

复制代码

Resume Existing Exam Session

三十七、在线考试倒计时真正控制的不是"秒"，而是考试公平性

从用户界面看：

复制代码

59:59

只是一个数字。

但从考试系统后台看，这个数字背后实际上关联的是：

复制代码

什么时候开始？

什么时候结束？

谁定义这个时间？

刷新以后是否变化？

断线以后是否变化？

不同设备是否一致？

不同服务器是否一致？

最后一道题是否有效？

什么时候自动交卷？

这些问题直接关系到：

考试公平性和考试结果是否可信。

因此在线考试系统的时间模块，本质上属于：

考试核心业务规则。

而不是一个简单的前端组件。

三十八、结语

在线考试倒计时到底应该以前端还是服务器为准？

如果只用一句话回答：

显示以前端为主，规则以服务器为准。

更加完整的技术原则应该是：

第一，服务器创建并持久化Exam Session；

第二，StartTime和Deadline由服务器计算；

第三，前端根据Server Time建立可信时间基准；

第四，前端使用相对时间实现平滑倒计时，而不是依赖系统时钟；

第五，周期性与服务器进行时间校准；

第六，页面刷新和断网重连必须恢复原Exam Session；

第七，Redis负责高性能运行态缓存，但数据库保存核心时间数据；

第八，客户端修改系统时间不能改变Deadline；

第九，前端负责到点交互和主动Submit；

第十，服务器必须拥有最终超时判定和自动交卷能力。

最终形成：

Server Time → Exam Session → StartTime → Deadline → 前端倒计时 → 周期校时 → 断线重连 → 服务端最终判定 → 自动交卷 → 日志追溯

的完整技术链路。

对于宏远培训考试系统这类面向企业正式培训与在线考试的系统来说，倒计时设计真正要解决的并不是：

"页面上的秒数能不能跳动。"

而是即使出现：

刷新、断网、休眠、修改系统时间、服务器切换和网络延迟，

考试仍然能够按照统一的时间规则继续运行，并且最终：

时间算得清、答案保得住、交卷判得准、异常查得到。

这才是一套在线考试系统时间控制真正应该达到的目标。