企业官网建设流程全解析

1. 这个系统的业务本质：到底在管理哪些"健康信息"

先别急着看代码。我接到过不少同学拿着"SSM养老院老人健康信息管理系统"这类题目来问，第一反应都是"这不就是个增删改查吗"。话是没错，但你要真把养老院的业务跑一遍，会发现这里的"健康信息"远比课设里常见的"学生信息管理"复杂得多。它不是一个单纯的CRUD堆砌，而是要把老人的基础档案、体检记录、慢病跟踪、用药提醒、护工分配、家属联动这几条线串起来。

简单画一下这个系统要覆盖的角色和流程：

• 管理员：维护全院床位、房间、护工排班，查看所有老人的健康数据汇总。
• 护工/护士：录入每日体温、血压、血糖等测量值，记录老人状态变化，执行用药计划。
• 医生/保健员：根据体检记录和日常测量数据，更新老人健康评估等级，给出照护建议。
• 家属：查看老人近期健康趋势（这个在很多课设里会被砍掉，属于加分项，我建议做进去）。

说白了，这个项目的核心难点不在于"会不会写SpringMVC的Controller"，而在于健康数据的建模颗粒度。老人不是学生，他的"健康信息"不是一条静态记录，而是一个持续变化的时间序列。你今天设计一个HealthInfo表只存身高体重，那基本就是个玩具；真正要落地，至少要拆成"档案表 + 体检表 + 每日测量表 + 慢病随访表"四层。

我见过不少同学的数据库设计，一张大宽表恨不得装下所有字段，结果后面做趋势图表、做时间范围查询时痛苦得不行。所以这篇文章我先把建模逻辑讲透，再给SSM落地细节和部署排坑经验，你看完可以直接照着做。

2. 技术选型的真实理由：为什么SSM在这个场景里依然够用

很多同学纠结：现在是不是该用Spring Boot了？SSM是不是过时了？我的态度很明确：课设、毕设、甚至小规模商用系统，SSM完全够用，而且它的"笨"恰恰是学习价值所在。

Spring Boot确实把配置简化到了极致，但代价是你对"容器怎么起、拦截器怎么生效、事务代理怎么织入"缺乏感知。SSM强制你手动组装Spring、SpringMVC、MyBatis三者的关系，一旦你把它们拼通了，后面学Spring Boot基本是一马平川。从面试角度讲，SSM也更容易被追问"SpringMVC的DispatcherServlet是在web.xml里怎么注册的""MyBatis的Mapper代理是怎么注入的"这类底层问题。

具体到这个养老院系统，我推荐的技术栈是这样：

为什么不用Spring Data JPA？因为健康信息系统的查询条件非常灵活——时间段、病种、评估等级、护工维度、楼栋房间维度，各种组合。MyBatis的<where>标签加动态SQL，写起来就是比JPA的Specification直观。你维护一个几百行SQL的老手都知道，这种业务用MyBatis最顺手。

另一个关键点是JDK和Tomcat的搭配。我用的是JDK 8 + Tomcat 8.5 + Maven 3.6.x。别小看这个组合，很多坑都出在版本错配。比如你装了JDK 17，Tomcat 8.5直接跑不起来，因为字节码版本不兼容。SSM是上古技术栈吗？不算上古，但确实对版本敏感。稳妥起见，这个组合是经过大量项目验证的，JDK 8+Tomcat 8.5不会出现莫名其妙的UnsupportedClassVersionError。

3. 数据库设计核心：健康档案怎么建模才是关键

我认为这个系统的成败，一半在数据库设计。前面提到过，要拆层。下面是我在实际项目里跑过的表结构，字段名基本可以直接用。

3.1 老人基础档案表——一张"主档"

字段除了常规的姓名、性别、身份证号、入住日期、房间号、床位号之外，务必加上这几项：

• emergency_contact紧急联系人
• emergency_phone紧急联系电话
• allergy_history过敏史
• health_level健康评估等级（1-4级，自理/半自理/不能自理/特殊护理）
• nurse_id负责护工ID，外键关联护工表
• status在院/退住/临时外出

