SSM病人跟踪治疗信息管理系统：从需求分析到部署答辩完整指南-代码聚汇网

我先扫描了一遍这个标题：SSM病人跟踪治疗信息管理系统-计算机毕业设计源码38164。做毕业设计的同学看到这种标题应该很熟悉，特别是选了Java Web方向、又不想一上来就追Spring Boot的人，“SSM三件套”几乎是绕不开的坎。但说实话，每年交上来的病人管理类系统太多了，大多数都长一个样——一个用户表、一个病人表、几个增删改查页面、再配一张统计图，就完事了。这种作品拿去答辩，老师问两句“你这个‘跟踪治疗’到底是怎么跟踪的”“状态是怎么流转的”，基本就卡壳。

这篇文章我从头到尾讲一遍，怎么把“病人跟踪治疗”这个题目从需求层面拆开，再落到SSM的代码和表结构上。不是给你贴一堆别人写好的源码就算完，而是告诉你为什么这么设计、每一步在解决什么问题，这样你拿到的才是一个能讲清楚、能应对追问的毕业设计。

1. 这个系统到底在解决什么问题：先别急着写代码

很多同学拿到题目第一反应是“不就是病人信息的CRUD吗”，这就是典型的还没做需求分析就急着动手。实际上“跟踪治疗”这四个字才是整个系统的核心，不是“病人管理”，也不是“信息管理”，而是“跟踪”和“治疗”两个动作。

1.1 从“一个CRUD系统”到“一个业务闭环”

如果你只是做一个病人信息登记表，那确实就是一个简单的增删改查。但“病人跟踪治疗”意味着系统要覆盖病人从入院、诊断、制定治疗计划、执行治疗、记录反应，到后续复诊跟踪的完整过程。它不是静态地存一份数据，而是要记录一条条随时间推进的治疗事件，让医生能随时看到“这个病人治到哪一步了”。

举个例子，一个高血压病人住进医院，医生给他开了药，定了两周的治疗方案。护士每天记录血压数据，医生根据数据调整药量。两周后病人出院，系统还要提醒他一个月后来复查。这一整套过程，如果只靠几张表做增删改查，根本撑不住。你需要的是：

通过治疗计划把“诊断”和“执行”串起来；
通过治疗记录把每天、每次的具体操作存下来；
通过状态字段控制治疗计划的推进，比如“治疗中”“已暂停”“已完成”；
通过提醒机制把“跟踪”这件事从被动查询变成主动推送。

所以这个系统的本质，是一个带状态流转的业务闭环系统，不是信息登记表。

1.2 角色划分与权限边界

再往细了拆解需求时，第一个要搞清楚的就是谁在用这个系统。医院场景下，至少有三个角色：管理员、医生、护士，有时候还要考虑病人自己查看报告，但毕业设计里建议把规模控制在三个角色以内，否则权限逻辑会把你拖垮。

管理员：维护科室、医生账号、系统基础数据，不参与具体治疗过程；
医生：负责诊断、制定治疗计划、开医嘱、查看病人的完整治疗历史；
护士：负责执行治疗计划、录入日常护理记录和生命体征数据。

这三个角色的权限差异非常明确。医生能写诊断和计划，护士只能记录执行情况，不能修改诊断内容；管理员能看到全部数据但一般只用于统计和维护。用SSM做权限控制，最简单可靠的方式就是Spring MVC的拦截器加一个角色字段判断，不需要引入Spring Security那套重家伙——毕业设计里把拦截器写明白，反而更能体现你对访问控制的理解。

1.3 核心业务流程推演

我建议你在写代码之前，先把下面这条主流程画在纸上，后续所有表结构和接口都围绕它来展开：

病人登记建档 → 医生接诊并作出诊断 → 医生制定治疗计划 → 护士按计划执行并录入治疗记录 → 医生根据记录调整计划 → 达到治疗目标后结束计划 → 生成复诊提醒 → 病人按期复诊并新增诊断记录

这条流程里，最核心的两个状态节点是“治疗计划”和“治疗记录”。计划是预设的、指导性的，记录是实际发生的、反馈性的。没有计划的系统是台账，没有记录的系统是空壳，两者必须同时存在。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型：为什么毕业设计仍然值得选SSM，而不是直接上Spring Boot

