JAVA在线考试系统源码解析：Applet+Servlet+Btrieve环境搭建与改造

简介JAVA在线考试管理系统源代码是一份面向高校计算机专业学生、Java开发初学者以及毕业设计开发者的完整项目资源。它围绕在线考试核心业务展开涵盖试题库管理、考试安排、考生答题与成绩统计等关键模块帮助读者理解从需求分析到系统实现的完整开发流程同时体会Spring、Hibernate或MyBatis、Servlet与JSP等JavaWeb主流技术的具体应用方式。压缩包共包含125个文件整体大小约1.06MB主要文件类型包括jsp动态页面、java源码、class编译文件、jar依赖库、html静态页面、gif示例动图以及数据库的mdf和ldf文件并附带war工程包和若干配置文件便于部署还原项目全貌。资源按模块组织目录结构较为清晰尤其适合课程设计、综合实训或毕业设计阶段对照参考。目前已有1369人学习下载读者可以获得一套可直接运行和二次开发的在线考试系统原型以及项目所涉及的数据库设计、权限控制、安全防护和前端交互实现思路实践价值较高。1. 拿到这份 JAVA 在线考试管理系统源代码先别急着编译它和你想象的不太一样解压这份 JAVA 在线考试管理系统源代码第一眼会愣一下没有常见的 src/controller、service 包而是 Applet1.class、Applet2.class、Applet3.class 和一批 .btr 结尾的数据库文件外加 service.cnf、bots.cnf 这类配置。别怀疑拿错了包这是一套非常典型的早期 JAVA Web 课程设计——浏览器端用 Applet 做交互后端用 Servlet 处理请求数据落在 Btrieve 嵌入式数据库里。它能完整跑通试题库管理、考生登录、在线答题、成绩统计这一整条链路适合正在找课程设计或毕业设计源码的人也适合想搞懂 Servlet/JSP 底层机制、而不是只会套 Spring Boot 的入门者。复现它的关键是先摸清这套老架构的技术栈边界。2. 先认清这份源码的技术底细从文件清单反推整体架构2.1 从 .btr 后缀识别数据库选型Btrieve 不是 MySQL不能按老套路装库拿到源码第一件事不是打开 IDE而是看文件后缀。这份资源的核心数据文件是 doctodep.btr 和 deptodoc.btr光从命名就能看出这是成对出现的关联表——一个表示「文档到部门」的依赖关系另一个是反查方向。这种成对命名在早期 MIS 系统里很常见如果换成关系型数据库通常会做成一张关联表加两个索引而 Btrieve 的风格是直接按访问方向拆成两个文件谁用谁读省去 JOIN。Btrieve 不是我们熟悉的 MySQL 那种服务端数据库它是 ISAMIndexed Sequential Access Method文件型数据库最早跑在 NetWare 网络上后来演化为 Pervasive PSQL再后来被 Actian 收购现在的名字叫 Actian Zen。它的核心特征是数据文件、索引文件全部合在 .btr 里应用通过 ODBC 或 JDBC 驱动直接读写文件没有独立的数据库守护进程帮你解析 SQL。所以如果你按照「装个 MySQL、导入 .sql 再跑」的常规思路来复现第一步就会卡死。判断一个文件是不是 Btrieve 文件有个土办法用十六进制编辑器打开看文件头前几个字节是二进制内容且文件大小通常正好是 512 字节或 4096 字节的整数倍。更正式的做法是装 Pervasive Control CenterPCC把 .btr 文件拖进去它能列出表名、字段名和索引信息。如果这份资源里没有带 DDF 文件Data Dictionary File由 File.ddf、Field.ddf、Index.ddf 三件套组成PCC 也能做元数据探测只是字段名能不能还原成可读名字就得靠源码里的 SQL 去猜了。我一般会按下面这个工具清单来搭环境工具用途关键说明Pervasive Control Center打开 .btr、读取元数据、检查表结构Pervasive PSQL v11 / v12 自带DDF Builder生成或修复 DDF 三件套没有 DDF 时用创建后才能走 SQL 访问jd-gui反编译 .class 查看原始逻辑确认代码里连接数据库的驱动类和 URL十六进制编辑器快速识别文件头判断 .btr 文件是否损坏这里还要强调一个关键差异Btrieve 的 JDBC 驱动和 MySQL 完全是两回事连接串形如jdbc:pervasive://localhost:1583/数据库名默认端口是 1583。很多人翻遍老项目找不到jdbc:mysql的配置就是因为连接参数写在 service.cnf 里或者直接硬编码进了某个工具类根本不是标准 JDBC 的写法。2.2 Applet 不是前端框架三个 class 的职责划分与反编译验证文件清单里出现三个 Applet class很多人会下意识以为这是前端页面文件。实际上 Applet 是 1995 年到 2010 年左右浏览器端运行 Java 程序的老技术通过applet标签嵌入网页由 JRE 插件执行。它既不是前端框架也不是后端服务而是一个「运行在浏览器里的 Java 程序」。在这类在线考试系统里Applet 最常见的职责是承载考试计时器、题目切换和答案暂存这些有状态交互。三个 Applet 的命名虽然只有编号但从在线考试的业务流程可以推断Applet1 大概率对应登录后主界面Applet2 对应答题界面Applet3 对应成绩查看或交卷确认。这只是推断想要坐实得靠反编译。jd-gui 是免费工具把 class 拖进去就能看到反编译出来的 Java 源码重点看每个 Applet 的init()和actionPerformed()方法里初始化了哪些组件、调用了哪些 Servlet URL。我拿到这类老项目的固定动作是这样的先建一个临时目录把三个 class 和四个 cnf 配置文件全部复制进去然后用 jd-gui 打开 Applet1.class搜索.do、.servlet、URLConnection这类关键字。搜索结果能直接告诉你 Applet 是通过 HTTP 调 Servlet 中转数据还是拿着 JDBC 驱动直连数据库——这两种模型的改造难度差了不止一个量级。如果是 HTTP 中转后面改成 Ajax 很轻松如果是直连数据库就得把驱动和账号密码都放进 Applet 的 codebase安全性和兼容性都很头疼。看完代码你会理解一个事实这套系统的「前端」本质上是 Java Swing 组件渲染在浏览器里而不是 HTML 加 JavaScript。这就意味着现在的 Chrome、Edge 默认都跑不了它除非用 IE 兼容模式或旧版浏览器。这个坑我在第 5 章会展开讲。2.3 配置文件不是摆设service.cnf、bots.cnf、linkinfo.cnf 的解读顺序老项目的配置文件没有统一标准service.cnf、bots.cnf、linkinfo.cnf、botinfs.cnf 这四件套是项目作者自己定义的含义要结合源码去读。但命名有规律可循service.cnf 通常是服务端运行参数比如数据库文件路径、服务器端口、最大连接数、会话超时时间linkinfo.cnf 从名字看是连接信息可能存了数据库用户名和密码bots.cnf 和 botinfs.cnf 在考试系统场景下更像是后台任务或定时服务的配置比如考试自动交卷的轮询间隔。我的建议是严格按照「先看代码怎么读、再看文件内容」这个顺序来。因为 .cnf 没有语法标准作者可能用keyvalue也可能用key:value甚至用空格分隔。直接在源码里搜文件名找到读取代码后解析规则一目了然。常见的读取代码是Properties.load(new FileInputStream(service.cnf))或者BufferedReader逐行 split前者说明是标准 properties 格式后者就得自己看分隔符。这些配置文件在复现时的价值比想象中大数据库路径配错启动直接报错端口冲突服务起不来会话超时设太短考生答到一半被踢下线。我建议按下面这个清单逐项核对配置项常见位置检查要点数据库文件路径service.cnf路径是否含中文、是否存在且可写服务端口service.cnf是否被占用默认 1583 是否被防火墙拦截数据库账号密码linkinfo.cnf与 Btrieve 里实际账号是否一致连接数上限service.cnf过小会导致多人同时考试时连接失败自动交卷间隔bots.cnf / botinfs.cnf计时器任务是否依赖外部调度提示老项目的 cnf 文件里密码通常不加密复现时不要把这个包直接上传到公开服务器免得账号信息泄露。3. 本地复现环境搭建JDK、Tomcat 与 Btrieve 引擎的版本搭配3.1 版本选型为什么是 JDK 8 Tomcat 8.5而不是最新版老项目的编译目标和运行环境往往停留在 Java 6 或 Java 7 时代。直接拿 JDK 17 或 JDK 21 去编译大概率会碰到两类错误一类是sun.misc.BASE64Encoder这种内部 API 被移除另一类是 Applet 相关的安全限制导致类加载失败。我自己吃过的亏是用 JDK 11 编译一个老教务系统报了一堆package sun.misc does not exist最后老老实实装回 JDK 8。JDK 8 是这个项目最稳妥的选择具体版本建议 1.8.0_202这是 Oracle JDK 8 最后一个免费商用更新的版本。Tomcat 选 8.5 系列它支持 Servlet 3.1兼容 JDK 8对老项目的 web.xml 配置也友好。不要用 Tomcat 10那个版本开始把javax.servlet包名换成了jakarta.servlet老代码几乎必挂。环境变量配置是老生常谈但每次都会有人栽跟头。Windows 下的配置命令如下setx JAVA_HOME C:\Program Files\Java\jdk1.8.0_202 setx CATALINA_HOME D:\apache-tomcat-8.5.100 setx Path %Path%;%JAVA_HOME%\bin;%CATALINA_HOME%\bin配置完成后重新打开命令行窗口执行java -version和catalina version验证。注意setx只对之后新开的终端生效如果你在同一个窗口里验证会找不到命令这是最常见的翻车点不是配置错了是窗口没重开。验证通过后再确认 Tomcat 能正常启动。执行catalina.bat run会以控制台模式启动日志直接打到终端方便看报错。看到Server startup in [xxx] milliseconds就说明 Servlet 容器这一层已经通了。3.2 数据库引擎安装 Pervasive PSQL 并挂载 .btr 文件Btrieve 文件不是拷到目录里就能读的必须装对应的数据库引擎。在 Windows 上这通常是指 Pervasive PSQL v11 或 v12这两个版本对 Windows 10 的兼容性还可以。安装时注意勾选「MicroKernel Router」和「ODBC/JDBC 驱动」组件只装主程序会缺 JDBC 驱动后面连不上库。安装完成后重点配置一个东西数据库路径Database Path / Local Database Path。打开 Pervasive Control Center找到 MicroKernel 设置把 .btr 文件所在的目录加进路径列表。这一步决定了引擎能不能发现你的 .btr 文件路径配错会报 Btrieve 错误 2文件不存在或错误 84路径无法访问。挂载完成后用 PCC 打开你的数据库目录双击 deptodoc.btr应该能看到表结构。如果能看到字段列表说明文件本身没损坏数据库引擎已正常识别。如果打开报错检查文件是不是被只读属性锁住或者是不是被另一个进程独占——本地测试时最容易踩的是用 Excel 打开过 .btr 文件导致引擎读不到。把目录权限也检查一遍Btrieve 服务运行账户需要对 .btr 所在目录有读写权限。默认的 SYSTEM 账户一般没问题但如果安装在 NTFS 分区且目录是从其他电脑拷过来的要看安全选项卡里的继承权限是否正常。3.3 部署到 Tomcat 并跑通最小流程登录到进入考试首页数据库引擎就绪后进入部署环节。老项目很少给你打好 WAR 包常见形态是把整个 WebRoot 目录或 web 目录复制到 Tomcat 的 webapps 下面。如果你的资源里带.class文件但没带.java源文件直接部署可用如果带的是源码需要先用 JDK 8 编译出 class再按原目录结构摆放。启动顺序很关键先启动 Btrieve 引擎再启动 Tomcat。因为 Tomcat 里的 Servlet 在初始化阶段就会建立数据库连接池引擎没起来的话连接直接失败。检查 Btrieve 服务是否在运行可以在 Windows 服务管理器里看 Pervasive PSQL 相关服务是否处于「正在运行」状态。# 在项目根目录检查 web.xml 中配置的起始页 find . -name web.xml -exec cat {} \; # 启动 Tomcat控制台模式便于看日志 catalina.bat run启动后访问http://localhost:8080/项目名/页面能正常渲染就完成了 80%。接着用管理员账号登录创建一场模拟考试添加几道题然后切换学生账号去答一遍最后看成绩是否统计出来。这套最小验证流程跑通后项目的复现就宣告成功了。我整理了一个最小验证清单部署完照着过一遍检查项预期结果失败时看哪里Tomcat 启动日志无异常堆栈logs/localhost.log访问首页HTTP 200HTML 可渲染web.xml 的欢迎页配置登录跳转到角色对应界面数据库连接是否正常试题列表能读取到数据PCC 中 .btr 表结构是否完整提交答案成绩能写入数据库写入事务是否存在4. 核心模块拆解登录鉴权、答题会话与成绩统计的实现路径4.1 权限控制角色-会话-菜单的最朴素实现这套系统里涉及管理员、教师、学生三类角色但别指望它用了 Spring Security 或 Shiro。老项目的典型做法是登录时查一张用户表把role字段写进HttpSession然后在每个 Servlet 里if/else判断角色决定返回哪个菜单。代码结构简单直接但也意味着所有需要权限判断的地方都得手写校验。这类项目里最常见的权限判断代码我拆过的几个版本结构基本一致// LoginServlet.java 中的核心逻辑 String username request.getParameter(username); String password Md5Util.encode(request.getParameter(password)); User user userDao.findByUsernameAndPassword(username, password); if (user null) { response.sendRedirect(login.jsp?error1); return; } // 核心把角色写入会话后续所有页面从这里判断权限 HttpSession session request.getSession(); session.setAttribute(currentUser, user); session.setAttribute(role, user.getRole()); // A管理员, T教师, S学生 // 按角色分发到不同首页 String target student.jsp; if (A.equals(user.getRole())) { target admin.jsp; } else if (T.equals(user.getRole())) { target teacher.jsp; } response.sendRedirect(target);这段代码暴露了三个关键信息。第一密码使用了Md5Util做加密虽然 MD5 在现在已经不安全但在老项目里是标配。第二角色字段用单字符枚举A/T/S判断时用equals而不是这是防止字符串对象比较翻车的细节。第三登录成功后直接跳转到对应页面菜单是写死在不同 JSP 里的所以管理员和学生的页面是独立的不是同一个页面里做菜单显隐。从改造角度讲这套权限模型最大的问题是散落式校验只要某个 Servlet 忘了判断role就会存在越权访问。我接手时通常第一步全局搜索getSession把所有校验逻辑列出来看有没有漏网的。你在文档和答辩里如果能主动讲出这个安全边界反而是加分项——说明你真的读懂了这个系统的权限模型。4.2 答题会话Applet 与 Servlet 之间的数据交换机制考试系统最核心的模块在答题环节而这份资源里答题界面大概率就是 Applet2.class。Applet 侧要干的事情有固定的套路初始化时从 Servlet 拉取试卷渲染成题目列表答题过程中把用户选择的答案暂存在内存数据结构里交卷时一次性提交给后端。由于 Applet 是 GUI 组件它的数据交换和普通 Web 表单有本质区别。这个环节最容易出问题的不是功能实现而是数据交换的格式。老项目常见的做法有两种一是用 URLConnection 拼参数调 Servlet二是把答案对象序列化成二进制流传输。前者可以直接在地址栏看到参数便于调试后者传输效率高但排查困难。判断方式是看 Applet 里有没有ObjectOutputStream如果用了那基本上就是 Java 原生序列化。这里给出这种项目里最常见的 Applet 提交答案核心代码// ExamApplet.java - 交卷提交核心逻辑 private void submitExam() { String examId getParameter(examId); // 从 HTML 参数中获取考试编号 StringBuilder answers new StringBuilder(); for (int i 0; i questions.length; i) { String selected questionPanels[i].getSelectedValue(); // 答案按题号拼成 id:answer|id:answer 的格式 answers.append(questions[i].getId()).append(:) .append(selected).append(|); } try { URL url new URL(getCodeBase(), servlet/SubmitExamServlet); URLConnection conn url.openConnection(); conn.setDoOutput(true); // 通过输出流把数据写到 Servlet OutputStreamWriter writer new OutputStreamWriter( conn.getOutputStream(), UTF-8); writer.write(examId examId answers answers.toString()); writer.flush(); // 读取 Servlet 返回的提交结果 BufferedReader reader new BufferedReader(new InputStreamReader( conn.getInputStream(), UTF-8)); String result reader.readLine(); showResultMessage(result); } catch (Exception e) { showErrorMessage(交卷失败请重试 e.getMessage()); } }这段代码里有几个参数值得细看。getParameter(examId)从 HTML 标签里获取考试编号说明页面在加载 Applet 时是通过applet标签的参数传入考试信息的答案格式是题号:选项用竖线分隔这个格式必须和后端SubmitExamServlet的解析规则完全一致否则会出现「交卷成功但成绩为零」的问题setDoOutput(true)表示用 POST 方式提交避免答案过长导致 URL 超限。在整个答题链路里交卷过程是唯一不能中断的环节。老系统在这块几乎没有断点续传机制网络一抖就丢卷。复现时一旦发现交卷失败优先检查 Tomcat 的 localhost 日志里有没有参数解析异常其次检查编码——OutputWriter指定了 UTF-8Servlet 侧如果没用相同编码读中文题目的答案就会乱码。4.3 成绩统计从明细表到统计报表的 SQL 聚合逻辑成绩统计是系统的收尾模块也是课程设计论文里最容易写进「系统实现与分析」章节的部分。老项目的成绩统计通常不是实时计算而是交卷时完成成绩汇总并写库再通过一个查询页面读取学生看自己的成绩教师看全班的平均分和分布管理员看整体通过率。这三层查询涉及的数据表结构在同类系统里高度一致核心表和字段基本可以按下面的方式来理解表名关键字段作用studentstudent_id, sname, class_name学生基础信息examexam_id, exam_name, total_score考试基本信息answer_recordstudent_id, exam_id, score, submit_time考试成绩明细exam_questionexam_id, question_id试卷与题目的关联关系成绩统计的典型 SQL 在同类项目里大概长这样-- 按考试统计最高分、最低分、平均分和参考人数 SELECT e.exam_name, COUNT(r.student_id) AS student_count, MAX(r.score) AS max_score, MIN(r.score) AS min_score, AVG(r.score) AS avg_score FROM exam e LEFT JOIN answer_record r ON e.exam_id r.exam_id GROUP BY e.exam_id, e.exam_name ORDER BY e.exam_id;这段 SQL 的统计口径是以 exam 表为主表左连接成绩表保证即便有缺考记录也能把考试信息列出来。COUNT(r.student_id)统计实际参考人数AVG(r.score)计算平均分。如果直接COUNT(*)会把空成绩的缺考记录也算进去平均分和参考人数就会失真。这个细节在答辩时是很好的提问话术——评审老师问统计逻辑时你答出左连接和 COUNT 字段的选择依据会显得确实下过功夫。业务逻辑层的实现也很有规律用一个ScoreStatService类把上面的 SQL 封装成方法返回ListScoreStatVO再由ScoreStatServlet接收前端请求后转成 JSP 渲染。如果你想做成绩分布直方图就把分数段在 Java 代码里分段聚合而不是用 SQL 的 CASE WHEN——老系统的惯用做法是能用代码算的绝不用复杂 SQL。5. 避坑指南老项目复现的五个典型坑5.1 坑一Tomcat 正常启动但页面上的 Applet 区域一片灰现象HTML 页面渲染正常登录也能成功但页面中本该显示考试界面的位置是一片灰色或者显示红色叉号。原因你用的浏览器不支持 NPAPI 插件。Chrome 从 45 版本开始移除了 NPAPI 支持Edge 和 Firefox 52 也相继跟进Applet 在这些浏览器里根本无法启动。这是老项目复现时遇到频率最高的问题不是代码问题是运行环境问题。解决三个办法按难度递增排列第一在 Win10/11 上使用 IE 模式Edge 浏览器的 Internet Explorer 模式运行页面第二装一个火狐 52 ESR 版本或旧版浏览器专门跑这个项目第三把 Applet 替换成现代前端方案具体改造路径我在第 6 章展开。我一般先装一个旧版浏览器快速验证业务逻辑确认系统本身没问题再做技术改造。5.2 坑二Btrieve 报错 2 或 84数据库文件打不开现象Tomcat 日志里出现Btrieve Error 2或者Error 84系统启动后登录时提示数据库无法访问。原因错误 2 表示指定路径下找不到 .btr 文件错误 84 表示文件路径无法访问或文件被锁定。常见场景是 .btr 文件从压缩包解压到某个深层目录而 Btrieve 引擎配置的数据库路径没有包含这个目录另一种可能是文件正在被另一个进程独占打开。解决打开 Pervasive Control Center在 MicroKernel 配置里把 .btr 所在目录手动加入数据库路径列表然后重启 Pervasive 服务。再确认没有其他程序占用文件这一步在 Windows 上要尤其注意杀毒软件一次实时防护扫描也能导致引擎短暂读取失败。改完配置后到服务管理器里右键重启 Pervasive PSQL 服务。5.3 坑三JDK 版本过高导致编译报错内部 API 调用找不到类现象用 JDK 11 或更高版本编译老项目源码报错信息类似package sun.misc does not exist、cannot find symbol: BASE64Encoder有时还会遇到泛型、自动装箱相关的语法兼容问题。原因老项目用了 JVM 内部 API比如sun.misc.BASE64Encoder做 Base64 编码这些类在 JDK 9 之后被移除了模块化体系。还有一类情况是项目用了旧语法在高版本 JDK 下编译器的严格模式会直接拒绝。解决不要尝试逐行改代码兼容新版 JDK直接装 JDK 8 最省事。我固定使用1.8.0_202版本它保留了所有内部 API同时兼容 Windows 10。如果你确实需要在高版本 JDK 上编译可以尝试添加--add-exports参数但老项目里的内部 API 调用往往不止一处逐个加参数的性价比极低。5.4 坑四登录后中文用户名或试题文本出现乱码现象页面能打开登录也能成功但用户名、选择题题干里凡是中文的地方全是??或者锟斤拷。原因三层字符集不一致。JSP 页面本身的编码、Servlet 里读取请求参数的编码、Btrieve 连接串里声明的编码这三者只要有一层不是 UTF-8中文就会出问题。老项目里最常见的是 JSP 写死了 GB2312而 Tomcat 默认用 UTF-8 解码请求参数。解决按下述顺序统一编码。JSP 头部加上pageEncodingUTF-8和contentTypetext/html; charsetUTF-8Servlet 在读取参数前调用request.setCharacterEncoding(UTF-8)JDBC 连接串追加characterEncodingUTF-8参数。这里有一个优先级要记住request.setCharacterEncoding必须在第一次getParameter之前调用否则无效。5.5 坑五Applet 始能加载但点「开始考试」时提示找不到数据库驱动现象Applet 界面显示出来了点击开始考试按钮后页面弹出异常窗口提示ClassNotFoundException: com.pervasive.jdbc.v2.Driver或者类似信息。原因Applet 运行在浏览器端它想直连 Btrieve 数据库就需要在 Applet 所在的环境中能找到 Pervasive 的 JDBC 驱动 jar 包。服务端 Tomcat 加载到的 jar 和浏览器端 JRE 加载到的 jar 不是同一个类加载器驱动 jar 没放进 JRE 的扩展目录就找不到。解决把 Pervasive JDBC 驱动 jar常见名称类似pvjdbc2.jar复制到本机 JRE 的lib\ext目录下重启浏览器再试。这算是规避方案更彻底的做法是在java.policy文件中授予 Applet 相应权限但配置比较复杂且只在本地有效。这也暴露了 Applet 直连模式的天生缺陷驱动、账号、密码全得暴露到客户端安全问题无解所以才有了第 6 章的改造方向。6. 改造升级把 Applet 直连替换成 Servlet 中转的 JSON 接口6.1 最小改造路径新增 ExamApiServlet 输出 JSON不改数据库、不动 JSP只加一个 Servlet 作为数据出口是投入产出比最高的改造方式。它把 Applet 从「直连数据库」变成「HTTP 调接口」逻辑变干净了也为后续对接现代前端留好了口子。我在两个项目里验证过这个改造量大约半天。// ExamApiServlet.java - 对外输出 JSON 数据 WebServlet(/api/papers.do) public class ExamApiServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 设置响应编码统一 UTF-8 resp.setCharacterEncoding(UTF-8); resp.setContentType(application/json); ListExamPaper papers examService.listAvailablePapers(); // 用 Gson 将对象列表直接转成 JSON 字符串 String json new Gson().toJson(papers); resp.getWriter().write(json); } }这个 Servlet 的妙处在于没有动原有的 service 层和数据库层数据来源还是那套 Btrieve但出口已经从私有协议变成标准 HTTP JSON。前端改造时不再需要 JRE 插件一个带计时器的 HTML 页面就能替代 Applet2.class 的全部职责。6.2 前端替换用原生 JavaScript 调用接口新的前端只需要维护一个有loadPapers()方法的普通页面// exam.html - 现代浏览器直接可用 fetch(/exam/api/papers.do) .then(response response.json()) .then(data { // 渲染试卷列表到下拉框 const select document.getElementById(paperList); data.forEach(paper { const option document.createElement(option); option.value paper.id; option.textContent paper.name paper.duration 分钟; select.appendChild(option); }); }) .catch(error console.error(试卷加载失败, error));这段代码把原本由 Applet 承载的「拉取试卷」职责交给了浏览器的 fetch API不再依赖任何插件。改造完成后你可以在 IE 模式、Chrome、Edge 里统一验证接口返回的数据是否完整再逐步把答题、交卷接口也按同样套路迁移。6.3 验证与习惯改造之后务必用一份包含中文试题、特殊字符选项的卷子做回归测试——重点看 JSON 解析时有没有转义错误。这一套顺手之后你会发现自己对 Servlet 生命周期、请求参数编码和 JSON 库的选型都有了真实体感这比单纯跑通老系统收获更大。从那以后我每次拿到老项目都会强制先走一遍「看文件清单 → 反编译确认 → 查配置文件 → 再决定跑还是改」的流程不再上来就catalina.bat run。这套资源本身的价值也恰恰在于能让你完整走过一遍这个流程。希望帮到你。本文还有配套的精品资源点击获取