这里的health_level建议用char(1)或tinyint，不要设计成varchar描述文本，否则后面做统计分组会写一堆CASE WHEN，难受得要死。

还有一个经验：身份证号一定做唯一索引。养老院会有老人重名的情况，但身份证号不会冲突。就算你们系统当前不做对接身份证读取，这个索引也能防止重复建档。

3.2 体检记录表——每次入住体检和定期体检存这里

字段设计要遵循"一检一录"的思路：

CREATE TABLE health_checkup ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, check_date DATE NOT NULL, height DECIMAL(5,2), weight DECIMAL(5,2), blood_pressure_high INT, blood_pressure_low INT, heart_rate INT, blood_sugar DECIMAL(4,1), vision_left DECIMAL(3,1), vision_right DECIMAL(3,1), bmi DECIMAL(4,1), conclusion VARCHAR(500), doctor_id BIGINT, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_elder_date (elder_id, check_date) );

注意这个联合索引(elder_id, check_date)，它是整个系统查询频率最高的路径——"查某位老人最近几次体检"。没有这个索引，数据量一旦到几万条，查询会明显变慢。

BMI字段建议在Service层计算后写入，而不是每次查询时实时算。这类派生数据落库，效率更高，也方便直接做SQL统计。

3.3 每日测量记录表——高频数据的存储策略

护工每天要录入血压、体温、血糖这些测量值。这张表是系统数据量最大、增长最快的表，建模时给自己留好扩展余地：

CREATE TABLE daily_measure ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, measure_date DATE NOT NULL, measure_time TIME, temperature DECIMAL(4,1), blood_pressure_high INT, blood_pressure_low INT, blood_sugar DECIMAL(4,1), spo2 INT, pain_level TINYINT, remark VARCHAR(200), recorder_id BIGINT, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, KEY idx_elder_date_time (elder_id, measure_date, measure_time) );

pain_level疼痛等级在课设里很少见，但在真实养老场景里是个重要指标。做这类系统时，我建议你要么不做，要做就做全套——把医学场景里真正会采集的字段放上去，评审老师看到会眼睛一亮，因为这说明你调研过真实业务，而不是对着别人的表结构抄。

3.4 慢病管理表——长期照护的核心载体

养老院老人最常见的慢病是高血压、糖尿病、冠心病。慢病表可以这样设计：

CREATE TABLE chronic_disease ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL, disease_name VARCHAR(50), diagnosed_date DATE, current_medication VARCHAR(100), medication_frequency VARCHAR(50), last_followup_date DATE, next_followup_date DATE, status TINYINT DEFAULT 1, -- 1管理中 0已缓解 KEY idx_elder_next_followup (elder_id, next_followup_date) );

这个next_followup_date字段是实现"到期提醒"功能的钥匙。你可以写一个Spring定时任务，每天扫一遍这个字段，把未来3天内需要随访的老人推送给护士端。这个功能虽然做起来简单，但非常贴合业务，也容易在答辩时展示。

3.5 五张表已经打底，剩下的按需扩展

除了上面四张核心表，一般还会加：

• sys_user：系统用户表，区分管理员、医生、护士、家属角色
• nurse_info：护工表
• room_info：房间床位表
• leave_record：出入院/请假记录
• medication_record：用药执行记录（强调"执行"，不是"计划"）

关于要不要建medication_plan计划表，我的建议是：课设阶段可以把用药计划和执行记录合并成一张表，因为大部分同学的时间只够做一个"增删改查+简单状态流转"。如果做成两表联动，意味着还要处理"计划作废、漏服补录、按时状态判断"这些细节，工作量大一截。你要评估自己的进度再决定。

4. SSM核心代码怎么组织：分层计划与关键实现

接下来是代码结构。我见过最崩溃的项目是包路径乱成一团，Controller里写SQL，Service返回Map。这个项目不算复杂，但你要是前期不分层，后面扩展功能时会追悔莫及。

4.1 包结构建议