我知道现在网上很多声音说SSM过时了，毕业设计应该用Spring Boot。这个说法有一定道理，但对于这个题目来说，SSM依然是一个稳妥且能拿高分的选择。

2.1 SSM与Spring Boot的核心差异

Spring Boot本质上是对Spring家族的一次封装和自动化配置，它把很多原来需要手写XML配置和注解的东西简化掉了。但SSM（Spring + SpringMVC + MyBatis）让你能够看到这些框架底层协作的完整过程。你写SpringMVC的处理器映射、写MyBatis的Mapper接口、写Spring的Bean装配，每一步都清清楚楚。

用Spring Boot做这个系统，可能三天就能把骨架跑起来；用SSM做，前期配置会花掉你两三天，但这两三天的价值在于，答辩时老师问“Spring和SpringMVC是什么关系”“MyBatis和JDBC有什么区别”“Bean是怎么管理的”，你都能用自己的项目经历回答出来，而不是背概念。这套系统恰好是一个中型业务系统，复杂度足够体现出SSM分层的好处，又不至于像Spring Boot那样把关键细节都“藏”起来。

2.2 分层架构中每一层的职责边界

SSM的标准分层是Controller、Service、Dao（Mapper），再加上实体层和工具层。我在做这个项目时，对每一层有一条规矩：

Controller：只负责接收请求、校验参数格式、调用Service、把结果封装成统一的JSON返回给前端，绝对不允许写业务逻辑；
Service：负责业务规则、事务管理、状态流转的判定。比如“当前计划已经是完成状态，不能再添加治疗记录”这条规则，写在Service里，而不是写在Controller或Mapper里；
Dao（Mapper）：只负责SQL操作，每个方法对应一个具体的数据库操作，逻辑尽量单一，不要写多条SQL拼在一个方法里的复杂逻辑。

严格按照这个边界来写，最大的好处是后期排查问题时，你只需要根据报错信息判断是哪一层的问题。比如页面报了500错误，日志里写的是SQL语法异常，那直接去Mapper里找；如果报的是业务逻辑错误，比如状态不允许操作，那就去Service里找，不用整个项目到处翻。

2.3 项目结构的物理组织

我的建议是按业务模块分包，而不是按技术层分包。很多人习惯建一个controller包把所有Controller都扔进去，项目小的时候无所谓，但这个系统的业务模块较多，按业务分包会更清晰。推荐结构如下：

code复制com.hospital.treatment
├── common          // 通用类：结果封装、常量、工具类
├── config          // 配置类：拦截器、跨域、静态资源映射
├── controller      // 控制层：按模块拆分
│   ├── admin
│   ├── doctor
│   └── nurse
├── service         // 业务层：接口 + 实现
│   ├── impl
├── dao             // MyBatis Mapper接口
├── entity          // 实体类
├── interceptor     // 登录与权限拦截器
└── vo              // 视图对象：专门封装给前端的数据

这里有个小技巧：给前端返回的数据，不要直接把entity实体类返回出去。比如病人实体里有身份证号、联系方式，但列表页只需要姓名和床位号，这时候定义VO来裁剪字段。一方面减少不必要的数据传输量，另一方面也防止敏感信息直接暴露到前端。答辩时提到这一点，会显得你考虑问题很周全。

3. 数据库建模：病人跟踪治疗的关键在于状态流转

数据库设计是这个系统最见功夫的地方，也是答辩时老师重点考察的部分。

3.1 核心实体识别

我梳理下来，这个系统至少需要这几张核心表：

用户表（sys_user）：系统登录账号，包含医生和护士、管理员三类角色；
病人表（patient）：基本信息，姓名、性别、年龄、联系方式、紧急联系人等；
诊断记录表（diagnosis_record）：医生对病人的每次诊断结论，包括诊断时间、诊断结果、病情描述；
治疗计划表（treatment_plan）：一次完整的治疗方案，关联病人和诊断记录，有开始时间、结束时间、状态；
治疗记录表（treatment_record）：针对某个治疗计划的实际执行记录，比如某次用药、某次物理治疗、某次检查；
医嘱表（medical_advice）：医生下达的处方或护理要求，可以挂在计划下或者诊断下；
复诊提醒表（follow_up_reminder）：记录需要复诊的信息和提醒时间。

