Java Servlet + MySQL声纹识别后台源码详解与部署避坑指南

简介：面向Java Web开发者与声纹识别技术学习者的一套完整后台源码，基于Java Servlet和MySQL实现声纹数据的采集、存储、查询与匹配验证，可支撑安全认证、门禁考勤等身份核验场景；适合具备一定Java基础、想理解Web前后端协作与声纹识别落地流程的读者。项目主要使用Java与HTML开发，通过Servlet接收前端数据并处理声纹特征比对，前端页面负责交互展示。资源共30个文件，以Java源文件、编译后的class类文件及7个JAR依赖包为主，另含HTML页面、Eclipse工程配置与使用说明，整体约3.31MB。目前已有267人学习/下载，代码支持Apache Tomcat部署，通过WebContent静态资源即可快速构建运行。源码层次分明，涵盖Servlet控制器、DAO数据库访问、用户/终端/设备实体Bean及数据库连接等关键模块，阅读后既能掌握Servlet+MySQL的工程组织方式，也能深入理解声纹模板匹配等核心业务，是开发同类安全认证系统时可直接借鉴的参考实现。

1. 基于Java Servlet和MySQL的声纹识别后台：这份源码到底解决了什么问题

提到声纹识别，很多人第一反应是深度学习模型、特征提取算法，但真正接手一个Java Servlet + MySQL的声纹识别后台项目时你会发现，最容易翻车的反而是数据链路：前端传上来的音频或特征值怎么接收、往哪张表存、比对结果怎么返回。这份基于Java Servlet和MySQL的声纹识别后台源码，把这条工程链路完整做了出来：两个Servlet分管业务请求与文件上传，三个Bean对应三类核心实体，一个DbConn管MySQL连接，前端入口在WebContent/index.html。它能解决的是“声纹模板的录入、存储、查询、匹配、结果返回”这一整套后台工程问题，而不是帮你从零训练声纹算法。适合正在做JavaWeb课设、想找一份Servlet结合MySQL的实操案例来复现的人，也适合想快速读懂别人项目里Servlet+DAO+Bean怎么协作的熟手。

2. 请求链路与项目骨架：从index.html到appServlet再到MySQL要走几条路

2.1 先读懂这份源码的目录结构：6个Java文件各管一段

下载后第一件事不是打开IDE，而是先把目录结构过一遍。这份源码是一个典型的Eclipse Dynamic Web Project，.classpath、.project、.settings这些文件都是Eclipse项目描述文件，不用动；src下面才是真正要读的代码，WebContent是Web根目录。我用一张表把它过一遍：

把这张表记在心里再看代码，你会发现它把声纹识别后台拆成了几个正交的模块：Servlet只管解析请求和返回结果，Bean只管属性，DAO只管SQL，DbConn只管连接。这就是JavaWeb项目最常见的分层，也是复现时最好抄的部分。readme.txt里通常有安装说明和开发背景，拿到手先读它。Eclipse的.settings目录里有一些IDE特定配置，如果导入时提示版本不对，删掉.settings和.classpath重新导入即可，不影响源码逻辑。

2.2 appServlet的请求处理链：doPost是入口，DAO是中转

普通业务请求都走appServlet。和你能搜到的servlet demo相比，它的特点是用了action参数做分发，而不是一个功能建一个Servlet。这样用户注册、模板录入、身份验证都从同一个入口进，后面加功能只需要加一个else if分支。核心骨架如下：

// src/web/appServlet.java 核心骨架（示例） @WebServlet("/appServlet") public class appServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 第一行必须设置编码，否则中文参数就是乱码 request.setCharacterEncoding("UTF-8"); response.setContentType("application/json;charset=UTF-8"); // 从请求里取参数，字段名要和 index.html 里的 name 完全一致 String action = request.getParameter("action"); String userId = request.getParameter("userId"); String voiceFeature = request.getParameter("voiceFeature"); String result; if ("enroll".equals(action)) { // 录入：把声纹特征向量更新到用户记录里 result = enroll(userId, voiceFeature); } else if ("verify".equals(action)) { // 验证：取出库里模板，和本次输入做比对 result = verify(userId, voiceFeature); } else { result = "{\"code\":400,\"msg\":\"unknown action\",\"score\":0}"; } response.getWriter().write(result); } }

