一提到"JSP + 医院预约挂号"这套组合，很多做过Java Web课程设计或毕业设计的同学应该都不陌生。这个JSP余杭医院预约挂号管理系统s4468，光看名字就知道是个典型的信息管理类项目：前端用JSP渲染页面，后端靠Servlet处理请求，数据库用MySQL存数据，最后扔到Tomcat里跑起来。做这种项目最磨人的地方其实不在于功能本身有多复杂，而在于你得把整个开发链路跑通——从建表到连库，从页面传参到Servlet接收，从本地调试到最终部署，每一步都可能踩坑。
这篇文章我把这个项目从里到外拆开讲一遍。不管你是拿它当毕设参考，还是想自己动手复现练手，都可以照着下面的思路走。我会把功能设计、数据库表结构、核心代码逻辑、环境配置到部署调试的完整过程都过一遍，重点讲那些不翻文档根本不知道的细节问题。
1. 项目概述与业务需求拆解
1.1 预约挂号业务的核心痛点
医院挂号难是个老生常谈的问题，尤其像余杭医院这种综合性医院，科室多、医生多、患者流量大。传统的现场挂号模式有几个非常明显的坑：患者早上六七点就得去医院排队，排到了可能号没了；医院方面呢，窗口压力大，挂号收费人员根本忙不过来；而且人工挂号完全没法做精细化的号源管理，哪个科室放多少号、哪个医生哪天坐诊，全靠手工台账。
预约挂号系统要解决的就是这几个问题：把号源数字化、把挂号流程线上化、把医院的排班信息公开化。患者可以在家通过浏览器查看科室信息和医生排班，选定时间后在线提交预约；医院管理员可以管理科室、医生、号源和预约记录。这其实就是把传统线下窗口的挂号逻辑搬到了Web端，再加一层管理后台。
1.2 系统功能边界与角色划分
这个项目从使用角色上分，基本是三类人：普通患者用户、医院管理员、还有作为基础数据来源的医生。
患者端核心功能就是注册登录、浏览科室和医生信息、查看排班、提交预约、查看自己的预约记录、取消预约。这里要注意，患者端的功能设计中有一个很重要的点：预约之前必须先登录。因为预约记录必须和用户账号绑定，否则后期没法做记录查询和取消操作。
管理端的功能就重多了，包括科室信息管理、医生信息管理、排班管理、预约记录审核、用户管理。管理员要能对医生信息和排班信息做增删改查，还能查看所有预约记录，甚至处理一些异常的预约单。
医生的角色在系统里更多是作为数据对象存在的，他的出诊信息（科室、职称、排班时间）由管理员维护，本身不直接登录系统操作。当然也有系统会把医生登录查看号源情况做进去，但那个属于功能扩展，核心流程不依赖它。
1.3 为什么选JSP/Servlet这套技术栈
有人可能会问，现在都什么年代了，为什么还要做JSP项目？其实道理很简单：这套技术栈在高校课程设计和毕业设计里的地位太稳固了。JSP + Servlet + JDBC + MySQL这套组合，是整个Java Web开发的地基，把这套东西整明白了，后面学Spring MVC、Spring Boot都会顺畅很多。
而且从项目复杂度上看，预约挂号系统涉及的表有七八张，业务逻辑里有比较典型的"事务操作"（比如预约时既要插入预约记录，又要扣减号源数），用Servlet + JDBC来写，逻辑非常直白，代码量适中，正好适合用来做课程设计。如果硬上微服务、上Redis、上消息队列，反而有点杀鸡用牛刀。
另外，JSP项目调试其实挺直观的——改完代码重启Tomcat就能看到效果，不像前后端分离项目那样还要处理跨域、联调一堆破事。对初学者来说，这套技术栈的学习曲线是相对平滑的。
2. 数据库设计与核心表结构
2.1 数据模型整体规划
先想清楚这个系统里有哪些实体：用户、科室、医生、排班、预约记录、管理员。实体之间的关系也不复杂：一个科室有多个医生，一个医生有多个排班，一个排班可以被多个用户预约（但一个用户对一个排班只能预约一次），一个用户有多条预约记录。
所以数据库层面核心就是六张表。如果做细一点，还可以加一张公告表，用来发布就诊须知之类的信息，但核心业务用不到的话可以不做。我见过不少同学的库表设计一上来就是十几张表，各种关联关系拉满，结果写JOIN查询把自己绕晕了。这种业务体量，六张表刚刚好。
2.2 主要数据表字段设计
用户表(user)的字段设计要注意一点：除了基本的主键id、用户名、密码之外，最好加上真实姓名、手机号、身份证号这几个字段。手机号和身份证号在预约场景下几乎必填，因为医院需要这些信息来标识患者身份。
医生表(doctor)要冗余一个科室id进去，这样查询医生列表时直接join科室表就能拿到科室名称。字段包括医生姓名、性别、职称（主任医师、副主任医师、主治医师等）、科室id、简介。这里有个小细节：医生的照片字段可以做，但本地项目建议存图片路径字符串而不是二进制数据，不然数据库会变得非常臃肿。
排班表(schedule)是整个系统的核心表。字段包含医生id、排班日期、时段（上午/下午）、号源总数、已预约数、剩余号数。这个表的每一次插入或更新，都直接影响预约功能的可用性。
预约记录表(appointment)字段包含预约编号、用户id、排班id、预约时间、状态。状态字段建议用tinyint类型，0表示待就诊、1表示已完成、2表示已取消，不要用字符串。
2.3 表关系与数据一致性处理
表关系在Navicat或者MySQL Workbench里建好外键关系，有助于理清逻辑，但实际开发中我建议业务逻辑层自己控制数据一致性，数据库外键可以建但不要过度依赖。
有一个必须注意的点：预约时要同时更新排班表的剩余号数和预约记录表新增一条数据，这两个操作必须放在同一个事务里。如果只插入预约记录，但没扣减号源，就会出现号源超卖的情况。或者更糟，号源扣了但预约记录没插进去，患者白约了。
START TRANSACTION; INSERT INTO appointment(user_id, schedule_id, status, create_time) VALUES(?, ?, 0, NOW()); UPDATE schedule SET remain = remain - 1 WHERE id = ? AND remain > 0; COMMIT;注意UPDATE语句里这个remain > 0条件，这是防止超卖的关键，后面我在并发问题的章节还会再聊到它。
3. 核心技术点与实现细节
3.1 JSP页面与Servlet的交互设计
JSP项目的前后端交互模式其实相当统一：浏览器发起HTTP请求，Servlet接收请求参数，调用DAO层方法操作数据库，然后把结果存到request或session作用域里，最后forward或redirect到JSP页面去渲染。
以用户登录这个最简单的功能举例，流程是这样的：用户在login.jsp表单里输入用户名和密码，表单action指向LoginServlet的URL。LoginServlet从request里取出参数，调用UserDao的queryByUsernameAndPassword方法查库。如果查到了，就把用户对象存进session，然后redirect到index.jsp；如果没查到，就往request里存一个错误信息，然后forward回login.jsp。
这里有一个很多新手会犯的错误：登录成功后用了forward而不是redirect。forward会导致浏览器地址栏停留在login.do，用户刷新页面时表单会重复提交。而redirect是302跳转，地址栏会变成index.jsp，刷新也没问题。记住这个原则：涉及数据变更的POST请求，处理完一定要redirect，不要forward。
JSP页面本身尽量少写Java代码，推荐用JSTL标签库配合EL表达式来遍历数据。比如展示预约记录列表时，把List放进request后，页面里可以直接用c:forEach循环渲染，比scriptlet里写for循环清爽得多，也不容易出错。
3.2 科室排班与号源管理的实现逻辑
排班功能是预约系统的发动机。管理员创建排班时，需要选择医生、日期、时段、号源总数这几个参数。这里有一个业务上的细节：同一医生同一天同一时段，不应该允许重复创建排班。所以在ScheduleDao的新增方法里，要先做一个唯一性校验——查一下有没有doctor_id、work_date、period三个字段完全一致的记录，有就提示管理员排班已存在。
号源扣减的问题前面已经提过，再补充一点：预约的时候要分两步走，先加载排班信息检查剩余号数是否大于0，再执行插入和更新操作。这两步之间有一个时间窗口，在并发场景下可能出问题。解决办法是把检查条件直接写进UPDATE语句的WHERE里，也就是前文那种写法。
在展示端，患者选择排班后，页面要明确显示该排班还剩多少号。这个信息可以直接从排班表查询。如果剩余号为0，前端按钮置灰显示"已约满"，同时后端也要做校验，不能只靠前端挡着。
3.3 登录认证与权限控制
登录认证用的是HttpSession，这算是所有Java Web项目的通用做法。登录成功后把user对象存在session里，后续需要判断登录状态的请求，就用Filter过滤器统一拦截。
这个项目里我建议写两个过滤器：一个是全局的编码过滤器，设置request和response的字符集为UTF-8；一个是登录检查过滤器，拦截所有非登录页面和登录接口的URL，检查session里有没有user对象，没有就重定向到登录页。
编码过滤器这个事千万别忽略。JSP页面、Servlet里取参数、JSP页面输出、数据库连接四处的编码必须统一成UTF-8，不然中文乱码问题会搞得你怀疑人生。最常见的坑是：页面显示正常，但往数据库存中文就变成问号，这种十有八九是JDBC连接串没加characterEncoding参数。
权限控制层面，医生和管理员的操作页面不需要做太细的区分，因为管理员功能本来就是个独立目录（比如/admin/下的页面），过滤器中做个简单的目录前缀判断就够了。普通用户访问admin目录直接拦下来，返回无权限提示。
3.4 预约流程的状态机设计
预约记录的状态变化是这个系统的业务骨架。我设计的是一个非常简单的四态流转：待就诊、已完成、已取消、已过期。待就诊是预约成功时的初始状态；管理员在后台可以把某条记录标记为已完成，模拟患者到院就诊后的状态更新；用户在就诊前可以取消预约，此时状态变为已取消，同时必须把排班表里扣掉的号数加回来；已过期状态是给那些超过就诊日期但没取消也没完成的预约单准备的，这个可以用一个定时任务或者手动触发的方式来处理。
取消预约归还号源这个操作，是最容易遗漏的。如果用户取消预约但号源不归还，那这对医院和患者都不公平——号被占了但人又不来。所以CancelAppointmentServlet里要同时做两件事：把appointment表的状态改成已取消，把schedule表的remain字段加一。老规矩，这两个操作放同一个事务。
4. 开发环境搭建与调试部署全记录
4.1 开发工具链选型说明
环境这个东西，不同版本搭配起来能折腾掉半条命。我这边实测下来最稳的一套组合是：JDK 8 + Tomcat 8.5 + MySQL 5.7 + Eclipse或IDEA。JDK版本千万别用太高，什么JDK 11、JDK 17听着挺新，但Tomcat 8.5和它搭配时有的老项目会出现编译兼容问题。MySQL 5.7比8.0省心，因为8.0的密码认证方式改了，JDBC驱动兼容性要额外处理。
开发工具二选一的话，Eclipse对JSP项目支持很直观，带Tomcat插件，部署调试一条龙。IDEA也行，但需要手动配置Artifacts和Deployment，新手容易在这里卡住。我个人的建议是：课程设计阶段用Eclipse，省下来的时间拿去调代码，更划算。
数据库可视化工具用Navicat或者DBeaver都行。Navicat更傻瓜，DBeaver免费，看个人习惯。建表这种事不建议手敲SQL命令行硬写，可视化工具建表效率高得多，还能看到表结构关系。
4.2 环境配置踩坑实录
我帮人排查过好几个环境问题，最常见的集中在下面这几个地方。
第一个是Tomcat端口被占用。启动Tomcat时报端口8080被占，通常是之前开过一个Tomcat实例没关干净，或者电脑上有其他服务占了这个端口。Windows下用netstat -ano查PID，然后任务管理器结束对应进程，或者直接改server.xml里的端口号。
第二个是数据库连接失败。报错信息一般是Access denied for user 'root'@'localhost'或者Unknown database。前者是账号密码不对，后者是数据库名没对上。这里的坑点在于：JDBC连接串里写的数据库名必须和你在MySQL里实际创建的库名完全一致，大小写都不能错。Linux服务器上还得分大小写，Windows上倒是无所谓。
第三个是动态Web项目部署后404。这通常是因为项目的访问路径写错了。项目部署到Tomcat后，访问URL是http://localhost:8080/项目名/...，不是直接http://localhost:8080/。如果配置了application context，这个项目名是可以自定义的，但URL里的路径必须和Context路径匹配。
4.3 部署到Tomcat的完整步骤
部署环节我分两种场景说，一种是在IDE里跑，一种是打包成war包放到独立Tomcat跑。
IDE里跑是最省事的。Eclipse里配置好Tomcat运行时环境后，右键项目 -> Run As -> Run on Server，自动完成编译部署启动。IDEA里要先配置Tomcat Server，然后创建一个Artifact，类型选Web Application: Exploded，Deployment里加上这个Artifact，运行即可。
独立Tomcat部署的流程更接近真实生产环境。第一步，项目右键导出WAR文件，注意不是JAR，是WAR。第二步，把WAR文件复制到Tomcat的webapps目录下。第三步，启动Tomcat，它会自动解压WAR包生成同名目录。第四步，导入数据库的SQL文件。这里推荐用命令行导入：
mysql -u root -p health_db < health_db.sql注意SQL文件里如果有建库语句，导入前就要确认库名和连接串里写的一致；如果SQL文件只建表不建库，需要先手动创建库再指定导入。
第五步，检查运行日志。Tomcat的logs目录下catalina.out文件里会有详细日志。启动无报错后，浏览器访问http://localhost:8080/项目名/就能看到系统首页了。
5. 常见问题与排查技巧实录
5.1 数据库连接池选型与配置细节
这个项目虽然可以用原生JDBC，但我建议引入Druid连接池，没别的原因，就是省心。裸写JDBC最烦的问题是每次请求都要getConnection然后close，频率一高数据库的连接资源开销很大。连接池的机制就是预先创建一批连接放在池里，用的时候拿，用完还回去，效率高很多。
Druid的配置其实就一个配置文件加几行代码。druid.properties文件里写jdbcUrl、username、password、initialSize这些参数。初始化时用DruidDataSourceFactory创建DataSource，之后的代码里统一从dataSource.getConnection()拿连接。
注意Druid依赖包一定要放到WEB-INF/lib目录下，否则运行时跑起来报ClassNotFoundException或者NoClassDefFoundError，那都是jar包缺失导致的。
5.2 分页查询的实现方案
预约记录查询这个功能在管理员后台是必须分页的。不然后台预约数据一大，一个页面渲染几千条记录，浏览器都要卡死。分页的SQL写法是标准的MySQL分页：
SELECT * FROM appointment LIMIT ?, ?;第一个问号是起始偏移量，第二个是每页条数。在Servlet里算好这两个值：当前页码和总页数从查询得到，起始偏移量=(当前页-1)*每页条数。前端JSP页面渲染一个简单的上一页/下一页导航，参数用当前页码传给Servlet。
这里有个细节：查询总记录数用的COUNT函数结果要存到request里传到JSP页面，用来计算总页数。不然每页都要重新查一次总数，数据不一致而且性能差。我用过很多次这个模式，简单可靠，没有任何花哨的东西。
5.3 常见报错整理速查
结合我自己的使用经验，把出现频率最高的几个问题整理成下面这个表，方便你排查时对照：
| 报错信息 | 常见原因 | 排查思路 |
|---|---|---|
| 404 Not Found | 路径写错或项目未正确部署 | 确认Context路径和请求URL，查Tomcat日志 |
| 500 空指针异常 | 从数据库查不到数据后直接调用对象方法 | 在关键位置判空，检查SQL条件是否过严 |
| 中文乱码 | 页面编码、请求编码、数据库编码不一致 | 统一UTF-8，JDBC连接串加characterEncoding |
| Access denied | MySQL账号权限不足或密码错误 | 用命令行验证账号能正常连接 |
| Port 8080 was already in use | 端口被占用 | netstat查PID后结束进程 |
| JSTL标签不生效 | jar包缺失或版本不匹配 | 把jstl和standard包放进WEB-INF/lib |
5.4 并发预约时的数据安全问题
最后专门说一下并发问题，这个是很多同学被问到时答不上来的点。设想这个场景：某个专家号只剩最后一个号，两个患者同时点预约，系统如果不做任何处理，可能出现两个人都预约成功的诡异情况。
原因在于：两个人同时读到剩余号数是1，同时通过校验，然后各自执行了插入预约记录的SQL，最后更新剩余号数时数值就错了。这种情况在真实项目里绝对不能接受。
解决办法前面提到过，就是把校验条件放进更新SQL：
UPDATE schedule SET remain = remain - 1 WHERE id = ? AND remain > 0;这条语句执行后，返回的影响行数就是判断依据。如果影响行数为1，说明扣减成功，号源占了；影响行数为0，说明remain不大于0，号源已经没了，直接返回"预约失败，号源已满"。有这一步兜底，哪怕真有两个人同时操作，数据库层面也只会让一个请求成功。配合之前的事务操作，整个预约为程就稳了。
我个人经验是用"先扣减、再验证"的思路来解决超卖问题，你如果把验证放在扣减之前，那并发问题就永远解不掉。
再补充一句关于测试的建议：如果你要模拟并发预约，别手动开两个浏览器刷，直接用JMeter或者Apache Bench压一下，并发设成10个线程同时请求预约接口，很快就能看出系统在极端情况下会不会出问题。搞清楚了这一点，整个项目的含金量会上升一大截。