有些表是可能会被省略的，比如医嘱表可以放到治疗记录里，但如果你的系统想多做一点亮点，独立成表会更好。复诊提醒表则是“跟踪”这个含义的落地核心，一定不能少。

3.2 关键表结构设计

具体建表时，最重要的两个表是治疗计划表和治疗记录表，我把核心字段列出来供你参考。

治疗计划表的关键字段：

sql复制CREATE TABLE treatment_plan (
    id INT PRIMARY KEY AUTO_INCREMENT,
    patient_id INT NOT NULL COMMENT '病人ID',
    diagnosis_id INT COMMENT '关联诊断记录ID',
    plan_name VARCHAR(100) NOT NULL COMMENT '治疗计划名称',
    plan_type VARCHAR(50) COMMENT '治疗类型：药物/手术/物理/综合',
    start_date DATE NOT NULL COMMENT '计划开始日期',
    end_date DATE COMMENT '计划结束日期',
    plan_status VARCHAR(20) DEFAULT 'TREATING' COMMENT '状态：TREATING治疗中/PAUSED已暂停/COMPLETED已完成/TERMINATED已终止',
    doctor_id INT COMMENT '制定计划的医生ID',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_patient (patient_id),
    INDEX idx_status (plan_status)
) COMMENT '治疗计划表';

治疗记录表的关键字段：

sql复制CREATE TABLE treatment_record (
    id INT PRIMARY KEY AUTO_INCREMENT,
    plan_id INT NOT NULL COMMENT '所属治疗计划ID',
    patient_id INT NOT NULL COMMENT '病人ID',
    record_type VARCHAR(50) COMMENT '记录类型：用药/检查/护理/手术',
    content TEXT COMMENT '治疗内容详细描述',
    result VARCHAR(200) COMMENT '治疗结果或反应',
    operator_id INT COMMENT '执行人（护士/医生）ID',
    record_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '执行时间',
    next_follow_up_date DATE COMMENT '下次复诊/跟踪日期',
    INDEX idx_plan (plan_id),
    INDEX idx_patient_time (patient_id, record_time)
) COMMENT '治疗记录表';

这里要说一下为什么plan_status字段这么重要。在业务逻辑里，状态的判断会贯穿整个系统——添加治疗记录时，要先检查计划状态是否为“治疗中”；调整计划时，要判断是否已经开始执行；删除计划时，要判断是否已有治疗记录。这些判断都依赖这个字段。为了让代码逻辑更加清晰，建议用字符串常量来定义状态值，不要用魔法数字，比如在Java里定义一个PlanStatus常量类：

java复制public class PlanStatus {
    public static final String TREATING = "TREATING";
    public static final String PAUSED = "PAUSED";
    public static final String COMPLETED = "COMPLETED";
    public static final String TERMINATED = "TERMINATED";
}

3.3 状态流转设计：系统的灵魂所在

光有一个状态字段还不够，你要定义清楚状态之间允许怎么跳转。这套规则往往写在Service层里，是毕业设计展示业务理解深度的关键部分。

我把这个系统的状态跳转规则定义如下：

TREATING（治疗中）→ PAUSED（已暂停）：医生主动暂停，比如出现不良反应需要评估；
PAUSED（已暂停）→ TREATING（治疗中）：评估完成后继续治疗；
TREATING（治疗中）→ COMPLETED（已完成）：治疗目标达成，正常结束；
TREATING（治疗中）→ TERMINATED（已终止）：因突发原因终止治疗，比如病人转院或放弃治疗；
COMPLETED和TERMINATED都是终态，不能再跳转到其他状态。

为什么我要在这个系统里花大量篇幅讲状态流转？因为“跟踪治疗”本质上就是状态流转的过程。你去看那些做得一般的毕业设计，治疗计划表里根本没有状态字段，或者有状态字段但代码里只做查询展示，从不做状态约束。这样的系统看起来功能都有，但业务上是说不通的。老师问你“如果一个计划已经完成了，护士还能往里面加治疗记录吗”，你说“能”或者支支吾吾，那基本就露馅了。所以这些规则一定要写死在Service层中。