这段逻辑说清楚了几件事。setCharacterEncoding必须在getParameter之前调用，这是JavaWeb中文乱码的第一条铁律；Servlet容器默认按ISO-8859-1解码，不等你声明UTF-8它就读成乱码。action参数是后端自己约定的协议，取值enroll和verify分别对应模板录入与身份验证，前端用隐藏域或fetch body里带上。userId是主键，voiceFeature是声纹特征值，常见格式是逗号分隔的浮点数组，比如“0.12,0.78,0.33”，一个128维特征向量转成文本也就几百字节，放在URL编码或请求体里毫无压力。

Servlet的映射方式有两种，要么用上面的@WebServlet注解，要么在web.xml里写servlet-mapping。这份源码走的是注解路线，复现时注意Tomcat版本不能太老，Tomcat 7以上才默认支持Servlet 3.0注解扫描；如果你在web.xml里也配了相同路径，启动会直接报冲突，这是后面避坑章会细说的点。

2.3 把项目跑起来：Eclipse导入与Tomcat部署的最小步骤

用Eclipse导入最省事，因为项目自带.project文件。操作路径是File → Import → Existing Projects into Workspace，选中源码目录，如果工程没被识别，检查.project文件是否在根目录、.classpath引用的JDK版本是否和本机一致。然后准备运行环境：

1. Eclipse里配好JDK：Window → Preferences → Java → Installed JREs，指向本机JDK安装目录。
2. 配Tomcat：Window → Preferences → Server → Runtime Environments → Add，选和你源码匹配的Tomcat版本。
3. 项目右键Run As → Run on Server，浏览器访问 http://localhost:8080/项目名/index.html。

如果是命令行环境，标准做法是把WebContent内容打成war包扔进Tomcat的webapps目录：

# 先编译src下的java文件到classes，再打war mkdir -p build/classes javac -encoding UTF-8 -cp "WebContent/WEB-INF/lib/*" -d build/classes \ $(find src -name "*.java") # 把编译产物和WebContent资源一起打成war jar -cvf voiceApp.war -C WebContent . -C build/classes . cp voiceApp.war $TOMCAT_HOME/webapps/ # 启动Tomcat并盯着catalina.out $TOMCAT_HOME/bin/startup.sh tail -f $TOMCAT_HOME/logs/catalina.out

javac那行的-cp参数把lib下所有JAR加入编译类路径，-encoding UTF-8防止源码里的中文注释和字符串被错误编码。打war的关键是结构必须是WEB-INF/classes放class文件、WEB-INF/lib放JAR包、web.xml或注解定义Servlet，Tomcat启动时会自动解压war。$TOMCAT_HOME要替换成你自己Tomcat的实际路径，比如/usr/local/tomcat。启动后看不到异常、catalina.out里出现“Deployment of web application ... has finished”就说明部署成功。

Eclipse和命令行是两条等价路径，二选一即可。我更推荐在真正部署前用命令行打一次war，因为它能逼你确认编译产物、依赖JAR、WebContent三层结构都齐了，Eclipse经常在背后帮你做了这些事，导致你换环境就露馅。

3. MySQL表结构与数据访问：三个Bean反推三张表，声纹模板怎么存

3.1 从userBean、terminalBean、deviceBean反推库表结构

很多JavaWeb项目源码拿到手，第一反应是找SQL文件，但这份源码没附建表脚本，表结构要从Bean反推。Bean的属性就是表的列，Bean的个数就是表的张数。先别急着写代码，把三个Bean的字段抄一遍，再按下面的SQL建表，后面调DAO才能对得上。

从业务场景看，userBean对应声纹用户，terminalBean对应采集终端，deviceBean对应物理设备。也就是说，系统要管理的不是“一张用户表”这么简单，而是“用户-终端-设备”三层关系：一个用户可能登记了多个终端，每个终端下又有设备实例。项目里这三个Bean的属性字段，就是下面三张表的列名来源，拿到源码先对着Bean的getter把表建出来。