com.yanglaoyuan ├── controller // 表现层，接收请求参数，返回视图或JSON ├── service // 业务接口 │ └── impl // 业务实现 ├── dao // MyBatis的Mapper接口 ├── entity // 实体类 ├── dto // 页面传输对象（用于封装多表联查结果） ├── common // 统一返回结果、异常处理 ├── config // Spring和SpringMVC配置 └── task // 定时任务

dto包是很多同学不知道用的。比如前端要展示"老人档案+负责护工姓名+所属房间号"，你用一个ElderVO对象来接收@Select里JOIN查询的结果，而不是返回一个Map<String,Object>。Map用多了，代码审查时一眼就会被看穿是新手。

4.2 一张图说清SpringMVC的请求流转

老人列表这个功能跑一次请求要经过的环节：

1. 浏览器发GET /elder/list?pageNum=1&pageSize=10请求。
2. DispatcherServlet拦截所有.do或/路径（由web.xml配置决定），找到@RequestMapping("/elder")的处理器。
3. HandlerMapping根据list后缀匹配到ElderController.list()方法。
4. 方法里调用ElderService.pageQuery()，Service层开启事务（如果涉及写操作）。
5. Service调用ElderDao.selectByCondition()，MyBatis通过动态SQL拼装查询条件。
6. 结果封装成PageInfo对象，返回逻辑视图名elder/list。
7. 视图解析器InternalResourceViewResolver拼上前缀/WEB-INF/views/和后缀.jsp，渲染出HTML。
8. 浏览器收到完整页面。

你调试时如果发现页面404或者样式加载不出来，90%的问题出在第7步的路径拼接上，这是SSM项目最高频的坑之一。后面部署章节我会专门讲。

4.3 一个完整的Controller示例：体检记录按时间段查询

@Controller @RequestMapping("/checkup") public class CheckupController { @Autowired private CheckupService checkupService; @GetMapping("/list") public String list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) Long elderId, @RequestParam(required = false) String startDate, @RequestParam(required = false) String endDate, Model model) { PageHelper.startPage(pageNum, pageSize); List<ElderCheckupVO> list = checkupService.queryByCondition(elderId, startDate, endDate); PageInfo<ElderCheckupVO> pageInfo = new PageInfo<>(list); model.addAttribute("pageInfo", pageInfo); model.addAttribute("elderId", elderId); model.addAttribute("startDate", startDate); model.addAttribute("endDate", endDate); return "checkup/list"; } }

这里有几处值得说：

• @RequestParam(required = false)处理可选参数，前端不传时不会报400错误。
• PageHelper.startPage()后面必须紧跟第一条SQL查询语句，中间不能有其他数据库操作。很多人踩过这个坑，因为PageHelper的拦截器是基于线程上下文的，一旦你中间执行了别的查询，分页就串了。
• 返回的是逻辑视图名，不是JSON。因为这是传统JSP页面渲染模式，不是前后端分离。

4.4 Service层的关键逻辑：事务位置和业务校验

健康信息系统的写入场景很多，比如护工录入每日测量值、医生更新体检结论。这类操作必须加事务。Spring的声明式事务注解@Transactional要放在Service实现类方法上，不是Controller方法上，也不是Dao接口上。为什么？

因为Spring AOP的代理机制基于接口代理，@Transactional放在Impl类的方法上时，只有通过Spring容器注入的Service代理对象调用该方法，事务才生效。你如果直接在Controller里注入Dao然后随意写库，一是没有数据库连接的统一管理，二是一旦中途异常，前面已经执行的更新操作不会回滚。

给你看一个典型的"事务边界"业务——录入体检记录时同时更新老人的健康等级：