我给出一段典型的状态流转校验代码，你可以参考这个风格：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public void updatePlanStatus(Integer planId, String targetStatus) {
    TreatmentPlan plan = planMapper.selectById(planId);
    if (plan == null) {
        throw new BusinessException("治疗计划不存在");
    }
    String currentStatus = plan.getPlanStatus();
    // 定义可选流转：当前状态 -> 允许的目标状态集合
    Map<String, List<String>> validTransitions = new HashMap<>();
    validTransitions.put(PlanStatus.TREATING, Arrays.asList(PlanStatus.PAUSED, PlanStatus.COMPLETED, PlanStatus.TERMINATED));
    validTransitions.put(PlanStatus.PAUSED, Collections.singletonList(PlanStatus.TREATING));
    // COMPLETED、TERMINATED为终态，不在map中，自然无法流转

    List<String> allowedTargets = validTransitions.get(currentStatus);
    if (allowedTargets == null || !allowedTargets.contains(targetStatus)) {
        throw new BusinessException("不能从" + currentStatus + "状态流转到" + targetStatus + "状态");
    }
    // 还需要处理业务校验，比如从TREATING到COMPLETED必须先确认所有治疗记录已录入
    planMapper.updateStatus(planId, targetStatus);
}

注意我把@Transactional注解加上了。这涉及到另一个重要的点：事务边界。

3.4 事务边界：不是加个注解就完事

在这个系统里，事务的使用场景非常多。创建治疗计划时，同时要初始化一条“计划创建”的治疗记录，这两个操作必须在一个事务里，要么都成功，要么都失败。护士录入一条治疗记录时，如果计划的plan_status是PAUSED或COMPLETED，要抛异常回滚。

Spring声明式事务用起来很简单，就是加@Transactional。但你要理解它的默认行为：RuntimeException会触发回滚，受检异常Exception不会触发回滚。如果我在Service里抛的是一个受检异常，事务是不会回滚的，数据就可能处于不一致状态。

所以我强烈建议你在项目中自定义一个BusinessException，让它继承RuntimeException。这样所有业务校验失败都抛业务异常，事务就能正确回滚。代码如下：

java复制public class BusinessException extends RuntimeException {
    private Integer code = 500;
    public BusinessException(String message) {
        super(message);
    }
    public BusinessException(String message, Integer code) {
        super(message);
        this.code = code;
    }
    public Integer getCode() {
        return code;
    }
}

然后在Service层统一抛这个异常，Controller层用@ExceptionHandler统一捕获，返回一个标准JSON格式的错误信息给前端。这样整个系统的异常处理链路就完整了。

4. 核心功能代码落地：从Mapper到Controller的完整链路

框架结构搭好了，表建好了，接下来就是写核心业务代码。我挑三个最有代表性的功能来说，分别是：动态查询病人列表、创建治疗计划的业务逻辑、以及录入治疗记录时的状态校验。

4.1 MyBatis中动态SQL的典型使用场景

在病人管理模块中，往往需要根据姓名、科室、入院时间、当前状态等多个条件组合查询。用MyBatis的<where>加<if>标签做动态SQL是标准做法。

病人表的查询Mapper，我的做法是这样：

xml复制<select id="selectByCondition" resultType="com.hospital.treatment.entity.Patient">
    SELECT * FROM patient
    <where>
        <if test="name != null and name != ''">
            AND name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="department != null and department != ''">
            AND department = #{department}
        </if>
        <if test="status != null and status != ''">
            AND status = #{status}
        </if>
        <if test="admissionStart != null">
            AND admission_date &gt;= #{admissionStart}
        </if>
        <if test="admissionEnd != null">
            AND admission_date &lt;= #{admissionEnd}
        </if>
    </where>
    ORDER BY create_time DESC
</select>

这里有一个关键细节：<if>这种动态SQL的拼接，在索引使用上有时会有问题。如果查询条件很多且都需要组合，比如病人列表页有姓名、科室、状态、入院时间四个筛选条件，那数据库层面如果一张表只有几万条数据，问题不大；但如果是几十万条数据，你就要考虑给筛选条件字段建联合索引。毕业设计阶段数据量小，动态SQL完全够用，但如果你希望在答辩时体现优化意识，可以补充说明这个索引策略，比如在department + status + admission_date上建联合索引，会是一个很好的加分项。

