基于JavaWeb的智慧养老院管理系统设计与实现全解析

每到毕业季，总有一批计算机专业的学生对着选题名单发愁：管理系统做了一茬又一茬，图书馆管理系统、学生选课系统、超市收银系统，听得耳朵都起茧了。如果你正在纠结选题，我认真建议你考虑一下基于JavaWeb的智慧养老院管理系统。这个题目听起来不花哨，但它踩中了当下的社会热点，功能边界清晰，技术栈经典，而且无论你打算用Servlet+JSP三件套，还是套Spring Boot的壳，都能做出一个完整、能演示、能写进简历的项目。最关键的，是它真的有实际使用场景，答辩时评委不会觉得你是在交作业，而是觉得你思考过问题。

这套系统说白了就是给养老院做一个信息化的管理后台，把老人档案、护工排班、健康记录、床位管理、探访预约这些线下台账全部搬到Web系统里来。我从选题理由、技术选型、数据库设计到具体的落地实现一步步拆给你看，连我在开发过程中踩过的坑、答辩时怎么讲亮点，都会一并写出来，希望对正准备动手的你有点实际帮助。

1. 项目定位与核心需求拆解

1.1 养老院管理的真实痛点

别看养老院管理这事儿听起来简单，真去做需求调研你就会发现，传统养老院的日常运营基本靠纸和笔，外加一个Excel表格。护工排班是手写的，老人身体指标登记是一本本纸质台账翻着查，家属想探访先打值班室电话确认有没有空房间，床位空了没人及时更新，费用结算更是月底对账对得头疼。

这种线下管理方式的问题非常典型：信息更新不及时，老人档案散落在不同护理员手里；数据凑不齐，月底统计报表得靠人肉汇总；家属想了解老人情况只能靠电话联系护工，体验差，护工也不堪其扰。智慧养老院管理系统要解决的，就是把这些分散的信息集中到一套Web应用里，不同角色各有一个入口，数据实时更新，谁都能在权限范围内查到想查的信息。

我建议你去做需求调研的时候，别只盯着"增删改查"这种技术词汇，而是真的去聊一位养老院运营人员的日常工作。你会发现最痛的不是功能少，而是"数据根本对不上"。比如一个老人转房间了，床位表和费用表没有联动更新，月末一算账就出差错。这种场景放到系统设计里，就是"床位状态变更时要联动更新关联表"的业务规则。一旦你把真实痛点挖出来，你的系统就比那些纯虚构的管理系统扎实得多。

1.2 系统角色与功能模块划分

这个系统我建议按三种角色来做，既能控制复杂度，又能覆盖完整的权限管理需求：

对应的功能模块我列了一个标准版本，你在写开题报告时可以直接用：

老人档案管理：入住、转房、退房的信息登记与历史记录，支持条件搜索和分页浏览。
健康记录管理：护工定期录入血压、体温、用药情况等数据，系统按时间线展示趋势。
床位管理：楼栋、楼层、房间、床位四级结构，床位状态自动关联老人入住状态。
探访预约管理：家属在线提交探访时段，管理员审批后生成探访单。
费用管理：按月生成床位费、护理费、餐费账单，支持实收登记。
护工排班管理：简单的值班表维护，避免用Excel来回传。
系统用户管理：不同角色的账号、权限，以及密码修改。

这套模块设计的巧处在于，每两个模块之间都有业务关联，比如床位状态会影响老人入住，健康记录又挂在老人档案下面，而费用管理又要同时读取床位数据和老人数据。这种关联恰恰是毕业设计评分时最看重的东西，评委想看到的不是一堆孤立的CRUD，而是模块之间的联动逻辑。

1.3 为什么这个题目适合做毕业设计

我在前面提到的那些管理类题目，普遍的问题是需求太泛、边界模糊，比如"超市收银系统"既有商品管理又有会员又要对接小票打印，技术点全堆上反而做得又散又浅。智慧养老院管理系统的好处是，它的业务场景非常收敛，核心就是"以老人为中心的信息管理"。

