1. 学生管理系统的数据模型先钉死别急着写第一行 Servlet我带过几届学生的课程设计也帮人改过不少跑不起来的学生管理系统代码。绝大多数问题不是出在 Servlet 写错了而是出在动手之前压根没想清楚表结构。有人上来就在 IDEA 里建 Web 工程写个StudentServlet字段想到哪加到哪等做到按班级筛选导出成绩单的时候发现表里没有班级 ID只能回头改表、改实体类、改 JSP 里的每一处${student.className}。返工的成本比一开始多花两小时设计表结构要高十倍。学生管理系统这个题目看着简单其实它是一个标准的、麻雀虽小五脏俱全的 CRUD 系统。它要落地的东西包括学生信息的增删改查、班级归属、课程与成绩、登录权限、分页与搜索。这几块任何一块抽象错了后面都要还债。所以这篇我打算按真实的开发顺序来讲先定数据、再搭骨架、然后攻下几个真正的硬骨头最后说部署和排错。提示如果你只是想交个作业把表结构简化成一张学生表 一张用户表也够跑。但只要你的系统里出现了课程成绩这两个词就请老老实实拆成多表不然成绩那一块一定会写成一坨。1.1 为什么表结构必须想在前头一个真实的返工案例我见过最典型的一次返工是这样的学生表里有一个class_name字段存的是计算机 2201 班这种字符串。一开始挺好用列表页直接显示。等要做到按班级统计人数班主任只能看自己班的学生时问题就来了——班级名字符串没法可靠地当关联键改一次班级名几百条学生记录全要跟着改。后来只能补一张class表再写一个脚本把旧数据按名字去匹配回填class_id还得处理名字写得不一致的历史脏数据。这就是典型的用展示字段当业务字段。判断方法很简单这个字段会不会被别人引用会不会被修改会不会用于筛选统计三个问题里有两个答是它就应该独立成表用主键 ID 关联而不是存文本。1.2 五张表的字段级设计我一般会拆成五张表够用且不过度设计。下面这个设计我实际跑过几个项目字段名和类型都比较稳。学生表student字段类型说明idint / bigint 自增主键snovarchar(20) 唯一学号业务唯一键namevarchar(50)姓名gendertinyint1 男 2 女不用汉字存birthdaydate出生日期phonevarchar(20)联系电话class_idint外键指向 class.idstatustinyint1 在读 0 离校create_timedatetime创建时间班级表classid、class_name、grade年级、teacher_id可选指向教师。课程表courseid、course_name、credit学分、teacher_id。成绩表scoreid、student_id、course_id、scoredecimal(5,2)、exam_time。这里一定要用decimal而不是float浮点数算平均分会飘。账号表sys_userid、username、password存哈希不存明文、roleadmin / teacher、ref_id关联教师或学生 ID。关于性别字段我强烈建议存数字。我一开始也图省事直接存男女结果前端排序、图标渲染、表单回显都得做字符串判断而且一旦有人输入男性就全乱。存tinyint在前端或枚举里做映射是更干净的做法。1.3 主键、外键、删除策略别把delete当默认动作主键用自增int还是业务键sno我的答案是自增 ID 做主键学号做唯一索引。学号虽然唯一但它是有可能变的比如学籍异动重新编号把业务键当主键会牵连一堆外键。删除策略上学生记录我基本都做逻辑删除用status或者单独的del_flag字段标记查询时统一带where del_flag 0。原因很实在成绩表里有student_id物理删掉学生之后这些成绩就成了孤儿数据做统计时对不上数。逻辑删除偶尔会带来唯一索引冲突的问题——比如学号逻辑删除后再新增同号学生会失败解决办法是把唯一索引改成(sno, del_flag)的联合唯一或者删除时给学号加个后缀。外键约束要不要建工程实践中争议挺大。建了外键数据库帮你兜底但批量导数据、逻辑删除、分库分表时会很别扭。我的做法是教学项目建外键方便理解关系生产项目一般不建物理外键改由 Service 层校验。这个取舍你得知道自己在做什么而不是别人都这么干。2. 分层骨架怎么搭Servlet 与 Spring Boot 的真实取舍把表定下来之后第二个必须拍板的问题是技术栈。这个问题在网上的答案往往两极分化一边说学 JavaWeb 就必须用原生 Servlet不然你根本不懂原理另一边说现在还写 Servlet 是浪费时间直接 Spring Boot 三件套。这两种说法都太绝对了。我的判断标准很具体看你的目标是什么。如果是为了理解 HTTP 请求怎么从浏览器走到你的方法、Session 怎么工作、JSP 怎么被编译成 Servlet那原生 Servlet JSP 是最直白的教具没有之一。如果是为了交付一个能扩展、能维护的后台系统Spring Boot MyBatis 会让你少写一半的样板代码。这两件事不冲突先做过一遍原生的再上框架你会明白框架替你干了什么。2.1 一次请求在原生 Servlet 里的完整流转路径很多同学写了半年 Servlet其实说不清一个查询学生列表的请求到底经过了哪些环节。我把它拆开浏览器发出GET /student?actionlistpageNum1。Tomcat 的 Connector 接收到请求解析成HttpServletRequest。根据web.xml里的url-pattern或者WebServlet注解匹配到StudentServlet。如果配了 Filter比如编码过滤器、登录过滤器请求先过 Filter 链。进入StudentServlet.doGet()方法里调StudentService。Service 调StudentDaoDao 用 JDBC 执行 SQL拿到ResultSet映射成ListStudent。Servlet 把 List 放进request.setAttribute(list, list)然后request.getRequestDispatcher(/student_list.jsp).forward(...)。JSP 被编译执行用 EL 表达式把数据渲染成 HTML返回给浏览器。这条链路上每一环都可能出问题匹配不到 Servlet 就是 404Filter 拦错了就是死循环重定向SQL 写错了就是 500JSP 路径写错就是资源不可用。搞清楚这条链你排错的时候就知道该往哪一层看。2.2 三层架构里每一层到底该放什么分层这件事最容易犯的错误不是不分层而是分了层却把逻辑全写在 Servlet 里。我见过 Service 层只是空壳转发所有业务判断——比如学号不能重复成绩必须在 0 到 100 之间——全塞在 Servlet 的doPost里。这样分层等于没分。我的分工原则是这样的Dao 层只干一件事跟数据库打交道。一个方法对应一条或一组 SQL入参是基本类型或实体出参是实体或集合。不写业务判断不抛业务异常。Service 层业务规则的所在地。学号唯一性校验、成绩范围校验、跨表操作的事务控制都放在这里。Dao 返回 null 之后该报什么错由 Service 决定。Servlet / Controller 层只做三件事——接参数、调 Service、决定跳哪个页面。不出现一行 SQL也不出现复杂 if-else 业务分支。举个具体例子。录入成绩这个操作在 Service 里应该长这样public void addScore(Score score) { // 业务校验 if (score.getScore() null || score.getScore().compareTo(BigDecimal.ZERO) 0 || score.getScore().compareTo(new BigDecimal(100)) 0) { throw new BizException(成绩必须在 0 到 100 之间); } // 同一学生同一课程不能重复录入 if (scoreDao.exists(score.getStudentId(), score.getCourseId())) { throw new BizException(该学生这门课的成绩已存在); } scoreDao.insert(score); }校验放在这里Servlet 那边只要 try-catch 捕获BizException然后回显错误信息就行了。改规则时只改一个地方这是分层真正的价值。2.3 我在选型上真实纠结过的三个点第一个是JSP 还用不用。JSP 现在确实不是主流了前后端分离是大势。但学生管理系统这种以表格和表单为主的场景JSP JSTL 的开发速度其实非常快c:forEach遍历列表、c:if控制按钮显示比写一堆 fetch 请求和 DOM 操作省事。我的建议是学习阶段用 JSP能让你看清服务端渲染的本质要做成作品集或者有前端同学配合再上分离方案。第二个是JDBC 还是 MyBatis。原生 JDBC 写多了你会崩溃每个查询都要getConnection、prepareStatement、遍历ResultSet、close还有一堆重复的映射代码。MyBatis 能省掉 80% 的样板。但如果完全没写过 JDBC你遇到 MyBatis 报错时会完全不知道它在背后干了什么。所以顺序是先手写一遍 JDBC 的增删改查再换 MyBatis你会对它心存感激。第三个是连接池选哪个。Druid 和 HikariCP 都能用我一般教学项目用 Druid因为它自带监控页面能直观看到连接池状态对理解连接是稀缺资源这件事很有帮助生产环境更倾向 HikariCP配置简单、性能好。这一层用不用连接池差别是巨大的——每来一个请求就新建一个数据库连接几十个并发就能把 MySQL 的连接数打满。3. 增删改查里最容易翻车的三个环节CRUD 听起来是最没技术含量的部分实际上 bug 密度最高的恰恰是这里。我在改别人代码时出问题的位置反复集中在三个地方分页、搜索、表单回显。3.1 分页为什么总数 SQL 与列表 SQL 必须同条件分页的标准做法是两条 SQL一条查当页数据一条查总记录数。坑在于——很多人查列表时带了筛选条件查总数时却把条件漏了。结果就是按班级筛选后列表只有 10 条分页却显示有 20 页。-- 列表带筛选条件 SELECT s.*, c.class_name FROM student s LEFT JOIN class c ON s.class_id c.id WHERE s.del_flag 0 AND s.name LIKE CONCAT(%, #{keyword}, %) AND s.class_id #{classId} ORDER BY s.id DESC LIMIT #{offset}, #{pageSize}; -- 总数条件必须一模一样只是把 SELECT 换成 COUNT SELECT COUNT(*) FROM student s WHERE s.del_flag 0 AND s.name LIKE CONCAT(%, #{keyword}, %) AND s.class_id #{classId};注意第二条 SQL 里我去掉了 JOIN因为总数统计不需要班级名少一次关联能快一点——但WHERE里用到的字段必须都在student表里否则还是得 JOIN 回来。这种优化可以做但前提是你清楚地知道自己在取舍什么。还有一个细节offset的计算。offset (pageNum - 1) * pageSize。如果你的pageNum是从 1 开始的忘了减 1第一页会显示空数据。这个 bug 我至少见过五次。3.2 模糊搜索拼 SQL 与注入防护的边界搜索框是 SQL 注入的重灾区。反面教材是这样写的// 千万别这么写 String sql SELECT * FROM student WHERE name LIKE % keyword %;只要有人在搜索框里输入 OR 11条件就恒真全表数据泄露。正确做法是用PreparedStatement让参数值和 SQL 结构分离String sql SELECT * FROM student WHERE name LIKE ?; ps.setString(1, % keyword %);这里有个小知识点%通配符要拼在参数值里而不是拼在 SQL 字符串里。因为LIKE CONCAT(%, ?, %)这种方式参数仍然是被数据库当作值处理的不会破坏语句结构。搜索条件动态拼接的时候我一般用一个StringBuilder加一个参数列表最后统一 setStringBuilder sql new StringBuilder(SELECT * FROM student WHERE del_flag 0); ListObject params new ArrayList(); if (StringUtils.isNotBlank(keyword)) { sql.append( AND name LIKE ?); params.add(% keyword %); } if (classId ! null) { sql.append( AND class_id ?); params.add(classId); }这样条件加多少参数就按顺序加多少不会错位。3.3 编辑页面的回显一个下拉框能让新手卡一下午新增和编辑通常共用一个表单页。新增的时候各字段是空的编辑的时候要把已有数据填进去。文本框好办value${student.name}就行。真正折磨人的是下拉框的选中状态——班级下拉框要自动选中该学生所属的班级。繁琐但可靠的写法select nameclassId c:forEach items${classList} varc option value${c.id} ${c.id student.classId ? selected : }${c.className}/option /c:forEach /select关键是那个${c.id student.classId ? selected : }。注意c.id在 EL 里是Integer或Long如果student.classId也是同类型比较的是值没问题但如果两边一个是字符串一个是数字EL 会做隐式转换多数情况能对极端情况会失灵。稳妥做法是统一类型或者用${c.id eq student.classId}。另一个高频问题是日期字段的回显。数据库里是date类型直接往input typedate的 value 里塞格式可能不匹配yyyy-MM-dd才对。需要在传输过程中做好格式化别指望浏览器帮你容错。4. 三个绕不开的硬骨头乱码、拦截、连接池这三块是新手最容易卡住、老手最容易忽略的地方。它们都不是什么高深技术但每一个都能让你排查半天。4.1 中文乱码先搞清楚它到底发生在哪一段乱码问题的本质是编码和解码用了不同的字符集。你只要问自己数据在传递的哪一步被转成了字节哪一步又变回了字符两端用的是不是同一套编码POST 请求的乱码处理起来最简单在读取任何参数之前调用一句request.setCharacterEncoding(UTF-8);注意之前两个字一旦调用了getParameterTomcat 已经按默认编码解析过了再设就晚了。所以这句话要放在 Servlet 方法的第一行或者干脆放进一个 Filter 里统一处理。GET 请求的乱码要看 Tomcat 版本。Tomcat 8 之后URIEncoding默认就是 UTF-8GET 一般不会再乱。如果你用的是更老的版本或者被改过配置需要在server.xml的 Connector 上加URIEncodingUTF-8。响应端的乱码也要管response.setContentType(text/html;charsetUTF-8);数据库这一端连接 URL 要带characterEncodingutf8且数据库和表的字符集建议统一用utf8mb4别用utf8——MySQL 的utf8其实只有三个字节存不下一些字符utf8mb4才是真正的 UTF-8。我的经验是乱码问题不要靠猜要靠定位。在 Servlet 里打印一下参数的长度和内容在数据库里直接 SELECT 看看存进去的是什么。如果参数打印出来就是乱码问题在请求端如果参数正常但数据库里乱问题在连接配置如果数据库正常但页面上乱问题在响应头或 JSP 的pageEncoding。4.2 登录拦截Filter 放行清单漏一个就死循环登录校验用 Filter 是最常见也最合适的方式。核心逻辑就一句Session 里没有用户信息就跳登录页。但新手最常踩的坑是——把登录页本身也拦住了。public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request (HttpServletRequest) req; HttpServletResponse response (HttpServletResponse) resp; String uri request.getRequestURI(); // 放行清单 if (uri.contains(login.jsp) || uri.contains(LoginServlet) || uri.contains(/css/) || uri.contains(/js/) || uri.contains(/images/)) { chain.doFilter(req, resp); return; } Object user request.getSession().getAttribute(loginUser); if (user null) { response.sendRedirect(request.getContextPath() /login.jsp); return; } chain.doFilter(req, resp); }这里的坑点有两个。一是静态资源要放行否则登录页的 CSS 加载不出来页面长得像纯文本用户以为没登录成功。二是request.getContextPath()——重定向时一定要带上项目上下文路径不然在 Tomcat 里部署成/sms时重定向会跑到根路径去直接 404。另外Filter 的url-pattern用/*会拦截所有请求包括转发forward。如果 JSP 是 forward 过去的会被再拦一次但用户已经登录了所以能过不至于死循环。真正死循环是登录接口本身被拦——这种问题在浏览器里表现为重定向次数过多看 Network 面板会看到一个接一个的 302。4.3 连接池别等到too many connections才想起来它我见过最典型的一个 bug 是连接泄漏——Dao 里Connection忘了 close或者抛异常时走了另一个分支没关。程序跑一段时间就报Too many connections。用连接池之后泄漏会更隐蔽因为池子里连接用完了不会立刻报错而是请求一直等待页面卡死。Druid 的基本配置长这样driverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/sms?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse usernameroot passwordyourpassword initialSize5 maxActive20 maxWait3000 validationQuerySELECT 1 testWhileIdletrue几个参数值得解释maxActive是最大连接数设太大会拖垮数据库一般按并发量的 1.5 倍估maxWait是获取连接的最长等待毫秒数设短一点能让问题暴露得更快validationQuery配合testWhileIdle能在取连接时先探活防止拿到已经被数据库断开的死连接。排查连接泄漏最快的办法是写个测试类循环调用 Dao 方法几百次看 Druid 监控页面里活跃连接数是不是只增不减。如果是一定有地方没关。用try-with-resources写 JDBC 代码能从根本上避免这类问题try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { // 自动关闭 }5. 从本地能跑到能交付部署与启动异常对照代码写完了跑不起来是另一回事。IDEA 里建 JavaWeb 项目这件事每年都有人卡在第一步。这里说几个最容易出问题的点。5.1 工程目录结构与 Artifact 配置标准 Web 工程的目录结构是这样的sms/ ├── src/main/java/ Java 源码 ├── src/main/resources/ 配置文件、mapper 文件 ├── src/main/webapp/ │ ├── WEB-INF/ │ │ ├── web.xml │ │ └── lib/ 依赖 jar 包 │ ├── css/ js/ images/ │ ├── index.jsp │ └── login.jsp └── pom.xml用 Maven 的话WEB-INF/lib下的 jar 由 Maven 依赖自动打包进去别手动往里面拷 jar不然容易出现版本冲突。IDEA 里如果不用 Maven就得在Project Structure → Artifacts里手动把 jar 加到WEB-INF/lib下这一步漏了启动就是ClassNotFoundException。用 Maven 的项目还要注意pom.xml里的packaging必须是war不是jar。写成jar打出来的包里没有WEB-INF和webapp没法部署到 Tomcat。5.2 启动异常对照表下面这张表是我踩坑踩出来的基本覆盖了 90% 的启动失败场景现象大概率原因排查方向ClassNotFoundException: com.mysql.cj.jdbc.Driver驱动版本与类名不匹配MySQL 8 用com.mysql.cj.jdbc.Driver5.x 用com.mysql.jdbc.Driver404所有页面都访问不了应用上下文路径不对检查 Tomcat 部署的 Application context 是否加了额外前缀404只有某个 Servlet 访问不了url-pattern 写错或注解没生效检查WebServlet(/student)与访问路径是否一致web.xml 的metadata-complete是否挡住了注解500报 No suitable driverURL 格式错误检查jdbc:mysql://有没有拼错参数用amp;还是页面能开但没样式Filter 拦了静态资源放行清单加上/css/、/js/等中文参数乱码未设置请求编码加编码 Filter检查 Tomcat 版本连接超时 / 卡住连接池耗尽或泄漏查 Druid 监控检查是否有未关闭的连接Public Key Retrieval is not allowedMySQL 8 认证插件问题URL 上加allowPublicKeyRetrievaltrue注意allowPublicKeyRetrievaltrue只适合本地开发环境生产环境应该用 SSL 连接或者正确配置认证插件不要图省事把这个参数带上去。5.3 交付前值得回头再走一遍的检查清单项目能跑通之后我习惯做一轮回归检查这一步能省掉现场演示时一半的尴尬空数据情况表里一条数据都没有时列表页是不是正常显示暂无数据还是抛NullPointerException这个最容易漏因为开发时数据库里总是有数据。边界值成绩输入 0 和 100 能不能存输入 -1 和 101 有没有被拦住姓名超长会不会报数据库错误删除后刷新删除一条记录后刷新页面会不会重复提交删除请求导致报错并发修改两个浏览器同时编辑同一学生后保存的会不会覆盖先保存的如果要处理得加版本号字段做乐观锁。权限越界普通教师能不能通过手改 URL 访问管理员页面这个必须由后端 Filter 或拦截器兜底不能靠前端隐藏按钮。浏览器兼容至少在你演示用的那台机器上完整点一遍别只在自己电脑上测。我个人在带人做这类系统的体会是能跑通只完成了 60%剩下 40% 都在这些边界和异常上。学生管理系统这种题目代码量不大但把数据设计、分层、乱码、拦截、部署这几件事完整走一遍你对 Web 开发的理解会产生质的变化——你会开始关心请求从哪来、到哪去、中间发生了什么而不是只会往 Servlet 里堆代码。这个转变比多写几个功能重要得多。