4.2 Service层：创建治疗计划的完整业务

创建治疗计划是这个系统里最核心的写操作之一。它不仅要插入计划本身，还要做一堆关联操作。我用伪代码展开完整逻辑：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public TreatmentPlan createPlan(TreatmentPlanCreateRequest request) {
    // 1. 参数校验：病人必须存在且未出院
    Patient patient = patientMapper.selectById(request.getPatientId());
    if (patient == null) {
        throw new BusinessException("病人不存在");
    }
    if ("DISCHARGED".equals(patient.getStatus())) {
        throw new BusinessException("病人已出院，不能创建治疗计划");
    }

    // 2. 校验当前是否有未结束的治疗计划（简单版业务约束）
    int treatingCount = planMapper.countByPatientAndStatus(request.getPatientId(), PlanStatus.TREATING);
    if (treatingCount > 0) {
        throw new BusinessException("该病人已有进行中的治疗计划");
    }

    // 3. 创建计划实体
    TreatmentPlan plan = new TreatmentPlan();
    BeanUtils.copyProperties(request, plan);
    plan.setPlanStatus(PlanStatus.TREATING);
    plan.setCreateTime(new Date());
    planMapper.insert(plan);

    // 4. 初始化一条治疗记录：记录计划创建事件
    TreatmentRecord initRecord = new TreatmentRecord();
    initRecord.setPlanId(plan.getId());
    initRecord.setPatientId(request.getPatientId());
    initRecord.setRecordType("INIT");
    initRecord.setContent("治疗计划创建，治疗开始");
    initRecord.setOperatorId(request.getDoctorId());
    recordMapper.insert(initRecord);

    return plan;
}

注意第4步，很多同学会忽略“系统日志”或者“初始化事件”这一步。但在这个业务场景里，它很有价值——因为它让治疗记录表有了一个有起始意义的记录，后续查询某个病人的完整治疗时间线时，这条记录就是起点。真正做医疗系统的专业人员，一定会考虑这种“审计性”的设计。放到毕业设计里，这就是所谓的业务完整性。

4.3 Controller层：参数校验与统一封装

Controller层要做的事情，一是接收前端参数，二是用@Valid做参数校验，三是调用Service处理，四是把结果封装成统一格式返回。

我习惯用一个Result类来统一返回结构：

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    // 省略getter/setter
    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("success");
        result.setData(data);
        return result;
    }
    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

Controller层的一个示例方法：

java复制@RestController
@RequestMapping("/api/plan")
public class TreatmentPlanController {

    @Autowired
    private TreatmentPlanService planService;

    @PostMapping("/create")
    public Result<TreatmentPlan> createPlan(@RequestBody @Valid TreatmentPlanCreateRequest request) {
        TreatmentPlan plan = planService.createPlan(request);
        return Result.success(plan);
    }

    @GetMapping("/history/{patientId}")
    public Result<List<TreatmentPlanVO>> getPlanHistory(@PathVariable("patientId") Integer patientId) {
        List<TreatmentPlanVO> list = planService.getPlanHistory(patientId);
        return Result.success(list);
    }
}

这里要注意的是，请求参数对象TreatmentPlanCreateRequest和实体类TreatmentPlan是分开的。前端传过来的参数，可能需要默认值或转换成日期格式，直接在Controller接口里用实体接收，会把请求参数校验和数据库实体耦合在一起，后期维护非常痛苦。定义独立的Request对象，跟我在前面提到的VO对象是一个道理，分层清晰，能让代码好读很多。

4.4 一个完整的请求链路

把这些串起来，一次“护士录入治疗记录”的请求会经历这样的链路：

前端通过Vue3封装的Axios发送POST请求到/api/record/add；
SpringMVC的前端控制器接收请求，通过处理器映射找到对应的方法；
TreatmentRecordController接收参数，先做格式合法性校验；
Controller调用TreatmentRecordService.addRecord()；
Service里首先查询计划状态，如果状态不是TREATING，直接抛出BusinessException；
校验通过后，插入治疗记录，更新计划的update_time；
如果传入了nextFollowUpDate，还要更新或插入一条复诊提醒记录；
事务提交，返回统一的Result结构给前端；
前端根据返回的code字段判断是否成功，并刷新页面数据。