这个系统的技术面覆盖也相当完整：从前端JSP页面，到Servlet控制器，到Service业务逻辑，到DAO数据访问，再到MySQL表结构设计，一条链路下来没有断点。横向对比的话，还包含了权限控制、模糊查询、分页处理、日期处理、文件上传（老人照片）这类在面试和笔试里高频出现的技术点。对一个本科生来说，做完这个项目，JavaWeb的知识体系基本就走通了一遍。

还有一点很实际：这个选题有社会价值。老龄化是现实问题，答辩的时候你可以从"养老服务信息化"切入去讲项目背景，评委对这个方向普遍有好感。我当年答辩的时候，评委问的第一个问题就是"你调研过真实养老院的数据吗"，虽然数据是我自己模拟的，但至少功能是跟着真实需求走的，这一点给了我很大的解释空间。

2. 技术选型与架构设计思路

2.1 JavaWeb技术栈怎么选

很多人在技术选型上纠结半天：是走十几年前经典的Servlet+JSP，还是直接押注Spring Boot？我的观点是，看你的目的是"稳过答辩"还是"往简历上加分"。

先看前者。如果学校对毕业设计的要求就是演示功能、写篇论文、跑通代码，那Servlet+JSP反而是最稳的选择。原因是代码足够直白，每一个请求从浏览器到Servlet再到JSP的过程都非常透明，你随时能说清楚每个环节发生了什么。而且答辩时老师极大概率会抽查代码，用Spring Boot框架写的东西，如果包着一堆自动化配置，你解释不清楚底层原理，导师反而会觉得你是在"框架依赖"。

再看后者。如果你之后打算找Java开发的工作，我会更加推荐你用Spring Boot来写这个系统。理由很简单，现在的公司项目已经很少再用Servlet手工配置了，HR和面试官想看到的也是你对Spring Boot的熟悉程度。不过你应该保留一套Spring Boot + MyBatis的写法，同时把Servlet/JSP的思路讲清楚，这两者并不矛盾。最怕的就是只会点Java基础知识，框架没学透。

我当年综合了这两个方向，最后选了纯Servlet+JSP + JDBC + MySQL的组合，属于是"舒服四件套"：代码量适中，完全不需要引入Maven的传递依赖地狱，部署时一个WAR包丢进Tomcat就可以跑。如果你是第一次做完整项目，真的建议先从这条路线入手，框架后面可以再试。

2.2 分层架构与MVC模式

分层架构不是可有可无的规范，而是决定你后期还能不能继续改代码的地基。我见过很多学弟学妹把数据库查询直接写在Servlet里面，页面上一排Java代码，最后改需求的时候头皮发麻——因为你不知道改一处会不会影响八处。所以我强烈建议你按标准三层架构来做：

控制层（Servlet）：接收请求、解析参数、调Service层、把结果放进request域、转发到JSP。
业务层（Service）：处理具体业务逻辑，比如退房时同时更新老人状态、床位状态、并生成结算记录。
数据访问层（DAO）：封装JDBC操作，每个表对应一个DAO类，方法命名尽量贴近业务。

再加上一个工具包(model、entity、util)，用来放数据对象和公共工具类，比如日期转换、字符串判空、MD5加密等。这样分完之后，代码的可读性会好很多，答辩的时候老师打开你的工程一看，结构清爽，印象分直接高了一截。

我在做这个项目时，包结构是这么定义的：

code复制src
├─ com.xxxx.bean       # 实体类（对应数据库表）
├─ com.xxxx.dao        # 数据访问层（JDBC操作）
├─ com.xxxx.service    # 业务逻辑层
├─ com.xxxx.servlet    # 控制器层（继承HttpServlet）
├─ com.xxxx.filter     # 过滤器（编码、登录校验）
├─ com.xxxx.util       # 工具类
└─ com.xxxx.listener   # 监听器（可选，比如在线人数统计）

