简介：面向JavaWeb开发者的体育竞赛管理系统毕业设计项目，完整覆盖运动员报名与成绩查询、管理员用户与参赛审核、裁判员成绩记录与公示等业务场景。系统采用JSP+Servlet经典架构，搭配MySQL 5.7数据库，前端通过JSP、HTML、CSS、JavaScript实现动态交互，后端由Java源码与编译后的class文件共同支撑，并配有SQL建表脚本，可直接导入数据库使用。包体共2662个文件，约29.37MB，以Java、JSP、HTML、CSS、JS、jar、SQL等类型为主，另有大量png/gif图片素材和文档，方便界面设计与开发参考。已有903人学习下载。内容包含完整的前后端代码、数据库脚本和项目文档，既适合毕业设计、课程设计直接参考，也可作为竞赛管理类系统二次开发的基座；目录按功能模块划分，层次清晰，便于快速定位与理解JavaWeb项目的整体结构。
1. 基于JavaWeb体育竞赛管理系统：这个毕设题目为什么值得认真做
体育竞赛管理系统是JavaWeb方向里一个典型的「业务闭环型」毕业设计题目。它不像电商系统那么重，也不像图书管理那么泛，业务逻辑恰好卡在一个合适的复杂度上——有角色区分、有报名状态流转、有赛程编排，还有成绩统计这类带聚合查询的功能。换句话说，它覆盖了JavaWeb最常见的几个场景：用户登录与会话管理、表单提交与数据校验、多表关联查询、事务控制。这些恰好是答辩时评委最爱追问的几类问题，也是找工作面试时被反复考察的底层能力。
我见过不少同学在这个题目上翻车，不是因为功能做不出来，而是把系统做成了「增删改查展示器」——登录、加个运动员、加个赛事、存个成绩，答辩时评委一问「报名时怎么防止重复提交」「成绩排名怎么算的」，当场卡壳。这个题目的核心竞争力不在页面多好看，而在业务约束和数据关系是否经得起追问。这篇文章会从技术选型、数据库设计、核心功能实现到部署验证，把一套完整且能自圆其说的方案讲透，适合正在开题或已经动手做了一半、想往深处补的同学。
2. JavaWeb技术选型与项目骨架：Servlet+JSP还是SSM，IDEA配置怎么做才不翻车
2.1 先选型：Servlet+JSP是毕设场景的最稳答案
「基于JavaWeb」这个措辞，在毕设语境里通常指以Servlet和JSP为核心的经典Java Web技术栈，也就是不用Spring Boot那套全家桶，而是直接用Servlet处理请求、JSP渲染页面、JDBC操作数据库。很多同学纠结要不要直接上Spring Boot，理由是现在公司都在用，写起来也快。但从毕业设计的角度，我的建议是：如果题目明确写了「JavaWeb」，优先用Servlet+JSP完成主体功能。
原因有三层。第一，答辩时评委一定会问「你用的是纯Servlet还是框架？为什么不用框架？」——用Servlet+JSP，你能讲清楚一次请求从浏览器到Servlet再到DAO的完整路径，这是JavaWeb课程的核心考点；如果用Spring Boot，你大概率只能说「框架帮我封装好了」，这在评委眼里等于黑匣子。第二，Servlet+JSP的代码量对体育竞赛管理系统这种规模是可控的，核心业务大概十来个Servlet、十来个JSP页面，自己写完全来得及。第三，往Spring Boot迁移的成本很低，底层的DAO、数据库表设计、业务逻辑全是通用的，后期想升级也有一条清晰的路。
那SSM（Spring+SpringMVC+MyBatis）呢？如果你已经把SSM学得很熟，用它也完全没问题，但注意一个风险：SSM的配置文件非常容易出问题，Spring和MyBatis的版本兼容性、扫描路径、事务管理器配置，任何一个地方出错都是报错半天查不出来。毕设时间有限，把精力花在业务逻辑上比花在框架调试上更值。我一般会建议选Servlet+JSP作为主路线，如果后续想加分，再用Filter实现登录拦截、用连接池管理数据库连接，这些是纯Servlet技术栈里就能完成的事情。
2.2 IDEA运行JavaWeb项目的配置：从JDK到Tomcat Deployment
选定技术栈后，第一步是在IDEA里把一个能跑的JavaWeb项目搭起来。这个环节配置项多，每一步都有踩坑空间，我按自己的操作习惯把流程列出来。
第一步，确认JDK版本。JavaWeb经典技术栈用JDK 1.8最稳妥，Tomcat 8.5对应JDK 1.8没有任何兼容问题。如果你机器上装了JDK 17，新建项目时也要在Project Structure里把Project SDK和Project language level都指到1.8，否则编译出来的class文件Tomcat可能不认。
第二步，创建项目。常见做法是新建一个普通的Java项目，然后手动给它加上Web支持：右键项目选择「Add Framework Support」，勾选Web Application。这时IDEA会自动生成web目录，里面有一个WEB-INF文件夹。注意，WEB-INF下面需要手动创建classes文件夹，用来放编译后的class文件——这一步IDEA不会自动建，漏掉的话Tomcat启动后会报ClassNotFoundException，而且这个报错特别容易让人误以为是代码写错了，实际上是输出目录没配好。
第三步，配置Tomcat。点开Run/Debug Configurations，点加号找到Tomcat Server -> Local。在Server标签页里配置Tomcat安装目录，在Deployment标签页里点加号选Artifact，选中项目名:war exploded。这一步如果选成war而不是war exploded，会导致每次修改代码后需要重新打包才能生效，非常影响开发效率。war exploded的意思是「解压后的war包」，IDEA会直接把编译产物和静态资源映射到Tomcat的运行目录，改完代码按Ctrl+F10重新编译就能生效。
第四步，配置Application context。默认值是/项目名_war_exploded，这会导致访问路径带一长串后缀。我一般会把它改成/，这样本地访问就是http://localhost:8080/直接进首页，也避免了JSP里路径拼接出错的可能。
配置完成后跑一次，Tomcat能起、页面能开，骨架才算立住。
2.3 三层架构与项目目录：包结构一开始就要分清楚
技术选型定了，目录结构也得从一开始就规整。常见的方案是把项目分成三层：控制层（Servlet）、业务层（Service）、数据访问层（DAO），实体类单独放。以下是一个可以直接照着建的包结构。
src/ ├── com.example.contest │ ├── entity/ # 实体类：User, Athlete, Event, Entry, Score │ ├── dao/ # 数据访问类：UserDao, EventDao, EntryDao, ScoreDao │ ├── service/ # 业务逻辑：EntryService, ScoreService │ ├── servlet/ # 控制器：LoginServlet, EntryServlet, ScoreServlet │ ├── filter/ # 过滤器：EncodingFilter, LoginFilter │ ├── util/ # 工具类：DBUtil, ParamUtil │ └── web/ # JSP页面按模块分目录这个结构里有两个容易被忽略的点。第一，entity里的类要和数据库表字段一一对应，属性命名用驼峰，表字段用下划线，在写SQL时手动做映射。这看起来笨，但出问题好排查——BeanUtils这类工具在纯Servlet项目里引入容易出意外，手动写getter/setter不用背锅。第二，util包里的DBUtil负责统一获取数据库连接，不要在每个DAO里重复写Class.forName和DriverManager.getConnection，否则改一个连接参数要动十几个文件。
2.4 数据库连接的写法：DBUtil与连接参数说明
DBUtil看起来简单，但参数配置有一些细节值得讲清楚。以MySQL为例，下面是一个标准的DBUtil实现。
public class DBUtil { private static String url = "jdbc:mysql://localhost:3306/contest_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai"; private static String username = "root"; private static String password = "your_password"; static { try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(url, username, password); } }连接串里四个参数各有用处：useUnicode=true和characterEncoding=utf8是解决中文乱码的关键，它们保证从数据库读出来的字符串按UTF-8解码；useSSL=false用来关掉MySQL 8.x默认开启的SSL警告，不然每次启动都会刷一大段日志；serverTimezone=Asia/Shanghai是因为MySQL 8.x的驱动要求显式指定时区，不写会直接报错。
驱动的选择也值得注意：com.mysql.cj.jdbc.Driver是MySQL 8.x的驱动类名，如果你的MySQL是5.7，驱动类名是com.mysql.jdbc.Driver。不少同学从网上下载老项目，驱动类名没改，在MySQL 8环境下直接ClassNotFound。判断方法很简单——看自己的MySQL版本，8.x用cj，5.7用不带cj的老类名，千万别混。密码不要硬编码在代码里，可以放到src根目录的db.properties里，用Properties类读取，这样改部署环境时不用重新编译代码。
3. 数据库设计先行：从赛事和报名反推表结构，把范式用到恰到好处
3.1 业务模块梳理：这个系统需要哪些数据表
动手建表之前，先把业务模块理清楚。一个体育竞赛管理系统，核心用户是管理员、参赛运动员（或领队）、裁判这几类角色。比赛流程可以分成几个阶段：管理员发布赛事、运动员报名、管理员编排赛程、裁判录入成绩、系统生成排名。沿着这条业务线，至少需要以下表：
- 用户表（user）：存登录账号，角色字段区分管理员、运动员、裁判
- 运动员表（athlete）：存运动员的详细资料，跟用户表关联
- 赛事表（event）：存赛事基本信息，名称、时间、地点、报名截止时间、状态
- 报名表（entry）：存运动员和赛事的报名关系，一条记录表示一个运动员报了某个赛事
- 赛程表（schedule）：存赛事下的比赛场次，对阵双方、比赛时间、场地
- 成绩表（score）：存比赛成绩，关联赛程，包含成绩数值和排名
这六张表是主骨架。公告表（notice）、裁判分配表这类属于外围表，看时间决定加不加。一个容易被忽视的设计是：报名表不只是「谁报了哪个赛事」这么简单，它还承担着状态管理的职能——报名后admin需要审核，审核通过才能参与编排。所以报名表里应该有一个status字段，值域是待审核、通过、驳回，这是业务逻辑的关键约束，也往往是评委关注的点。
3.2 核心建表SQL：字段类型、默认值、外键策略
数据库设计要落到SQL语句上。下面给出四张核心表的建表语句，字段类型和约束都经过实际验证。
CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL COMMENT '登录名', `password` VARCHAR(100) NOT NULL COMMENT '密码，建议存MD5或加盐哈希', `role` TINYINT NOT NULL DEFAULT 1 COMMENT '1运动员 2裁判 3管理员', `real_name` VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', `phone` VARCHAR(20) DEFAULT NULL, `created_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `event` ( `id` INT NOT NULL AUTO_INCREMENT, `event_name` VARCHAR(100) NOT NULL COMMENT '赛事名称', `event_type` VARCHAR(20) NOT NULL COMMENT '项目类型：100米、跳远、篮球等', `start_time` DATETIME NOT NULL COMMENT '赛事开始时间', `end_time` DATETIME DEFAULT NULL, `entry_deadline` DATETIME NOT NULL COMMENT '报名截止时间', `location` VARCHAR(100) DEFAULT NULL COMMENT '比赛地点', `status` TINYINT DEFAULT 1 COMMENT '1报名中 2进行中 3已结束', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `entry` ( `id` INT NOT NULL AUTO_INCREMENT, `event_id` INT NOT NULL COMMENT '赛事ID', `user_id` INT NOT NULL COMMENT '运动员用户ID', `athlete_name` VARCHAR(50) NOT NULL COMMENT '冗余运动员姓名', `status` TINYINT DEFAULT 0 COMMENT '0待审核 1通过 2驳回', `created_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_event_user` (`event_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `score` ( `id` INT NOT NULL AUTO_INCREMENT, `event_id` INT NOT NULL, `schedule_id` INT NOT NULL COMMENT '赛程ID', `athlete_name` VARCHAR(50) NOT NULL, `score_value` VARCHAR(20) NOT NULL COMMENT '成绩，如 12.35秒/5.82米', `ranking` INT DEFAULT NULL COMMENT '名次', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;几个关键设计点值得展开讲。
第一，entry表上加了唯一约束uk_event_user，这是防止同一个运动员重复报同一赛事的最强防线。代码层面再怎么查重都可能有并发漏洞，数据库唯一约束是兜底方案，这条一定不能省。
第二，score_value用了VARCHAR而不是DECIMAL——因为不同比赛项目的成绩表达方式不同，径赛是秒、田赛是米、球类可能是比分，用数值类型反而卡死自己。排名ranking字段单独存，是为了避免每次查询都临时算排名。
第三，所有表的字符集统一用utf8mb4，不要用utf8。utf8在MySQL里是utf8mb3的别名，存不了emoji和一些特殊字符，而utf8mb4是完整的Unicode实现。建表时统一指定，比后期改表容易得多。
3.3 范式与冗余：报名表里为什么「故意」存冗余字段
第三范式要求消除传递依赖，非主键字段必须直接依赖主键。按这个标准，报名表里的athlete_name是冗余的——运动员姓名可以通过user_id关联user表查出来。但我建议在entry表里保留这个字段，理由有两层。
第一是查询性能。报名列表页需要显示运动员姓名，如果每次都要连表查user，SQL会写成SELECT e.*, u.real_name FROM entry e LEFT JOIN user u ON e.user_id = u.id。当报名数据上千条、JSP页面还要分页时，连表查询的消耗能明显感受到。冗余存储后，列表查询只需要查entry一张表。
第二是业务语义。报名表是「业务快照」——运动员报名的瞬间，他的姓名、所属单位就定格了。如果之后管理员在user表里改了运动员的姓名，报名记录里的姓名不该跟着变，否则历史数据会被篡改，成绩单上打印的名字和当年报名表对不上。这是典型的「业务数据不可变原则」，在竞赛场景下是刚需。
冗余的正确姿势是：只冗余「不会频繁变化且有查询需求」的字段，并且要在代码注释里写明冗余的理由。评委问起来，这就是一个有意识的设计决策，而不是不懂范式。
3.4 状态字段与时间字段：几个容易被追问的设计细节
数据库设计答辩环节被追问最多的是状态字段和时间字段。我这里集中说几个设计细节。
状态字段优先用TINYINT类型的数字枚举，而不是VARCHAR存「待审核」「已通过」这类中文。数字存储省空间、比较快、不容易因中英文混输出错，代码里用常量类定义语义：public static final int ENTRY_STATUS_PENDING = 0;。JSP页面上需要显示中文时，用Java代码映射，而不是直接数据库存中文。
时间字段要区分「业务时间」和「记录时间」。业务时间是赛事开始时间、报名截止时间这类由用户输入的，用DATETIME类型；记录时间是created_time、updated_time这类由系统自动生成的，用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP。后者可以省去在代码里手动set当前时间的麻烦。
另外推荐一个习惯：每张表都加上created_time字段，即便当前业务用不上。排查问题的时候，它能帮你确认数据是「测试时插入的」还是「系统自动生成的」，也能在展示时作为列表的排序依据，这个习惯能让你在后期少后悔很多次。
4. 核心功能实现：登录态、赛事报名、成绩统计的完整代码走读
4.1 登录与登录拦截：Session的保存、销毁与Filter过滤链
登录功能是每个JavaWeb系统的门面，代码本身不复杂，但和「登录拦截」配合起来就有讲究了。下面先看登录Servlet的核心逻辑。
@WebServlet("/login") public class LoginServlet extends HttpServlet { private UserDao userDao = new UserDao(); @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String username = request.getParameter("username"); String password = request.getParameter("password"); if (username == null || password == null || username.trim().isEmpty() || password.isEmpty()) { request.setAttribute("error", "用户名和密码不能为空"); request.getRequestDispatcher("/login.jsp").forward(request, response); return; } User user = userDao.findByUsernameAndPassword(username, password); if (user == null) { request.setAttribute("error", "用户名或密码错误"); request.getRequestDispatcher("/login.jsp").forward(request, response); return; } HttpSession session = request.getSession(); session.setAttribute("loginUser", user); session.setMaxInactiveInterval(30 * 60); if ("admin".equals(user.getRole())) { response.sendRedirect(request.getContextPath() + "/admin/dashboard"); } else { response.sendRedirect(request.getContextPath() + "/athlete/eventList"); } } }登录逻辑的要点在三个地方。第一，参数校验放在最前面，用户名密码为空时直接转发回登录页并携带错误信息，不要继续查数据库，这是最基本的防御习惯。第二，密码校验使用findByUsernameAndPassword，但实际项目中应该先按username查出User对象，再比对密码哈希，这样能区分「用户不存在」和「密码错误」，不过涉及密码加密方案，这里先按下不表，后面会专门提。第三，session.setMaxInactiveInterval(30 * 60)设置了30分钟的会话超时时间，这是必要的——不设置的话默认超时时间是20分钟，用户操作稍慢就被踢下线，体验很差。
登录拦截用Filter实现，这是纯Servlet技术栈里最能体现「JavaWeb基本功」的环节。
@WebFilter("/*") public class LoginFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; String uri = req.getRequestURI(); if (uri.endsWith("/login") || uri.endsWith("/login.jsp") || uri.contains("/static/") || uri.equals(req.getContextPath() + "/")) { chain.doFilter(request, response); return; } HttpSession session = req.getSession(false); if (session == null || session.getAttribute("loginUser") == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); } }过滤器的要点是放行规则和会话校验。放行规则里包含了登录接口本身、登录页面和静态资源，这三个都必须放行，否则会形成「登录页需要登录才能访问」的死循环。注意req.getSession(false)里的false——如果没有会话，这个方法返回null而不是创建一个新会话，可以避免恶意请求大量创建无用session导致内存膨胀。这是面试里常被问到的细节，放在过滤器里写正好展示基本功。
4.2 赛事报名：重复提交、截止时间和事务边界
赛事报名是体育竞赛系统里业务约束最多的功能，需要同时处理三个问题：防重复报名、报名截止时间校验、以及事务一致性。看下面的实现。
@WebServlet("/athlete/entry") public class EntryServlet extends HttpServlet { private EntryService entryService = new EntryService(); @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { HttpSession session = request.getSession(); User loginUser = (User) session.getAttribute("loginUser"); int eventId = Integer.parseInt(request.getParameter("eventId")); Event event = new EventDao().findById(eventId); if (event == null) { request.setAttribute("error", "赛事不存在"); request.getRequestDispatcher("/athlete/eventList.jsp").forward(request, response); return; } if (event.getStatus() != 1) { request.setAttribute("error", "当前赛事不在报名时间内"); request.getRequestDispatcher("/athlete/eventList.jsp").forward(request, response); return; } if (new Date().after(event.getEntryDeadline())) { request.setAttribute("error", "报名已截止"); request.getRequestDispatcher("/athlete/eventList.jsp").forward(request, response); return; } boolean success = entryService.addEntry(eventId, loginUser); if (success) { response.sendRedirect(request.getContextPath() + "/athlete/myEntry"); } else { request.setAttribute("error", "报名失败，可能已报名过该赛事"); request.getRequestDispatcher("/athlete/eventList.jsp").forward(request, response); } } }Servlet层做了三项前置校验：赛事存在性、赛事状态是否是报名中、是否过了截止时间。注意校验顺序——先查赛事是否存在，再判断状态，最后判断截止时间，顺序反了会报空指针。
真正的防重和事务控制在Service层。
public boolean addEntry(int eventId, User user) { Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); EntryDao entryDao = new EntryDao(); if (entryDao.findByEventIdAndUserId(conn, eventId, user.getId()) != null) { conn.rollback(); return false; } Entry entry = new Entry(); entry.setEventId(eventId); entry.setUserId(user.getId()); entry.setAthleteName(user.getRealName()); entry.setStatus(0); entryDao.insert(conn, entry); conn.commit(); return true; } catch (SQLException e) { e.printStackTrace(); try { if (conn != null) conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } return false; } finally { try { if (conn != null) conn.setAutoCommit(true); conn.close(); } catch (SQLException e) { e.printStackTrace(); } } }这段代码里最关键的是事务边界控制。先查再插这个操作，在并发下有一个经典的竞态条件：两个请求同时查到「未报名」，然后都执行插入。这时前文的唯一约束uk_event_user就会起作用——第二个插入直接抛SQLException，被catch捕获后回滚，数据不会脏。所以代码层面的防重校验是「提前拦截，提升用户体验」，数据库唯一约束是「最后防线，保证数据绝对正确」。两道关卡各司其职，这是并发安全的正确姿势。
conn.setAutoCommit(false)是开启事务的开关。这个设置是连接级别的，所以finally里一定要把它重置为true后再close，否则连接归还到连接池后，下一个使用者会继承这个「非自动提交」状态，造成莫名其妙的更新丢失。这个问题极难排查，是血泪经验。
4.3 成绩录入与排名统计：聚合SQL与排名算法
成绩录入和排行统计是体育竞赛系统「有含金量」的部分，也是答辩评委最可能追问的功能。录入成绩相对简单，核心是排名统计——需要按赛事分组、按成绩数值排序、生成名次。下面是最常用的排名SQL。
SELECT s.athlete_name, s.score_value, @rank := @rank + 1 AS ranking FROM score s JOIN event e ON s.event_id = e.id JOIN (SELECT @rank := 0) r WHERE s.event_id = ? ORDER BY CASE WHEN e.event_type = '径赛' THEN CAST(s.score_value AS DECIMAL(10,2)) END ASC, CASE WHEN e.event_type = '田赛' THEN CAST(s.score_value AS DECIMAL(10,2)) END DESC;这个SQL用MySQL的用户变量@rank实现了排名计算，避免把数据全部捞到Java内存里再排序。两个CASE语句处理了径赛和田赛的差异——径赛成绩数值越小排名越靠前，田赛成绩数值越大排名越靠前，这个细节非常容易被忽略，但恰恰是评委爱问的点。
更稳妥的替代方案是：查出来后在Service层用Java排序并生成名次。虽然多写几行代码，但逻辑更直白、调试更容易。对于毕设规模的数据量，Java排序的性能完全够用，而且不用关心MySQL版本对用户变量兼容性的问题。
4.4 基于角色的菜单与权限控制：数据权限该怎么做
最后提一下权限控制。前面Filter章节只做了「是否登录」的拦截，但系统里还有三种角色，不能让运动员访问管理员的页面。常见的做法是在Filter里校验角色。
String uri = req.getRequestURI(); User loginUser = (User) session.getAttribute("loginUser"); if (uri.startsWith("/admin/") && !"admin".equals(loginUser.getRole())) { resp.sendError(HttpServletResponse.SC_FORBIDDEN); return; }按URL前缀做粗粒度的角色拦截，放在Filter里统一控制，这个方案简单有效。注意uri.startsWith("/admin/")判断不能少，否则所有以admin开头的内容都不设防。更细粒度的数据权限——比如运动员只能看自己的报名记录——需要在SQL层面加WHERE条件，这属于业务逻辑的范畴，在DAO查询时传入loginUser.getId()即可。
5. 避坑清单：从MySQL 8驱动到中文乱码，五个高频问题的现象、原因与解决
5.1 MySQL 8.x驱动加载失败：ClassNotFoundException与连接报错
做JavaWeb毕设的同学，数据库环境五花八门，MySQL 8.x已经是主流，但很多教程和课件还停留在5.7的写法。最常见的报错是ClassNotFoundException: com.mysql.jdbc.Driver，或者启动后连接数据库报Unable to load authentication plugin 'caching_sha2_password'。
这两个报错本质是同一个原因：MySQL 8.x把默认驱动类改成了com.mysql.cj.jdbc.Driver，同时默认认证插件从mysql_native_password换成了caching_sha2_password。如果你的项目里还在用老的驱动类名，或者驱动jar包版本是5.x，就会踩上。
解决分两步。第一步，去Maven仓库下载mysql-connector-java8.0.x版本的jar包，放到WEB-INF/lib下。第二步，驱动类名改成com.mysql.cj.jdbc.Driver，连接串加上serverTimezone=Asia/Shanghai。顺便验证一下：如果你用的是8.0.30及以上版本，驱动类名多点了一次——com.mysql.cj.jdbc.Driver，别写成com.mysql.jdbc.cj.Driver，这个手误网上到处都是。
5.2 中文乱码：三处编码必须一致，少一处都白搭
中文乱码是JavaWeb项目里出现频率最高的玄学问题，页面显示问号、插入数据库变成??、表单提交回来乱码，原因千奇百怪，但排查路径是固定的——三处编码必须保持一致：JSP页面编码、请求编码、数据库连接编码。
第一处，JSP页面头部写pageEncoding="UTF-8"和contentType="text/html; charset=UTF-8"，缺一不可。第二处，请求编码靠Filter解决，在EncodingFilter里对request和response都设置UTF-8，注意request.setCharacterEncoding("UTF-8")必须放在任何读取参数之前，否则不生效。第三处，数据库连接串里的characterEncoding=utf8，前面DBUtil里已经写过了。这三处都对了，乱码基本绝迹。
还有一个容易被忽略的细节：Tomcat 8.5及以上版本对POST请求默认按UTF-8解码，但对GET请求的query string默认按ISO-8859-1解码。如果你的搜索功能在GET提交中文时乱码，需要改Tomcat的server.xml，在Connector节点加上URIEncoding="UTF-8"。这个和前面Filter解决的是两个不同层面的问题，别混为一谈。
5.3 Tomcat端口占用与IDEA热部署失效
Tomcat启动报错Port 8080 is already in use太常见了。解决方式很直接：要么关掉占用8080的进程，要么给Tomcat换个端口。Windows下用命令行netstat -ano | findstr 8080查PID，然后在任务管理器里结束进程；IDEA里改端口则在Run/Debug Configurations -> Tomcat Server -> HTTP port里改成8081。
另一个更隐蔽的问题是热部署失效——改了Java代码后不重启Tomcat，访问的还是老逻辑。原因是Deployment里选的Artifact是war而不是war exploded，IDEA没法增量更新。解决方法是回Deployment标签页，删掉原来的war，重新添加war exploded。如果已经是war exploded还不生效，检查IDEA的Build -> Build Project是否执行了，开发阶段我习惯用Ctrl+F9手动触发编译，比依赖自动编译靠谱。
5.4 JSP里路径写死的坑：斜杠开头的绝对路径和相对路径
JSP页面里资源引用的路径问题，让不少人调试到怀疑人生。页面能打开，但CSS样式全丢了、图片裂了、跳转链接404。核心原因是：JSP里以/开头的路径，是相对于Web应用根路径的，而你的Application context如果设成了/contest，浏览器会去请求http://localhost:8080/css/style.css，实际资源在http://localhost:8080/contest/css/style.css。
解决分两种。第一，在JSP页面里用${pageContext.request.contextPath}拼接绝对路径，这是最稳妥的写法：<link rel="stylesheet" href="${pageContext.request.contextPath}/css/style.css">。第二，更省事的办法——把Tomcat的Application context设成/，这样根路径和项目路径重叠，所有以/开头的引用都能正常工作。我推荐开发阶段用第二种，省心；理解原理后用第一种，规范。
5.5 连接没关导致的连接耗尽：Connection泄漏是隐形的数据库杀手
最后一个高频坑是连接泄漏。很多同学的DAO代码只写了conn = DBUtil.getConnection()，执行完SQL就什么都不管了。前几十次运行没问题，时间一长突然报Too many connections，重启Tomcat又好一阵，然后再次崩溃。这是典型的连接未关闭导致的泄漏。
JDBC的Connection是底层TCP连接的封装，不close就会一直占着数据库的服务端连接。MySQL默认最大连接数是151，一个连接泄漏几分钟就被耗尽了。解决的唯一办法是在finally块里关闭，前面EntryService的代码里已经演示过了。如果是JDK 7以上，可以用try-with-resources让代码更简洁：
try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { // 处理结果集 }注意try-with-resources的关闭顺序是逆序的——rs先关，ps其次，conn最后，正好符合依赖关系。
6. 部署验证与进阶技巧：war包导出、生产路径检查、参数化SQL与连接池
6.1 导出war包并验证部署：从IDEA到Tomcat的最后一公里
开发阶段用war exploded没问题，但交付时最好导出一个完整的war包，放到独立的Tomcat里验证一遍。这个验证步骤的价值在于：它能暴露出开发环境里被隐藏的问题，比如依赖的jar包没打进去、路径写死、数据库密码硬编码在机器上能跑但换环境就废。
导出war包的操作很简单：IDEA右侧Maven面板（如果你的项目没有Maven，直接用Build -> Build Artifacts -> Build，选择war类型的Artifact）构建产物会在target或out目录下生成war文件。找到一个空闲的Tomcat，把war包丢进webapps目录，启动Tomcat，它会自动解压并部署。然后重点检查三件事：首页能不能打开、登录后跳转路径对不对、CSS和图片是否正常显示。
我自己的习惯是直接把war包丢到一个干净的Tomcat里做一次冒烟测试，把该暴露的问题在交付前全暴露掉。这比答辩前十分钟手忙脚乱改配置要稳妥得多。
6.2 两个必加的进阶点：参数化SQL与连接池
如果你的系统准备拿个良好以上的成绩，下面两个进阶点是性价比最高的投入。
第一个是参数化SQL，也就是用PreparedStatement替代Statement拼接SQL。这既是防SQL注入的安全底线，也是面试和答辩必问点。之前所有代码示例里用的都是PreparedStatement，它的本质是让SQL语句先预编译、再传参，用户输入永远不会被当作SQL代码执行。比如登录查询写成SELECT * FROM user WHERE username = ? AND password = ?，而不是"SELECT * FROM user WHERE username = '" + username + "'"。前者即使用户输入' OR '1'='1也不会破坏SQL结构。建议把系统里所有的Statement都检查一遍，确认没有拼接字符串的写法。
第二个是引入数据库连接池。DriverManager每次getConnection都新建TCP连接，开销大、响应慢，并发一高就卡。常见做法是使用Druid或HikariCP，配置一个数据源，从池里借连接、还连接。改造起来也简单，DBUtil里不再直接用DriverManager，而是从池子里取连接。核心配置如下：
jdbcUrl=jdbc:mysql://localhost:3306/contest_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username=root password=your_password initialSize=5 maxActive=20 maxWait=60000参数说明：initialSize是启动时初始化的连接数，maxActive是最大活动连接数，maxWait是获取连接的超时时间（毫秒），超过这个时间拿不到连接就抛异常。对于毕设的并发量，initialSize=5、maxActive=20足够用了。连接池的意义不只是性能——它还能帮你兜住连接泄漏，因为池会强制回收超时未归还的连接。
讲到连接池，想起自己当年踩过的坑：换连接池后清掉了DBUtil里的Class.forName，启动直接报错。原因是Druid虽然会自动注册驱动，但前提是驱动jar包在classpath里。老代码里的Class.forName保留着也无妨，但要注意和连接池里配置的driverClassName保持一致，别一个写cj一个写不带cj，两个类名指向同一个驱动，但写法不统一容易把自己绕晕。
最后说一个我自己的习惯：核心功能完成后，花一个晚上把「用户注册 -> 管理员审核 -> 运动员报名 -> 赛事编排 -> 成绩录入 -> 排名生成」这条完整链路走一遍，用真实数据、录成视频、截图存档。这个动作有两个作用——一是逼着自己把边界条件全部测到，二是答辩时万一现场出环境问题，手里的演示录像是最后一张保底牌。这套系统做到了数据表有业务约束、代码有三层边界、部署有一键war包，就已经超过大多数同类毕设了。希望这些经验能帮你少走弯路，也祝你的答辩顺利。
本文还有配套的精品资源，点击获取