这条链路里，我认为最重要的是第5步——在Service层做状态校验。所有修改业务数据的操作，都必须经过Service层的业务规则校验，而不是只在Controller层检查参数非空。这是系统是否具备“业务逻辑”的分水岭。

5. 前端对接：Vue3与SSM的跨域、请求封装与交互细节

现在很多毕业设计的前端都在用Vue3，这本身没问题，但SSM项目在对接Vue3时有一个绕不开的坑：端口不同导致的跨域问题。如果你用Vue开发服务器（默认5173端口），SSM后端跑在Tomcat的8080端口，两者之间直接访问会因为CORS策略被浏览器拦截。

5.1 跨域问题的两种解决方案

方案一是在后端加CORS配置。在SpringMVC里，可以用WebMvcConfigurer添加跨域映射：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意，使用allowCredentials(true)时不能同时使用allowedOrigins("*")，要使用allowedOriginPatterns("*")，否则浏览器会报错。这是一个小的坑，我这里提一下，免得你在调试时浪费时间。

方案二是在前端配置代理。在Vue3项目的vite.config.js里：

javascript复制export default defineConfig({
    server: {
        port: 5173,
        proxy: {
            '/api': {
                target: 'http://localhost:8080',
                changeOrigin: true
            }
        }
    }
})

推荐第二种。因为跨域真正上线后会有安全隐患，开发阶段用代理转发，既绕过了浏览器限制，又模拟了同源请求，更接近生产环境的行为。我自己调试时就是这么做的，实测很稳。

5.2 Axios封装与统一错误处理

Axios请求封装是前端项目整洁度的一个重要体现。每个页面都直接调axios.post(url, data)，代码会很散乱。我的习惯是集中封装一个request.js模块。

javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'

const request = axios.create({
    baseURL: '/api',
    timeout: 10000
})

// 请求拦截器：附加token
request.interceptors.request.use(config => {
    const token = localStorage.getItem('token')
    if (token) {
        config.headers['Authorization'] = token
    }
    return config
})

// 响应拦截器：统一处理错误
request.interceptors.response.use(
    response => {
        const res = response.data
        if (res.code === 200) {
            return res.data
        } else {
            ElMessage.error(res.message)
            return Promise.reject(new Error(res.message))
        }
    },
    error => {
        ElMessage.error('网络异常，请稍后重试')
        return Promise.reject(error)
    }
)

export default request

这里有一点需要提醒：在响应拦截器里，如果接口返回的是业务错误（比如code是500，message是“治疗计划已完成，不能添加记录”），ElMessage.error会弹出一个全局的错误提示。这样做的好处是页面代码里不用每个接口都写catch分支，业务错误会被统一处理。坏处是页面上可能弹两次错误提示——一次是拦截器弹的，一次是页面catch里弹的。解决办法就是页面里只处理成功逻辑，错误统一交给拦截器，页面不再重复弹出错误提示。

5.3 前端路由与动态菜单

对于一个分角色的系统，前端路由建议做动态路由。管理员、医生、护士看到的菜单应该不同：管理员看到用户管理、科室管理；医生看到病人列表、诊断管理、治疗计划管理；护士看到治疗记录录入、日常护理记录。

实现动态路由有两种思路。简单版是登录成功后根据角色字段在前端用v-if控制菜单显隐，不需要后端返回路由表；进阶版是后端在登录接口里返回当前角色拥有的菜单权限编码，前端根据权限编码动态生成路由。毕业设计用简单版就够了，但你要是想展示自己对权限控制的理解，可以用进阶版。个人建议如果时间充裕，用第二种，因为答辩时可用性展示效果非常明显。

5.4 数据可视化的小亮点

既然是“跟踪治疗”系统，可视化页面是加分项。用ECharts做几个图表并不难，但内容要比“所有病人的数量”有信息量。建议做这几个图：

按治疗状态分布：饼图，展示治疗中、已完成、已暂停、已终止的计划数量，反映当前在治病人的总体情况；
每月治疗计划新增数量趋势：折线图，展示月份维度的数据，体现系统的时间维度追踪能力；
今日待复诊提醒列表：普通表格即可，不用图表，展示“跟踪”这个行为最直接的结果。