实体类对应数据库表字段，比如User、Elderly、HealthRecord、Bed、FeeRecord、VisitAppointment。你写的时候会注意到，很多实体类的字段名跟你页面表单里的name属性几乎一致，这就是最简单的JavaBean精神——用属性承载数据，让请求参数通过反射自动组装成对象。前期你会觉得繁琐，但等做了几个模块之后，你会习惯这种模式，因为它能显著减少重复代码。

另外给一个大多数代码里都会用到的公共类：BaseServlet，它把所有Servlet里的doGet和doPost统一成process请求分发，通过反射调用子类方法。这样的话，每个功能模块只需要一个Servlet类，里面按方法拆，页面URL也更简洁。这个设计也是很多企业项目的原型，可以在答辩时聊聊。

2.3 数据库设计的表结构与关系

数据库设计是这套系统的灵魂，我先说一个很多毕业生都会犯的错：表设计要么太碎，要么太粗，字段命名随意，类型不假思索地全用VARCHAR，连日期都存成字符串。我的建议是，所有字段类型必须跟真实语义保持一致，日期就用DATE/DATETIME，数值就用INT/DECIMAL，状态用TINYINT，文本用TEXT。这样后面写统计SQL时会非常舒服。

核心表我建议至少设计8张，我画了一下大概的表结构和关系：

老人表（elderly）：主键id，姓名、性别、身份证号、出生日期、联系电话、入住日期、退房日期、状态（在住/退房）、家属联系方式等。
用户表（user）：主键id，用户名、密码（MD5加密存储）、真实姓名、角色（admin/nurse/family）、关联老人id（如果是家属角色则关联）。
护工表（nurse）：护工基本信息，关联用户表。
健康记录表（health_record）：主键id，老人id、体温、血压、心率、血糖、用药记录、饮食情况、记录时间、录入人。
床位表（bed）：id、楼栋、楼层、房间号、床位号、状态（空闲/占用）、关联老人id。
探访预约表（visit_appointment）：id、老人id、申请人姓名、联系电话、探访日期、探访时段、状态（待审批/通过/拒绝）、登记时间。
费用表（fee_record）：id、老人id、费用类型（床位费/护理费/餐费）、金额、计费月份、实收金额、状态（未缴/已缴）、缴费时间。
排班表（shift_schedule）：id、护工id、值班日期、班次（早/中/晚）。

表关系里最核心的就是老人表之后的所有业务表都通过elderly_id关联到老人，而床位表通过bed_id和elderly_id维持一对一的在住关系。这里有个细节需要注意：床位状态和老人状态不能做成强一致性的同步，而是要尽量用SQL事务去保证。比如你办理入住时，在一个事务里同时更新老人状态和床位状态，任何一步失败就回滚。如果你在代码里分开执行两条update语句而不开事务，后面绝对会因为忘了改状态而出一堆bug。

从答辩角度讲，数据库设计是非常值得多花点时间的部分。你可以提前准备好一份"数据库设计说明书"，把每张表的设计目的、字段含义、表间关系用表格列出来，答辩的时候老师问到你为什么这个字段要这么设计时，你能讲清楚，这就是很大的亮点。

3. 核心功能模块的实现解析

3.1 建库建表与初始化数据

我从头开始演示一下建表的过程，就拿最核心的老人表来举例。你写完建表SQL之后，最好顺手插入几条测试数据，数据字段尽量模拟真实情况，这样后面开发页面、调试SQL时很有帮助。表结构如下：