-- 建库统一用utf8mb4，比utf8更省心 CREATE DATABASE IF NOT EXISTS voice_auth DEFAULT CHARACTER SET utf8mb4; CREATE TABLE sys_user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, voice_template TEXT COMMENT '声纹特征值，逗号分隔的浮点向量', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB; CREATE TABLE terminal ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, terminal_code VARCHAR(64) NOT NULL UNIQUE COMMENT '终端编号', user_id INT UNSIGNED NOT NULL, model VARCHAR(32) COMMENT '设备型号', CONSTRAINT fk_terminal_user FOREIGN KEY (user_id) REFERENCES sys_user(id) ) ENGINE=InnoDB; CREATE TABLE device ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, device_sn VARCHAR(64) NOT NULL UNIQUE COMMENT '设备序列号', terminal_id INT UNSIGNED, status TINYINT DEFAULT 0 COMMENT '0下线 1在线', last_active_time DATETIME, CONSTRAINT fk_device_terminal FOREIGN KEY (terminal_id) REFERENCES terminal(id) ) ENGINE=InnoDB;

几个参数值得展开。字符集选utf8mb4而不是utf8，是因为特征向量文本里可能出现特殊分隔符和生僻字符，utf8mb4是MySQL里最完整的UTF-8实现，能避免“字符集不支持某某字符”这种后期玄学问题。voice_template用TEXT类型存文本特征，而不是BLOB，原因有三：一是特征向量本质是一串float转成的文本，TEXT可读、可调试、能在客户端直接SELECT出来核对；二是BLOB在多个驱动、多个字符集之间搬运容易出编码问题；三是TEXT足够大，65KB上限存几千维的特征向量都绰绰有余。分表后外键约束要命名规范，fk_terminal_user一眼能看出是terminal表关联sys_user表，删改时不会搞错。

这份源码没有用Mybatis，就是原生JDBC加手写SQL。所以Bean属性是驼峰命名，数据库列名是下划线命名，写DAO时手动做映射。如果你之前只写过Mybatis自动映射，这里会多一道手工转换，但这恰恰是理解SQL的好机会。

3.2 DbConn连接MySQL：DriverManager够用，参数一个不能省

DbConn是全项目唯一和数据库打交道的入口，也是最容易翻车的地方。源码里的连接写法基本是DriverManager直连，小项目和课设场景完全够用，下面是常规实现：

// src/db/DbConn.java（惯例实现） package db; import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; public class DbConn { // MySQL 8.x 驱动类名；如果是 MySQL 5.x，改为 com.mysql.jdbc.Driver private static final String DRIVER = "com.mysql.cj.jdbc.Driver"; private static final String URL = "jdbc:mysql://localhost:3306/voice_auth" + "?useUnicode=true&characterEncoding=UTF-8" + "&useSSL=false&serverTimezone=Asia/Shanghai" + "&allowPublicKeyRetrieval=true"; public static Connection getConnection() throws SQLException { try { Class.forName(DRIVER); } catch (ClassNotFoundException e) { throw new SQLException("MySQL驱动类未找到，检查WEB-INF/lib下是否有对应JAR包", e); } return DriverManager.getConnection(URL, "root", "改成你的密码"); } }

URL上的四个参数缺一不可。useUnicode和characterEncoding保证中文字符按UTF-8进出数据库；useSSL=false关掉开发环境的SSL告警，生产环境再按需开启；serverTimezone=Asia/Shanghai解决MySQL 8.x驱动报的“server time zone value unrecognized”错误；allowPublicKeyRetrieval=true解决MySQL 8默认caching_sha2_password认证方式下“Public Key Retrieval is not allowed”的报错。很多人照着《mysql安装配置教程》装完MySQL 8，第一道坎就是这里——驱动类名变了、认证方式变了、时区也变了，少了任何一个参数demo就跑不通。

这里提一个替换方案：如果数据量上来，DriverManager每次getConnection都新建连接，性能扛不住。常见做法是换成HikariCP或Druid连接池，改动只发生在getConnection内部，外围DAO调用不用动。但这份源码既然用了直连，复现时先按直连跑通，跑通之后再谈优化。