ECharts只要引入前端项目，再封装一个图表组件，数据格式对齐后调用即可。这里的重点是数据接口，你需要在后端提供对应的统计SQL。比如按状态分布就是GROUP BY plan_status加COUNT(*)，非常简单，但对答辩的展示效果提升很明显。

6. 从开发到答辩：部署演示与高频追问

系统写完了，还要能顺利跑起来、讲明白，这才是毕业设计的完整闭环。这一章我讲讲实际部署时会遇到的高频问题，以及答辩时老师最喜欢追问的几个方向。

6.1 项目从零启动的完整步骤

实际部署这个项目，我的建议步骤如下：

准备基础环境：JDK 8或11、Maven 3.6+、Tomcat 9、MySQL 5.7或8.0。注意JDK版本要和Tomcat兼容，如果你用JDK 17搭配Tomcat 9，个别功能可能会报模块访问错误，建议用JDK 8最省心。
创建数据库并初始化：执行你准备好的建表SQL，将初始管理员账号插入用户表。注意数据库字符集要设置为utf8mb4，否则录入病人姓名时遇到生僻字可能乱码。
修改配置文件：项目中的jdbc.properties或application.properties里配置数据库连接信息。如果你本地MySQL密码是空，而代码里写的是root/123456，启动就会报Access denied。这个细节最容易在演示现场翻车。提前检查数据库密码是否匹配。
Maven编译打包：在项目根目录执行mvn clean package -DskipTests，如果项目是war包，放到Tomcat的webapps目录下启动；如果是jar包（Spring Boot方式），直接java -jar运行。SSM传统做法一般是war包，注意打包时不要漏掉配置文件。
前端构建：如果使用Vue3，在项目目录执行npm install和npm run build，把dist目录下的文件部署到Nginx或Tomcat的静态目录。开发调试时可以直接用npm run dev启动Vite服务器，配合前端代理访问后端接口。
启动验证：先访问后端接口确认返回JSON，再访问前端页面确认能正常登录和查询数据。特别要注意登录后Session的管理，SSM项目默认的Session有效期是30分钟，如果演示现场时间较长，建议在配置里调大，比如改成120分钟，避免演示到一半Session过期被踢下线。

6.2 演示时推荐的展示路径

答辩演示时不要从头到尾乱点，要设计一条故事线。我按这个系统的业务闭环推荐如下：

以管理员身份登录 → 创建医生和护士账号 → 切换到医生账号 → 新建一个病人 → 做出诊断并创建治疗计划 → 切换到护士账号 → 按计划录入两条治疗记录 → 回到医生账号查看治疗历史 → 标记计划完成 → 查看复诊提醒列表 → 查看统计图表页面

这条路径走下来，整个过程就是一次完整的“病人跟踪治疗”闭环。老师能直观看到你系统的每一个模块都不是孤立的，而是串联在业务流程里的。这点非常重要，因为它直接对应了我在第1章反复强调的“业务闭环”。

6.3 答辩时最容易被追问的五个问题

根据经验，老师对这类系统的高频追问基本集中在五个方向，事先做好准备，比临场发挥要靠谱太多：

“你的系统解决了什么实际问题？”
- 答：核心是构建了一个从诊断到治疗、再到后期跟踪的闭环，通过状态流转控制治疗流程，让医生和护士能协同工作并完整记录治疗过程。
“治疗计划的状态是怎么管理的？”
- 答：定义状态机，状态字段控制流转，Service层做校验。这是系统最有价值的设计之一，你放在代码里的状态流转Map会在这里发挥最大作用。
“如果两个护士同时为一个病人录入治疗记录，会出现什么问题？”
- 答：最后执行的记录覆盖前一条，或者两个记录都插入成功但顺序混乱。解决思路是用事务加行级锁控制并发，比如在计划表上做乐观锁版本号判断，或者用数据库的唯一约束防止重复。其实这个系统并发量不大，但能够说出乐观锁或select ... for update的概念，说明你有并发意识。
“数据库是怎么设计的？为什么这么设计？”
- 答：按业务闭环拆实体，核心是计划表和记录表，通过外键关系串联流程；用状态字段控制计划生命周期，用时间字段做跟踪和提醒。多表设计时注意主外键关系和索引的建立。
“MyBatis的#{}和${}有什么区别？”
- 答：#{}是预编译占位符，会生成?，能防止SQL注入；${}是字符串拼接，有注入风险，不能直接拼接用户输入。这是MyBatis最经典的一道题，这个项目正好用了动态SQL，回答时可以结合项目里的实际写法。