sql复制CREATE TABLE `elderly` (
  `id` INT NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` VARCHAR(50) NOT NULL COMMENT '姓名',
  `gender` TINYINT NOT NULL COMMENT '性别 1-男 2-女',
  `id_card` VARCHAR(18) NOT NULL COMMENT '身份证号',
  `birth_date` DATE NOT NULL COMMENT '出生日期',
  `phone` VARCHAR(20) DEFAULT NULL COMMENT '本人电话',
  `contact_phone` VARCHAR(20) NOT NULL COMMENT '紧急联系人电话',
  `check_in_date` DATE NOT NULL COMMENT '入住日期',
  `check_out_date` DATE DEFAULT NULL COMMENT '退房日期',
  `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态 1-在住 2-已退房',
  `bed_id` INT DEFAULT NULL COMMENT '关联床位ID',
  `remark` TEXT COMMENT '备注',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

你看这个表设计有几个细节：性别用TINYINT而不是VARCHAR，因为查询统计和判断逻辑更简洁；身份证号必须是CHAR(18)，长度固定；状态字段设置默认值1，避免插入时漏写；进InnoDB引擎开着外键关联和事务支持。这些细节在答辩时都可以拿出来讲，老师一眼就能看出你不是随便写写的。注意CHARSET一定要用utf8mb4，我之前用过utf8，老人生日历程里万一有特殊符号或者生僻字就直接乱码了，后来统一改成utf8mb4才消停。

健康记录表我建议这么设计：

sql复制CREATE TABLE `health_record` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `elderly_id` INT NOT NULL COMMENT '老人ID',
  `temperature` DECIMAL(4,1) DEFAULT NULL COMMENT '体温',
  `blood_pressure_high` INT DEFAULT NULL COMMENT '血压-收缩压',
  `blood_pressure_low` INT DEFAULT NULL COMMENT '血压-舒张压',
  `heart_rate` INT DEFAULT NULL COMMENT '心率',
  `blood_sugar` DECIMAL(4,1) DEFAULT NULL COMMENT '血糖（mmol/L）',
  `medication` VARCHAR(255) DEFAULT NULL COMMENT '今日用药',
  `diet` VARCHAR(255) DEFAULT NULL COMMENT '饮食情况',
  `record_time` DATETIME NOT NULL COMMENT '记录时间',
  `nurse_id` INT NOT NULL COMMENT '录入护工ID',
  PRIMARY KEY (`id`),
  KEY `idx_elderly_time` (`elderly_id`, `record_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

联合索引idx_elderly_time是为了后面查询"某个老人的健康记录趋势"时更快，SQL条件WHERE elderly_id = ? ORDER BY record_time DESC走这个索引就够了。这也是我在做这个项目时相对满意的优化点，虽然数据量小用不上索引，但体现出的设计意识是加分项。

如果你用Spring Boot + MyBatis，建表后建议额外加一层mybatis-generator自动生成实体类，省得手写重复字段。但如果你是Servlet+JDBC路线，老老实实手写Bean也很快，建模过程本身就是复习JavaBean规范的绝佳机会，不建议跳过。

3.2 登录认证与权限控制

登录和权限是管理系统里躲不开的模块，而且往往是答辩时老师第一个关注的点。我建议你用Filter统一处理，而不是在每个Servlet里手动判断session。这样做的好处是安全逻辑集中、不易遗漏。

我先写一个最简单的统一登录校验Filter：

java复制public class LoginFilter implements Filter {
    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.jsp") || uri.endsWith("/login")
                || uri.contains("/css/") || uri.contains("/js/")) {
            chain.doFilter(request, response);
            return;
        }
        Object user = req.getSession().getAttribute("loginUser");
        if (user == null) {
            resp.sendRedirect(req.getContextPath() + "/login.jsp");
            return;
        }
        chain.doFilter(request, response);
    }
}

再看密码加密。明文存密码在毕业设计里真的太常见了，但也是一眼就能被答辩老师抓出来的安全漏洞。我强烈建议用MD5加盐或者至少是MD5摘要之后再入库。配合工具类，注册的时候加密存储，登录的时候把用户输入的密码加密后和库里的密文比对。虽然MD5现在不算强安全算法，但在毕业设计场景下，你能主动意识到"密码不能明文存"这一点，已经是很大的加分项。

登录成功之后，我还建议你往session里放一个角色标识，比如roleType=admin/nurse/family，这样可以通过Filter做第二层权限过滤。因为不是所有页面都允许所有角色访问，比如管理员的费用管理页面，护工是不应该能打开看到的。Filter会再判断一下路径前缀和角色是否匹配，不匹配就跳到403页面。

我分享一下我做的时候比较顺利的前后端数据流转方式：登录成功后把用户基本信息放到session里，JSP页面上用EL表达式${sessionScope.loginUser.name}来显示当前用户名，顶部导航栏根据角色渲染不同菜单项。这样代码不会显得重复，而且保持session里的用户对象比较干净，不存放多余的查询结果。

3.3 分页查询与模糊搜索

管理端列表页（老人列表、费用账单、探访记录）几乎一定会用到分页。有些同学拿到的代码是全量查询后在前端用JavaScript做分页，这种我只能说：数据量小能跑，但你拿着这个去答辩，老师问你"如果有一万条记录你怎么处理"，你就支支吾吾了。正确的做法是SQL层面的LIMIT分页，由后端计算偏移量。

分页参数计算方法很简单：

code复制pageSize = 10（每页条数）
pageNum = request.getParameter("pageNum")，默认1
offset = (pageNum - 1) * pageSize
SQL: SELECT * FROM elderly WHERE name LIKE ? LIMIT ?, ?

这样一个很直观的计算过程，我建议你自己手动推导一遍，后面对前端翻页逻辑的理解会直线上升。我在项目里还顺手做了一个超简单的分页工具类PageBean，封装了总条数、总页数、当前页和每页记录数，避免每个模块都重复写分页代码。

模糊搜索和分页经常要组合使用，这时候在Service层你需要统计不带LIMIT的总条数，再执行带LIMIT的查询。比如：

java复制public PageBean<Elderly> searchElderly(String keyword, int pageNum, int pageSize) {
    String baseSql = " FROM elderly WHERE status = 1 ";
    String countSql = "SELECT COUNT(*) " + baseSql;
    String dataSql = "SELECT * " + baseSql + " ORDER BY check_in_date DESC LIMIT ?, ?";
    // 注意：拼接keyword时用PreparedStatement，防止SQL注入
}

我踩过一个坑是统计SQL漏掉了搜索条件，导致搜索后总页数不变。这个低级错误排查了我一下午，最后发现countSql里没拼keyword。从那以后我的习惯是先写好count的SQL，再拼data的SQL，反复对照条件部分是否一致。所以搜索和分页联调时，你多关注"条件一致"这四个字。

至于页面上的JSP，用<c:forEach>遍历查询结果，用<c:if>判断当前页是否显示上一页/下一页按钮。这个过程不复杂，但是很体现你对JSTL的使用熟练度，建议别把这些工作全丢给js渲染。

3.4 事务处理与联动更新

事务处理是这个项目里我把代码写得最认真的一块。理由很简单，只要你的业务逻辑跨表更新，就一定有失败的可能。比如办理入住，至少涉及两步操作：更新老人表状态、更新床位表状态。如果你第一步成功、第二步失败，数据库就处于不一致状态，后面查床位、统计在住人数全都会出错。

在JDBC里实现事务的经典写法是：

java复制Connection conn = null;
try {
    conn = DBUtil.getConnection();
    conn.setAutoCommit(false); // 开启事务

    // 1. 更新老人表：入住状态、绑定床位
    // 2. 更新床位表：状态改为已占用，绑定老人ID

    conn.commit(); // 提交
} catch (SQLException e) {
    if (conn != null) {
        conn.rollback(); // 回滚
    }
    throw e;
} finally {
    DBUtil.close(conn);
}

这里有个重要的工程习惯：Service层不要自己new Connection，而应该从DAO层或者统一的数据源获取，并且把事务边界控制在Service方法里。因为DAO只负责单表操作，Service才知道"这是一个需要原子性的业务动作"。如果你把事务放在DAO里，多个DAO之间的事务就无法共享同一个Connection，回滚也失效了。

Spring Boot的写法更简单，在Service方法上加上@Transactional注解就行，但你必须清楚它背后的AOP原理，答辩时老师可能顺着这个注解问你"Spring事务什么时候会失效"。提前准备下"自调用导致事务失效"这个经典问题，答得出来就是亮点。

3.5 数据可视化简单实现

智慧养老院管理系统如果要加分，可以在首页加一个简单的数据统计面板：在住老人总数、今日健康记录条数、待审批探访数、本月费用实收金额。这些数据直接从数据库聚合查询出来，然后展示在管理后台首页卡片上。你要是愿意还可以用ECharts画一个老人年龄分布饼图或者每月的健康指标折线图，这种可视化效果在答辩现场特别抓眼球，而且ECharts引入成本极低，一个<script>标签加一段配置就行。

我自己做的时候，首页放了一个"近7天体温趋势折线图"，数据来源是健康记录表按天聚合的平均体温。SQL写起来也不难，关键是图表出来之后页面档次一下就上去了。这个模块在答辩时很能让老师眼前一亮，因为它不只是一个"管理系统"，还带了一点点"数据分析"的意思。当然，前提是你要能解释清楚图表数据是怎么算出来的，别只停留在"图表自动就出来了"这一步。

4. 开发环境搭建与关键配置实操

4.1 IDEA创建Web项目与Maven配置

我强烈建议你用Maven来管理依赖，哪怕你是Servlet+JSP项目。理由很简单：不用手动往WEB-INF/lib里塞jar包了，MySQL驱动、JSTL标签库、Servlet API这些全都用pom.xml声明，干净利落。创建一个Maven Web项目的标准步骤大概是：

1. 在IDEA中新建Maven项目，选择archetype:webapp模板。
2. 项目结构里确认是否有src/main/java、src/main/resources、src/main/webapp/WEB-INF等目录。
3. pom.xml里加入servlet-api、jsp-api、jstl、mysql-connector-java、druid等依赖。
4. 配置Tomcat：Run -> Edit Configurations -> 加一个Tomcat Server -> Local，Deployment里添加war包，Application context建议设成/elderly。

有一个容易忽略的点：mysql-connector-java的版本一定要和你本机MySQL版本对应。我早年用过一次Connector/J 5.1连MySQL 8.0，结果直接报Public Key Retrieval is not allowed，加了一堆参数才解决。如果你是MySQL 8.x，建议直接上8.0.30+版本。

配置Tomcat的Deployment时，很多人遇到访问不到页面的问题，多半是Application context没配对。如果你设的是/elderly，那么访问首页就应该是http://localhost:8080/elderly/index.jsp，千万别下意识不加这个前缀，我当年在这儿吃了小半天的亏。建议IDEA里的URL设置成http://localhost:8080/elderly/，可以直接跳转到项目首页。

4.2 数据库连接工具类与参数配置

JDBC连接最朴素的做法是每次操作都DriverManager.getConnection()，但这样在高频访问下性能很差。现在我建议你至少用上Druid连接池，只需要在druid.properties里配置几行参数，然后写一个工具类拿连接：

java复制public class DBUtil {
    private static DruidDataSource dataSource;

    static {
        try {
            Properties props = new Properties();
            props.load(DBUtil.class.getClassLoader()
                    .getResourceAsStream("druid.properties"));
            dataSource = (DruidDataSource) DruidDataSourceFactory
                    .createDataSource(props);
        } catch (Exception e) {
            throw new RuntimeException("初始化数据源失败", e);
        }
    }

    public static Connection getConnection() {
        try {
            return dataSource.getConnection();
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
    }

    public static void close(Connection conn, Statement stmt, ResultSet rs) {
        if (rs != null) { try { rs.close(); } catch (SQLException ignored) {} }
        if (stmt != null) { try { stmt.close(); } catch (SQLException ignored) {} }
        if (conn != null) { try { conn.close(); } catch (SQLException ignored) {} }
    }
}

注意close方法里这个和ResultSet -> Statement -> Connection关闭顺序很重要，如果你只用connection.close()而不关闭前面的Statement和ResultSet，连接池回收后还是会有内存泄漏风险。写这个工具类的时候我还顺便解释一下为什么外层不直接返回dataSource——因为业务层想拿到的只是Connection，池子内部怎么管理你不需要关心。这正好是"依赖倒置"的一种体现。

4.3 中文乱码的全局处理

JavaWeb中文乱码是几乎所有毕业生都会撞见的坑，我记忆犹新。乱码的根源在于：浏览器请求编码、Tomcat容器解码、Servlet响应编码、MySQL连接编码、JSP页面编码，这五处必须保持统一，否则任何一个环节编码不一致都会出现乱码。

我最省心的做法，是直接写一个EncodingFilter统一设置：

java复制public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
        throws IOException, ServletException {
    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) resp;
    request.setCharacterEncoding("UTF-8");
    response.setContentType("text/html;charset=UTF-8");
    chain.doFilter(request, response);
}

同时，JSP页面第一行加上<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" %>，MySQL连接URL上带上characterEncoding=utf8和useUnicode=true。另外还要注意Tomcat里对URL中中文参数的解码默认是ISO-8859-1，所以如果是GET请求参数里带中文，最好在Servlet里转码：

java复制String name = request.getParameter("keyword");
if (name != null) {
    name = new String(name.getBytes("ISO-8859-1"), "UTF-8");
}

当然，如果统一了EncodingFilter，Tomcat 8及以上对GET请求也能正确处理UTF-8。不同环境有细微差别，所以我建议你每做一个新接口，就在浏览器地址栏测一下带中文的GET请求，防止页面显示出"锟斤拷"这种经典乱码。乱码问题虽然不算高深，但你把这个处理逻辑讲清楚，反而能跟老师说"实际开发中遇到过并解决过"，这比背概念有用多了。

4.4 前端页面与后端数据的对接

关于页面层，老实说毕业生如果做后端，JavaScript不强是常态。但至少你应该会用AJAX提交表单和处理JSON响应，因为这种前后端交互方式在项目演示时非常加分，尤其是探访预约这种需要动态刷新页面的模块。

我当时是这么处理的：表单不整页submit，而是用jQuery的$.post把数据AJAX提交到一个VisitAppointmentServlet，返回JSON格式的成功/失败信息，页面局部刷新。这样做有一个明显的好处：表单校验可以在前端先跑一遍，只要后端再报一次错，错误信息也直接在页面上弹出，不用整页跳转，用户操作体验好了很多。你如果想在答辩时演示得更酷一点，完全可以把探访预约模块做成一个弹窗表单+AJAX提交，现场演示效果很棒。

后端返回JSON非常简单，用response.setContentType("application/json;charset=UTF-8")，然后out.write(jsonStr)。我一般用一个小小的工具方法，把result封装成{"code":200,"msg":"success"}，避免每个Servlet里都用StringBuilder拼字符串。Gson依赖很小，引入后就一行代码搞定转换。

5. 常见问题排查与答辩经验

5.1 启动与运行中的经典报错速查

开发过程中你会撞到很多报错，我列了一个速查表，每个都是JavaWeb项目里反复出现的经典问题，你可以直接把它当成debug手册用：

排查问题时我的习惯是"先断点后看日志，先打印后翻报错"。很多同学第一反应是去网上搜错误信息，但更高效的是在关键方法入口打上System.out.println()或者跟踪调试，看到数据在哪一步开始不符合预期，问题基本就定位一半了。

5.2 测试数据与系统演示准备

系统做完了，但演示效果可能很干瘪，很大原因是你没有任何测试数据。我建议你别吝啬，至少准备30条以上有层次的测试数据：老人分布在不同的年龄段、入住日期有跨度、健康记录每周至少两条、费用记录覆盖好几个月份，这样你演示分页、日期筛选、统计图表时才有素材。

如果想做得更专业，可以写一个DataInitializer工具类，每次部署后自动生成一批模拟数据。或者在SQL脚本里提前Insert，测试完清库重跑一遍也方便。我当时就是为了答辩演示专门写了个初始化数据的脚本，不断调参调整年龄段分布，最后出来的图表数据比较自然。

演示的时候有个小技巧：不要把页面所有角落都讲一遍，而是围绕一个完整业务场景讲。比如说"一位家属想为老人预约下周的探访"，你从前台提交预约，切换到管理员后台审批，再展示老人档案和费用清单。这比一个页面一个页面念功能要生动得多，评委也更关注你如何串联模块。

5.3 答辩时突出技术亮点的几个切入点

答辩环节你要想清楚，评委看重的不是你实现了多少功能，而是你是不是理解自己在做什么。我准备了几个可以主动讲出来的技术亮点，供你参考：

数据库事务确保跨表更新的一致性：比如"办理入住"和"退房结算"都放在一个数据库事务里，任何一步失败会回滚，确保数据不产生不一致状态。
使用Filter统一处理登录校验和权限控制，避免功能模块漏加安全判断。
SQL语句全部使用PreparedStatement参数化查询，防止SQL注入，这也是一个非常容易说得意想不到的安全层面的亮点。
使用Druid连接池而不是每次请求都新建连接，提升了系统并发情况下的资源利用效率。
密码不落明文，通过MD5加盐存储，体现安全设计意识。

这里再补充一个高级一点的思路：如果时间充裕、能力又够，可以考虑在"用药提醒"模块里引入一个简单的定时任务，例如用@Scheduled（Spring Boot环境）或者TimerTask（普通JavaWeb环境），每天固定时间扫描数据库里需要用药的老人记录，生成待处理任务。这种小的“智能”功能能迅速提升项目的层次，而且你讲起来也很有内容。

当然，答辩的时候不要为了炫技而讲太多自己没吃透的设计，不然老师顺着你的思路追问几个底层问题，你答不上来反而尴尬。我的经验是：准备三四个"真正自己实现并理解"的亮点，反复练习讲解，比背十一个照着网上抄的强。

5.4 这套系统后续还能怎么扩展

做完毕业设计不是终点。如果你还想把项目写在简历上，或者感觉还有余力，可以往这几个方向扩展：做一个Android/微信小程序端，让家属更方便预约探访；给健康数据接入一些智能硬件（比如手环），自动生成健康趋势；增加消息推送，用药提醒和探访审批结果通过微信公众号模板消息发给家属；权限控制升级为Spring Security或Shiro，做更细粒度的按钮级权限。

我个人在实际操作中最推荐扩一个方向：把老人生理数据做成曲线图模块，用定时任务自动抓取数据后通过ECharts在前端展示。这个功能既有技术含量，又非常贴切"智慧养老"这个主题，答辩时属于最能引起共鸣的模块。

6. 最后聊几句实在话

做这个项目最大的价值，不是你最后交上去那份代码能跑多顺畅，而是你借着它把JavaWeb的整条链路串起来了：前端页面怎么写、请求怎么到达后端、Servlet怎么调Service、Service怎么调DAO、SQL怎么查、结果怎么回显，每一步你都亲自动手过。我当年做完这个项目之后，再去看Spring Boot的自动配置，突然就通畅了——原来那些"约定优于配置"的东西，底层还是我们写过的这套流程，只是框架帮你代劳了细节。

最后再分享一个从调试习惯上受益最多的小技巧：每次写完一个模块，不要急着往下做，先把页面跑起来，用浏览器开发者工具把请求和响应都看一遍，确认数据链路通了再继续下一个模块。这个习惯维持到最后，整个项目基本不会积累大量"最后一口气跑不通"的隐患。相信我，JavaWeb项目最大的杀手不是技术难点，而是前期埋下的各种小坑没有及时清理，到最后堆在一起爆发。你慢一点，反而最快。