3.3 DAO层的数据访问：PreparedStatement是底线，匹配逻辑留在Servlet

DAO层的职责边界要清楚：它只做存取，不做声纹算法。存的时候把特征文本写入voice_template，查的时候把模板取出来，剩下的比对计算放到Servlet或Service层。一个典型DAO长这样：

// src/dao/UserDao.java（示例） package dao; import db.DbConn; import java.sql.*; public class UserDao { // 录入：把声纹特征向量保存到用户记录 public boolean saveVoiceTemplate(int userId, String voiceFeature) throws SQLException { String sql = "UPDATE sys_user SET voice_template = ? WHERE id = ?"; try (Connection conn = DbConn.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, voiceFeature); ps.setInt(2, userId); return ps.executeUpdate() > 0; } } // 验证：取出库里模板，返回给Servlet做比对 public String getVoiceTemplate(int userId) throws SQLException { String sql = "SELECT voice_template FROM sys_user WHERE id = ?"; try (Connection conn = DbConn.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { return rs.next() ? rs.getString("voice_template") : null; } } }

两个写法要养成肌肉记忆。第一，SQL一律用PreparedStatement占位符，绝对不要用字符串拼接把userId拼进SQL，否则SQL注入这道坎早晚要踩；占位符从1开始编号，setInt(2, userId)对应SQL里第二个问号，写错位置会查错数据。第二，try-with-resources自动关闭连接、语句、结果集，顺序从里到外，避免连接泄漏。手动close的老写法里最典型的问题是异常时忘记关闭连接，导致MySQL连接数被吃光。

匹配算法为什么不放在DAO里？因为DAO一换数据库实现，算法也跟着重写，耦合太死。常见做法是DAO只把模板String取回来，在Servlet里解析成double数组，再交给一个可替换的比对方法。下面是约定方式：

// Servlet或Service里做比对，算法可替换 double[] enrolled = parseFeature(dbTemplate); // 库里的模板 double[] input = parseFeature(voiceFeature); // 本次输入 double score = cosineSimilarity(enrolled, input); // 余弦相似度 boolean pass = score >= 0.85; // 阈值由业务定 return "{\"code\":200,\"score\":" + score + ",\"pass\":" + pass + "}";

这样设计的好处是，以后想把余弦相似度换成模型推理，只改Servlet里这一处，表和DAO都不用动。特征向量的维度、阈值0.85都是业务参数，复现时可以按自己的场景调。

4. fileServlet与前端交互：声纹特征以什么格式传，上传链路怎么闭合

4.1 fileServlet为什么单独拆一个：文件上传和普通表单请求不是一回事

appServlet用getParameter就能拿到voiceFeature，是因为普通表单请求的body是urlencoded格式。但声纹采集经常要传录音文件，比如.wav、.pcm，这种数据量大、二进制或不定长文本，必须走multipart/form-data格式，这就是fileServlet存在的理由。它接收的是<input type="file">提交上来的Part对象，而不是普通参数。源码的lib目录下有一组JAR包，如果包含commons-fileupload和commons-io，说明走的是FileUpload旧API；如果Servlet版本在3.0以上，直接用@MultipartConfig更省事。下面是新式写法：

// src/web/fileServlet.java（示例） @WebServlet("/fileServlet") @MultipartConfig(maxFileSize = 10 * 1024 * 1024, // 单文件最大10MB maxRequestSize = 20 * 1024 * 1024) // 请求最大20MB public class fileServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding("UTF-8"); resp.setContentType("application/json;charset=UTF-8"); // 前端表单里 <input type="file" name="voiceFile"> Part filePart = req.getPart("voiceFile"); String userId = req.getParameter("userId"); String fileName = filePart.getSubmittedFileName(); // 写到服务器磁盘，目录用真实路径，避免相对路径踩坑 String uploadDir = getServletContext().getRealPath("/uploads"); File dir = new File(uploadDir); if (!dir.exists()) { dir.mkdirs(); } filePart.write(uploadDir + File.separator + fileName); // 把文件内容当作特征文本读出来，交给DAO入库 String featureText = new String(filePart.getInputStream().readAllBytes(), "UTF-8"); boolean ok = new UserDao().saveVoiceTemplate(Integer.parseInt(userId), featureText); resp.getWriter().write(ok ? "{\"code\":200,\"msg\":\"upload ok\"}" : "{\"code\":500,\"msg\":\"upload failed\"}"); } }