6.4 给代码留几条“扩展接口”

这个问题可能不在答辩问题清单里，但我建议你提前给系统留几个扩展点，装也要装出扩展性。比如：

在治疗记录表里预留record_type字段，后续可以接入更多治疗类型；
在病人表里预留medical_record_number字段，后续可以做电子病历编号；
在复诊提醒表里预留remind_channel字段，后续可以对接短信或微信公众号推送。

这些字段可以不用做复杂的界面功能，但在数据库设计文档里体现出来，并说明“我保留了接口的扩展性”，会让老师觉得你考虑问题有前瞻性。

7. 我踩过的几个坑，希望你避开

项目做完之后复盘，有几类坑是SSM病人管理类项目里最容易遇到的，我挑几个典型的分享出来，都是实际动手才能体会到的。

第一个坑是日期时间类型的序列化问题。 后端实体里用Date类型，返回给前端时可能会变成一串时间戳数字，而不是“2024-12-01 14:30:00”这种可读格式。原因是你没有配置日期格式化。解决办法是在实体类的日期字段上加上@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解，或者在SpringMVC配置里统一注册一个自定义ObjectMapper。这个坑很不起眼，但真的会影响演示效果——页面上显示一串数字，观感非常差。

第二个坑是MyBatis的Mapper扫描不全导致的启动报错。 有时你会忘记在启动类或配置里扫描Mapper包，结果启动时Spring容器找不到Bean。SSM项目里通常用@MapperScan("com.hospital.treatment.dao")来指定扫描路径，如果路径写错了，启动不会立即报错，而是在第一个调用Mapper的地方才报NoSuchBeanDefinitionException。调试时会很困惑，排查半天发现是路径写错了。

第三个坑是上传图片或文件时的临时目录问题。 有些同学会做病人头像上传功能，用MultipartFile接收文件，存到本地磁盘。但Tomcat有时候会因为临时目录被清理导致文件上传报错。稳妥的做法是把文件保存到项目外部的一个独立目录（比如D:/upload/），而不是存在项目目录内，避免重新部署时文件丢失。

第四个坑是前端联调时的接口路径不一致。 后端接口如果是/api/plan/create，前端Axios的基础路径设置写成了/api，请求又拼了一次/plan/create，那没问题。但如果你后端的Controller类上写了@RequestMapping("/api/plan")，方法上又写了@PostMapping("/create")，而前端直接用/plan/create去请求，就404了。调试这类问题最快的办法是打开浏览器开发者工具看Network面板里的请求URL，和后端实际映射的路径做对比。

8. 写在最后：这个项目的扩展价值

SSM病人跟踪治疗信息管理系统做下来，你其实已经完成了一个中型业务系统的完整开发流程。它不是一个“题库”式的CRUD项目，而是有业务规则、有状态管理、有事务控制、有权限体系、有前端交互的完整应用。

如果你时间还充裕，我建议你在现有基础上往这两个方向任选一个做扩展：一是给系统引入WebSocket，做一个简单的医生端实时消息提醒，比如病人有新治疗记录时推送给主管医生；二是引入定时任务，用Spring的@Scheduled实现每天自动检查复诊提醒，给即将复诊的病人生成待办任务。这两个方向都属于“系统自运行”的能力，会让老师眼前一亮。

从个人经验来讲，做毕业设计最忌讳的是急于求成。你把这个系统的需求调研、数据库设计、代码分层、状态流转想明白，收获的不仅是一个能通过的毕设，而是一整套“如何从零搭建一个业务系统”的方法论。这套东西，比任何源码本身都值钱。

我在实际开发过程中一直在坚持一个原则：每张表、每个接口、每个状态，都要能回答出“为什么要这么设计”。多问自己几个为什么，答辩时你才能答得理直气壮。

SSM病人跟踪治疗信息管理系统：从需求分析到部署答辩完整指南