@Transactional(rollbackFor = Exception.class) public void addCheckup(HealthCheckup checkup, int newHealthLevel) { checkupDao.insert(checkup); elderDao.updateHealthLevel(checkup.getElderId(), newHealthLevel); // 如果上面两步中间抛异常，事务回滚，体检记录和健康等级都不会写入 }

rollbackFor = Exception.class是另一个高频知识点。默认情况下@Transactional只在遇到RuntimeException时才回滚，但咱们项目里可能抛出自定义的BusinessException，而它不继承RuntimeException的话，事务就不回滚。所以统一写上rollbackFor = Exception.class是最省心的做法。

4.5 MyBatis动态SQL：健康查询的核心武器

MyBatis的<where>标签非常适合健康系统的多条件组合查询。体检记录按老人、按日期范围、按病种、按关键字段是否有值来过滤，效果很好：

<select id="queryByCondition" resultType="com.yanglaoyuan.dto.ElderCheckupVO"> SELECT c.*, e.name AS elder_name, e.room_no, e.bed_no FROM health_checkup c LEFT JOIN elder_info e ON c.elder_id = e.id <where> <if test="elderId != null"> AND c.elder_id = #{elderId} </if> <if test="startDate != null and startDate != ''"> AND c.check_date &gt;= #{startDate} </if> <if test="endDate != null and endDate != ''"> AND c.check_date &lt;= #{endDate} </if> </where> ORDER BY c.check_date DESC </select>

注意>和<——在XML里直接写>和<会报错，因为XML解析器会把它们当作标签符号。这是新手的经典报错点。

5. 三个高频踩坑点：从404到事务不生效

这部分是我最想跟你分享的实操经验。每个坑我都亲眼见过至少两位数的同学踩进去。

5.1 坑一：SpringMVC路径配置导致的404和样式丢失

项目启动Tomcat后访问http://localhost:8080，菜单都出来了，但一点"老人列表"就404，或者页面能打开但CSS、JS全部失效。

问题根源基本在web.xml的servlet-mapping配置：

<servlet-mapping> <servlet-name>dispatcher</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

如果你配的是<url-pattern>/*</url-pattern>，那么连JSP的内部转发路径也会被DispatcherServlet拦截，然后视图解析器试图找到/WEB-INF/views/elder/list这个"请求路径"，结果404。改成/之后，JSP渲染由容器处理，动态请求才走SpringMVC，这是最经典的配置。

至于CSS失效，通常是静态资源被拦截了。你要在SpringMVC配置文件里加上：

<mvc:resources location="/static/" mapping="/static/**"/>

同时前端页面用${pageContext.request.contextPath}/static/css/bootstrap.css这样带上下文路径的方式引用资源，直接写/static/css/bootstrap.css在部署到非根路径时会挂。

5.2 坑二：MyBatis的Mapper接口和XML映射找不到

这一条也几乎是每个SSM项目都逃不过的。报错通常是BindingException: Invalid bound statement (not found)。造成这个问题的原因有三个：

• XML文件没放进target目录：Maven项目约定把mapper XML放src/main/resources/mapper下，但如果你放到了src/main/java/dao目录下，且没有在pom.xml里配置resource打包，编译后XML不会出现在classes里。排查方法很简单，去target目录看一眼有没有XML。
• MapperScannerConfigurer扫描路径错了：basePackage要指向DAO接口所在的包，不能指向整个项目根包，否则全部的注解都被扫描，会产生代理冲突。
• namespace和接口全限定名不一致：MyBatis通过命名空间来匹配代理接口，所以<mapper namespace="com.yanglaoyuan.dao.ElderDao">必须和接口的完整包名一致。

5.3 坑三：@Transactional没生效，写库一半成功一半失败

症状是：新增体检记录成功，但健康等级更新失败，而且数据库里第一条记录还真留下了。这就说明事务没有覆盖这两次操作。

常见原因有三个：

• @Transactional放在了Controller里。Spring的AOP默认只拦截Spring容器管理的bean，Controller虽然也是bean，但事务代理的织入顺序会出问题，而且分层思想也不允许Controller直接写业务事务。
• Service被new了出来而不是@Autowired注入。你自己new的对象不经过Spring容器，自然没有代理。
• 同一个类里方法自调用。比如saveElder()方法内部直接调用了本类的saveCheckup()方法，事务不会生效。因为这是绕过代理直接调用了目标对象方法。解决办法是：要么把第二个方法放到另一个Service里注入过来，要么像很多项目一样，通过ApplicationContext动态获取代理对象（不推荐，但确实能解燃眉之急）。

5.4 坑四：日期时间格式传参报400

前端用datetime-local输入框提交"2024-05-18T10:30"，后端用Date接收，直接400。SpringMVC默认无法自动转换这种带T的格式。

解决方案有两种，我推荐第二种：

方案一：前端传字符串，后端用String接收，再手动LocalDateTime.parse()。 方案二：在Controller类里加@InitBinder：

@InitBinder public void initBinder(WebDataBinder binder) { binder.registerCustomEditor(Date.class, new CustomDateEditor(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm"), true)); }

统一格式，省得每处手动解析。如果前端传的是"yyyy-MM-dd"，就对应改格式串。这个就是老手和新手的区别——新手在Service层处处打补丁，老手在绑定阶段一次性解决。

6. 部署环境配置：从本地跑通到服务器部署的完整链路

6.1 开发环境清单

先列一套我验证过无数次的版本组合，你照着装就行：

Maven的pom.xml依赖里，如果用到Spring 5.x，建议版本组合是：spring-webmvc 5.3.x+mybatis 3.5.x+mybatis-spring 2.0.x+pagehelper 5.3.x。这几个版本是社区里验证过的稳定搭配，互相没有依赖冲突。

6.2 数据库初始化步骤

拿到项目的health_care.sql文件后，在MySQL命令行或者Navicat里执行：

1. 创建数据库：CREATE DATABASE health_care DEFAULT CHARACTER SET utf8mb4;
2. 选用数据库：USE health_care;
3. 执行SQL脚本：SOURCE /你的路径/health_care.sql;

如果脚本里包含中文注释，执行时报错乱码，多半是客户端和数据库的字符集不一致。执行前先设置一下：SET NAMES utf8mb4;

最后一步很关键：把db.properties里的数据库账号密码改成你自己的，尤其是密码。很多同学拿到项目后忘了改，报Access denied for user 'root'@'localhost'，一脸懵。我当时第一次跑论文项目的源码时也犯过这个错，排查了半小时才发现是密码问题。

6.3 用IDEA跑起来的顺序

IDEA导入Maven项目后，正确的运行步骤是：

1. 配置Tomcat：Run → Edit Configurations → 点"+ → Tomcat Server → Local"。
2. 在"Deployment"选项卡里，点"+ → Artifact"，选择xxx:war exploded，Application context填/。
3. 确保"Server"选项卡里的URL是http://localhost:8080/。
4. 点运行。

关于war exploded和war的区别：前者是目录形式，改了代码热部署快，开发用这个；后者是压缩包，部署到Linux服务器才用。开发时不用exploded，你会每次修改都要重新打包，非常痛苦。

6.4 部署到Windows/Linux服务器的差异点

如果要把项目部署到生产环境或给评委演示，通常不再依赖IDEA，而是把项目打包成war丢到Tomcat的webapps目录：

mvn clean package -DskipTests

打包完在target目录里找到xxx.war，丢到Tomcat的webapps下，启动startup.bat（Windows）或startup.sh（Linux）。

这里有个最容易忽略的坑：JDK版本要和本机一致。你在IDEA里用JDK 8编译，服务器的Tomcat如果运行在JDK 11上，一般问题不大；但如果你本机用的JDK 17编译，服务器是JDK 8，直接启动报错。稳妥做法是服务器也装JDK 8，并且catalina.sh或setclasspath.bat里明确指定JAVA_HOME。

数据库连接池的配置也有讲究。本地用localhost:3306没问题，部署到服务器后如果数据库和应用在同一台机，可以继续用localhost；如果分开，记得把jdbc.url改成内网IP，并检查服务器防火墙是否放行3306端口。

7. 论文文档怎么写才不虚：围绕"完整系统"讲出深度

标题里提到"带论文文档1万字以上"，这个点我得单独提醒你。很多同学以为论文就是把数据库建表语句抄一遍，再把界面截图贴上去。大错特错。论文的核心是向评审证明你解决了一个真实问题，而"健康信息管理"恰恰是要点很多的选题。

建议的论文结构：

• 绪论：养老院健康管理的背景，要引用一两条实际政策或行业协会数据，增强可信度。
• 需求分析：画用例图，写清楚老人、护工、医生、家属、管理员五类角色的权限和数据边界。
• 系统设计：重点写数据库设计的第三范式分析，你把我的四层健康数据模型展开讲，说明为什么不能合并成一张表，理由就是更新异常和冗余。
• 核心模块实现：选两到三个功能重点描述，比如每日测量数据录入、慢病到期提醒、健康趋势报表。每个功能写清楚流程和关键代码。
• 系统测试：不要只写"功能正常"，要写测试用例表格，包括输入、预期输出、实际输出、是否通过。

论文怎么凑够1万字？不是硬灌水，而是把每个环节讲深。比如数据库设计，光E-R图、表结构说明、字段设计理由就至少能写2500字。这不是水，是这类系统设计的必要内容，只是大部分人不知道从哪个角度扩展。

还有个小技巧：把ECharts健康趋势图作为一个独立章节来写，包含曲线图接口返回的数据格式、前端如何用Ajax拉取数据、以及为什么选择折线图展示血糖趋势而非柱状图。这种细节会让论文的深度明显上一个档次。

8. 从0到1跑通这个项目的完整时间线

最后分享一个我从拿到需求到跑通系统的时间安排，你可以照着排，避免前期磨叽太久：

第1-2天：环境搭建和需求梳理

• 装好JDK、Maven、Tomcat、MySQL、IDEA，全部版本统一。
• 确认系统角色和功能清单，画简单的用例图。
• 这一步不需要写代码，把脑中的功能边界定清楚。

第3-4天：数据库建表和初始化

• 按上面的表结构建库建表，插入测试数据（20个老人、5个护工、3个医生）。
• 测试数据很重要，别用空表开发，否则后面调试列表页啥都看不到。
• 顺手写好db.properties，验证数据库连接。

第5-8天：后端核心代码

• 按"老人档案管理"先做一个完整闭环：Controller → Service → Dao → JSP页面。
• 跑通这个闭环后，剩下的模块都是类似套路，速度快很多。
• 期间一定要用PageHelper把分页加上，这是课设的必备功能，晚做不如早做。

第9-12天：扩展功能和可视化

• 加上体检记录录入、每日测量录入、慢病随访提醒。
• 引入ECharts画老人健康趋势曲线，这是答辩的高光环节。

第13-14天：测试和论文整理

• 把异常场景测一遍：空值提交、日期越界、非法ID访问。
• 写测试用例表格，截图保留完整证据链。
• 对照论文提纲往里填内容，代码和截图直接引用。

如果遇到卡壳，有个经验值得记住：先把列表页和增删改查跑通，再考虑任何花哨功能。不要一上来就研究ECharts怎么画图、Excel怎么导出、权限怎么精细控制，那些都是主流程通了之后的锦上添花。很多同学截止前两天还在调数据库连接，就是因为没有按这个顺序推进。

最后说两句实在话

我从接触SSM到用它做完整项目，最大的体会就是：框架只是工具，业务建模和排错能力才是你真正带走的东西。这个养老院健康管理系统题目的好处在于业务足够真实，你做完它，能理解"一个管理系统是怎么从无到有生长出来的"，而不只是会写几个注解。

如果你在部署时遇到"项目启动Tomcat，浏览器打开空白""MyBatis报Could not find result map""页面跳转路径404"这类问题，优先去检查控制台第一行异常堆栈，定位到具体类名再决定处理方案。不要一次改三个地方，你会分不清到底是哪处生效。一次改一处，启动一次，看一次日志，这是最笨但最有效的调试节奏。

希望这篇文章能把你要走的路趟平，项目跑通的那一刻应该会有种"原来不过如此但过程值了"的感觉。