@MultipartConfig三个参数一次说清：maxFileSize限制单个文件最大10MB，超了直接抛异常；maxRequestSize限制整个请求体最大20MB，防止恶意大包拖垮Tomcat的接收线程；第三个参数fileSizeThreshold是文件超过多少字节直接落盘而不是进内存，默认值够用，没写也不影响。filePart.write里的路径必须是服务器真实路径，getServletContext().getRealPath("/uploads")会返回Tomcat部署目录下的绝对路径，Windows和Linux都能跑；路径拼接用File.separator而不是硬编码斜杠，否则Windows上会出现“路径找不到”的翻车。文件读出后按UTF-8转成字符串，才能真正和DAO的TEXT字段对接。

如果你在lib下看到commons-fileupload，说明源码走的是DiskFileItemFactory那套旧API，代码会在doPost里先判断是不是multipart请求，再遍历FileItem列表。两种写法的前端完全一致，后端差异只取决于Servlet版本依赖。复现时先看lib里有没有commons-fileupload再选写法，这条判断能帮你少走弯路。

4.2 index.html前端的数据提交：form表单字段和后端参数名必须对齐

前端index.html承担两个职责：录入学声纹时用隐藏域提交特征值，上传文件时用multipart表单提交录音。后端Servlet拿的每个参数，前端都必须有对应name，错一个字母就取到null，这是新手最常见的翻车点。下面两个表单按源码的交互场景给出：

<!-- 业务请求：录入声纹模板 --> <form action="appServlet" method="post"> <input type="hidden" name="action" value="enroll"> <input type="text" name="userId" value="1"> <input type="hidden" name="voiceFeature" value="0.12,0.78,0.33,..."> <button type="submit">录入声纹模板</button> </form> <!-- 文件请求：上传录音文件 --> <form action="fileServlet" method="post" enctype="multipart/form-data"> <input type="text" name="userId" value="1"> <input type="file" name="voiceFile" accept=".wav,.pcm"> <button type="submit">上传声纹文件</button> </form>

action用隐藏域传值，是为了让普通表单也能走同一个Servlet的不同分支。voiceFeature在真实项目里不会手写，而是由采集端的麦克风采集特征模块生成的字符串自动填充。file表单必须写enctype="multipart/form-data"，不写浏览器就用默认的urlencoded编码，后端getPart直接抛IOException。accept属性只是浏览器提示过滤，并不强制，后端还是要靠扩展名校验来兜底。

如果想在前端用JavaScript发异步验证请求，fetch的写法是：

fetch('appServlet', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8' }, body: 'action=verify&userId=1&voiceFeature=0.11,0.79,0.31' }) .then(r => r.json()) .then(data => { if (data.code === 200) { console.log('验证通过，得分：' + data.score); } else { console.log('验证失败：' + data.msg); } });

注意Content-Type和body的编码格式保持一致。如果把action、userId、voiceFeature三个参数用&拼接，就必须用urlencoded；如果要用JSON格式传，后端得改成从request.getInputStream()读JSON解析。这份源码约定的是getParameter方式，前端千万别图方便传JSON，否则后端永远取不到参数。

4.3 一次完整声纹验证请求的数据流与返回格式

前面几节串起来看，一次完整的声纹验证请求是这么走的：

1. 用户在index.html点击验证按钮，前端采集声音，提取特征向量，文本化后POST到appServlet。
2. appServlet解析action为verify，取出userId和voiceFeature，先经过request.setCharacterEncoding("UTF-8")解码。
3. appServlet调UserDao.getVoiceTemplate(userId)，DAO用PreparedStatement从sys_user表取出voice_template。
4. DAO把模板字符串返回给Servlet，Servlet解析成double数组，与本次voiceFeature算相似度，得出score和pass。
5. Servlet拼JSON字符串，response按application/json;charset=UTF-8写回前端。
6. fetch拿到响应，按code字段判断业务是否成功。

这个链路看起来简单，但每一步的字段名都要对齐。返回的JSON建议按下面这张表统一字段，前后端各写各的就不会吵架：

声纹模板文件上传链路则是另一条：fileServlet接收文件，按userId找到对应用户，把文件内容作为特征文本写入voice_template。两条链路共用同一张表、同一个DAO，只是入口不同，这也是为什么这个后台要拆两个Servlet。复现时先别碰文件上传，用curl把appServlet这条轻量链路走通，确认表和DAO没问题，再去调文件上传，排查起来能省很多时间。

5. 避坑实战：Tomcat部署、MySQL连接与Servlet映射的五类翻车现场

5.1 五类典型翻车现场：现象、原因、解决

第一类：部署后访问404，Tomcat日志里报ClassNotFoundException。现象是启动没报错，但浏览器访问 http://localhost:8080/voiceApp/appServlet 返回404，或页面能出但点击就500。原因是少数JAR包没进WEB-INF/lib，或者src下的类没编译到WEB-INF/classes。解决：确认lib目录下JAR包齐全，确认build/classes下class文件和src包路径一致；再用jar -tf voiceApp.war看一眼war内部结构，WEB-INF/classes/web/下必须有appServlet.class。

第二类：连接MySQL报“Public Key Retrieval is not allowed”。现象是数据库账号密码都对，但getConnection直接抛异常。原因是MySQL 8.x默认认证插件是caching_sha2_password，驱动首次连接要拿服务端公钥，但URL没允许。解决：URL加allowPublicKeyRetrieval=true&useSSL=false；或者登录MySQL把用户改成mysql_native_password认证插件。这个坑几乎每个装完MySQL 8的人都要踩一遍，建议直接在DbConn里把参数写全。

第三类：前端传“张三”，数据库里查出来是乱码。现象是页面表单提交中文用户名，存库后SELECT出来全是问号或“å¼ ä¸”这样的乱码。原因是request.setCharacterEncoding("UTF-8")放在了getParameter之后（无效），或Tomcat的URIEncoding没配，或连接串少了characterEncoding=UTF-8。解决：setCharacterEncoding必须放在doPost第一行；GET请求的中文参数要在Tomcat的conf/server.xml里给Connector加URIEncoding="UTF-8"；连接URL也加上characterEncoding=UTF-8。三处都对齐，中文问题才彻底消失。

第四类：Tomcat启动报“The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized”。现象是MySQL 8驱动启动时直接拒绝连接，错误信息里一串乱码时间值。原因是MySQL服务端时区未设置，驱动拿不到合法时区。解决：URL加serverTimezone=Asia/Shanghai，或者在MySQL里执行set global time_zone='+08:00'。两招选一个就行，两个都做也不冲突。

第五类：fileServlet上传报文件目录不存在或路径分隔符错误。现象是本地Windows能跑，部署到Linux服务器后filePart.write抛FileNotFoundException，或者目录被创建成了带反斜杠名字的怪目录。原因是getRealPath返回的目录在Linux上不存在，且代码用了硬编码的“\”或“/”。解决：write之前先dir.mkdirs()创建目录；拼接路径用File.separator；检查webapps目录对Tomcat用户有写权限。

5.2 部署前的自检清单：照着走一遍能省半天

每次拿到一份Servlet+MySQL源码，我都会强制走一遍下面的清单，顺序不能乱：

1. 数据库就绪：执行建库建表SQL，用mysql客户端手工SELECT一张表，确认库名、表名、列名和DAO里SQL完全一致，账号密码和DbConn一致。
2. 依赖就绪：WEB-INF/lib下有MySQL驱动JAR；servlet-api这类Tomcat自带的JAR不要放进lib，否则会和Tomcat自带版本冲突，报NoSuchMethodError或LinkageError。
3. 映射对齐：把@WebServlet注解里的urlPatterns抄出来，和index.html里form的action、fetch的URL逐一比对。少一个斜杠都是404。
4. 窗口和端口：确认8080没被占用，Linux下用netstat -ano | grep 8080看一眼；防火墙对8080放行。
5. 日志导向：启动后不要只看控制台，直接tail -f $TOMCAT_HOME/logs/catalina.out，搜“Exception”和“Deployment”。部署完成的关键词是“has finished”，不是“Server startup”。

清单走完，用curl模拟一次完整请求验证链路，这一步能把绝大多数遗漏暴露出来：

curl -s -X POST 'http://localhost:8080/voiceApp/appServlet' \ -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' \ --data 'action=enroll&userId=1&voiceFeature=0.12,0.78,0.33' # 期望输出形如：{"code":200,"msg":"success","score":0}

curl的-s是静默模式不输出进度条，-X指定POST，--data按urlencoded格式发送body。浏览器地址栏只能发GET，POST请求用curl或Postman模拟才可靠。注意响应Content-Type必须是application/json;charset=UTF-8，如果看到text/html，说明Servlet没设置响应类型或设置位置错了。

5.3 从一次启动失败到定位：日志、端口、依赖三步排查

如果前面清单走完还是起不来，按三步定位。第一步看端口，Tomcat启动失败最常见原因是8080被别的进程占用，报错信息里一定有“Port busy”或“java.net.BindException”，换端口在conf/server.xml里改Connector的port。第二步看依赖冲突，启动日志里出现“NoClassDefFoundError”或“ClassNotFoundException”时，去WEB-INF/lib排查是否有重复版本的JAR，尤其是MySQL驱动千万别同时放5.x和8.x两个版本。第三步看部署目录，Tomcat的webapps下同名war和同名目录同时存在时，Tomcat会优先按目录运行，旧class文件没及时清理就会产生怪异的500错，把webapps下的旧目录删掉、再清一次work目录缓存，重新解压war。

这三步能覆盖九成启动失败。剩下的个别问题，基本都能通过catalina.out里的异常堆栈找到线索。记住一点：Tomcat的启动日志是黑匣子的钥匙，别只看浏览器，日志比网页诚实得多。

6. 进阶：把Servlet返回体统一成JSON协议，复现时顺手改这三处

6.1 统一JSON返回体，所有Servlet不再手拼字符串

源码里如果用response.getWriter().write()直接拼JSON，字段一多就乱，还容易漏转义。复现时我建议顺手加一个极简的Result工具类，把code、msg、score、pass四个字段封装起来，让appServlet和fileServlet共用。

// 极简JSON响应工具类 public class Result { private int code; private String msg; private double score; private boolean pass; public static Result ok(double score, boolean pass) { Result r = new Result(); r.code = 200; r.msg = "success"; r.score = score; r.pass = pass; return r; } public static Result fail(String msg) { Result r = new Result(); r.code = 500; r.msg = msg; return r; } // 字段少，手写JSON比引库更直观 public String toJson() { return "{\"code\":" + code + ",\"msg\":\"" + msg + ",\"score\":" + score + ",\"pass\":" + pass + "}"; } }

改法很简单：原先Servlet里所有拼JSON的地方，换成Result.ok(score, pass).toJson()或Result.fail("模板不存在").toJson()。这个类不依赖第三方库，字段再多几个也只需要往toJson里加一行，前后端契约永远一目了然。

6.2 异常兜底与请求日志

第二处改造是doPost里的异常处理。原生Servlet如果不在方法内try-catch，业务代码抛出的SQLException会直接变成Tomcat的500错误页，前端拿到的是HTML不是JSON，fetch解析必然失败。习惯是在每个doPost里包一层try-catch，catch块里返回Result.fail(e.getMessage())。然后在方法开头打一条入口日志，把action、userId这些关键参数打印出来，出问题时先在日志里复现请求，再查SQL，比瞎猜快得多。

6.3 参数校验前置

第三处是参数校验。不要等DAO执行到SQL才暴露空指针，doPost一进来就用if把userId为空、voiceFeature为空的请求拦下，直接返回code=400。这样前端和联调的人能明确知道是自己传参有问题，而不是后台逻辑坏了。从那以后，我每次拿到Servlet+MySQL的源码，都强制先做三件事：把Servlet映射列出来、把DbConn参数过一遍、把lib下的JAR版本梳一遍——这三步能挡掉八成翻车。希望帮到你。

本文还有配套的精品资源，点击获取