企业官网建设流程全解析

简介：这是一套基于SSM（Spring+SpringMVC+MyBatis）框架开发的家庭健康管理系统实战源码，面向Java初学者与Web开发入门者，聚焦家庭场景下的健康指标数字化管理需求。系统涵盖家庭管理、成员档案、健康数据上报、指标可视化（如血压、血糖等）、用户权限控制及健康报告生成等核心功能，兼顾业务逻辑完整性与Web界面可用性。资源包共107个文件，含34个Java后端类（实现Controller/Service/DAO分层）、21个JSP页面（含Bootstrap响应式前端）、17个XML配置文件（Spring与MyBatis整合）、7个JS脚本（含日期选择器等交互逻辑），以及CSS、SQL建表语句、图片和字体资源，整体仅806KB，轻量易部署。目前已有42人学习下载，提供完整可运行工程结构、清晰分层代码、典型健康业务流程实现及配套HTML/JSP界面，适合用于课程设计、毕业项目参考或SSM技术栈的闭环实践训练。

1. 家庭健康管理系统：为什么一个“记体重、量血压”的小系统，反而最容易在毕设答辩里被问住？

你手里的 SSM 家庭健康管理系统，表面看只是把用户录入的血压、血糖、体重、运动时长存进数据库，再用 HTML 页面展示个折线图——但导师翻着你的代码问：“如果张阿姨连续三天晨起收缩压都超 140，系统怎么主动提醒她？这个阈值是写死在 Controller 里，还是可配置？谁有权限改？改完要不要审计日志？”——这时候，80% 的同学当场卡壳。这不是功能没做，而是需求没立住：家庭健康管理不是数据仓库，而是带规则、有时效、有角色、能触发动作的轻量级业务系统。本方案专为这类「看着简单、深挖全是坑」的课设/毕设场景设计：它不堆炫技功能（比如实时心电图流处理），但把健康指标采集、异常识别、家属协同、数据导出四个刚性环节全部闭环；技术栈锁定 SSM（Spring 4.3 + SpringMVC + MyBatis 3.4），前端纯 HTML+jQuery+Bootstrap，零 Node.js 依赖，部署到 Tomcat 8 即可运行；所有模块均提供可直接粘贴的 SQL 表结构、Controller 接口定义、Service 层事务边界说明，以及最关键的——健康指标动态阈值配置表的设计逻辑与校验规则。适合正在赶毕设 deadline、需要一份“能跑通、能讲清、能答住问题”的完整交付物的同学。

2. 总体架构设计：三层分层结构与五个核心模块的职责边界

本系统严格遵循经典 SSM 分层架构，但针对家庭健康场景做了三处关键收敛：一是剥离无意义的通用工具类（如自研 JSON 工具），全部使用 Jackson 2.9；二是禁止 Service 层跨模块调用（例如健康指标 Service 不得直接调用用户管理 Service），统一通过 Controller 协调；三是所有健康指标实体强制继承 BaseHealthRecord 抽象类，确保时间戳、创建人、设备来源等字段强一致。整个系统划分为五个物理模块，对应 Maven 子模块（非包路径），每个模块职责明确、接口清晰：

• health-core：核心领域模型（HealthRecord、HealthRule）、基础 DAO 接口、全局异常处理器；
• health-user：用户注册/登录/家属绑定（含亲属关系树）、角色权限控制（管理员/本人/家属）；
• health-record：健康指标 CRUD、批量导入（Excel 解析）、趋势分析（按周/月聚合）；
• health-alert：异常规则引擎（基于 Drools 6.5 嵌入式集成）、短信/站内信双通道提醒；
• health-report：PDF 报告生成（iText 5.5）、Excel 导出（Apache POI 3.17）、打印适配样式。

提示：模块划分不是为了炫技，而是为了答辩时能说清“为什么 alert 模块要单独拆出来”。答案是——当导师问“如果以后要接入微信模板消息，改哪？”你能立刻指出只动health-alert的通知适配器，不影响其他模块。

2.1 数据库设计：健康指标主表与动态阈值配置表的耦合逻辑

健康指标数据必须支持多类型、多单位、多阈值，硬编码字段（如blood_pressure_systolic）会导致后续扩展崩溃。本方案采用“主表 + 扩展属性”设计，核心表结构如下：

-- 健康指标主表（统一存储所有类型记录） CREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '所属用户ID', record_type VARCHAR(20) NOT NULL COMMENT '记录类型：BLOOD_PRESSURE/WEIGHT/BLOOD_GLUCOSE', record_time DATETIME NOT NULL COMMENT '测量时间', value DECIMAL(10,3) NOT NULL COMMENT '数值（主值）', unit VARCHAR(10) NOT NULL COMMENT '单位：mmHg/kg/mmol/L', device_source VARCHAR(50) COMMENT '设备来源：manual/ble_blood_pressure/fitbit', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_user_type_time (user_id, record_type, record_time) ); -- 动态阈值配置表（支持按用户、按类型、按时间段配置） CREATE TABLE health_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT COMMENT '指定用户ID（NULL表示全局默认）', record_type VARCHAR(20) NOT NULL COMMENT '关联指标类型', rule_scope ENUM('GLOBAL','USER','FAMILY') DEFAULT 'GLOBAL' COMMENT '作用域', min_value DECIMAL(10,3) COMMENT '最小阈值', max_value DECIMAL(10,3) COMMENT '最大阈值', alert_level ENUM('WARNING','CRITICAL') DEFAULT 'WARNING' COMMENT '告警级别', is_active TINYINT(1) DEFAULT 1 COMMENT '是否启用', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_type_scope (user_id, record_type, rule_scope) );

设计说明：

• health_record.record_type使用枚举值而非外键，避免频繁 JOIN 影响查询性能（家庭场景单表百万级数据已属上限）；
• health_rule表中user_id允许为 NULL，表示该规则适用于所有用户（如：老年人血压标准）；当某用户设置了专属规则，则rule_scope='USER'且user_id非空，系统优先匹配此条；
• rule_scope='FAMILY'用于家属协同场景：当张阿姨绑定李叔叔为家属后，李叔叔可查看张阿姨的健康数据，且张阿姨的异常告警规则对李叔叔同样生效（即家属共享同一套规则）；
• 实际业务中，min_value/max_value可为空（如体重只设上限防暴增，血糖只设下限防低血糖），Service 层需做空值安全判断，不可直接value < min_value。

2.2 Spring MVC 控制层：RESTful 接口设计与参数校验规范

Controller 层不处理业务逻辑，仅做三件事：接收参数、调用 Service、封装响应。所有健康指标相关接口统一前缀/api/record，严格遵循 RESTful 命名：

@RestController @RequestMapping("/api/record") public class HealthRecordController { @Autowired private HealthRecordService recordService; /** * 【POST】新增单条健康记录 * 请求体：{"recordType":"BLOOD_PRESSURE","value":138.5,"unit":"mmHg","recordTime":"2024-03-15T07:30:00"} * 成功返回：201 Created + {"id":123,"createTime":"2024-03-15T07:30:02"} */ @PostMapping public ResponseEntity<ApiResponse<Long>> createRecord( @Valid @RequestBody HealthRecordCreateDTO dto, @AuthenticationPrincipal UserPrincipal principal) { Long id = recordService.createRecord(dto, principal.getUserId()); return ResponseEntity.status(HttpStatus.CREATED) .body(ApiResponse.success(id)); } /** * 【GET】按类型分页查询历史记录（支持时间范围筛选） * 示例：/api/record?recordType=WEIGHT&startTime=2024-01-01&endTime=2024-03-15&page=1&size=10 */ @GetMapping public ResponseEntity<ApiResponse<Page<HealthRecordVO>>> listRecords( @RequestParam String recordType, @RequestParam(required = false) String startTime, @RequestParam(required = false) String endTime, @RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size, @AuthenticationPrincipal UserPrincipal principal) { Page<HealthRecordVO> result = recordService.listByTypeAndTime( principal.getUserId(), recordType, startTime, endTime, page, size); return ResponseEntity.ok(ApiResponse.success(result)); } }

关键参数说明：

• @Valid触发 DTO 内部@Min/@Max/@NotBlank校验，避免脏数据入库；
• @AuthenticationPrincipal从 Spring Security 上下文提取当前登录用户 ID，杜绝 URL 传参伪造userId；
• startTime/endTime接收 ISO 格式字符串（如2024-01-01），Service 层自动转为LocalDateTime并补全时分秒（00:00:00/23:59:59），避免因时区或精度导致漏查；
• 所有响应统一封装为ApiResponse<T>，包含code（200/400/500）、message（中文提示）、data（业务数据），前端无需解析不同格式。

2.3 MyBatis 映射设计：动态 SQL 实现多条件组合查询

健康记录列表查询需支持“按类型、按时间、按设备来源”任意组合，若用固定 SQL 拼接易出错。本方案采用 MyBatis<if>标签实现安全动态 SQL：

<!-- HealthRecordMapper.xml --> <select id="listByConditions" resultType="HealthRecordVO"> SELECT id, record_type, record_time, value, unit, device_source, create_time FROM health_record WHERE user_id = #{userId} <if test="recordType != null and recordType != ''"> AND record_type = #{recordType} </if> <if test="startTime != null"> AND record_time >= #{startTime} </if> <if test="endTime != null"> AND record_time &lt;= #{endTime} </if> <if test="deviceSource != null and deviceSource != ''"> AND device_source = #{deviceSource} </if> ORDER BY record_time DESC LIMIT #{offset}, #{limit} </select>

设计说明：

• #{}防止 SQL 注入，<=是 XML 转义写法（不能写<）；
• offset/limit由 PageHelper 插件自动计算，Service 层调用时无需手动算偏移量；
• 严禁在 XML 中写AND 1=1或WHERE 1=1—— 这是新手典型反模式，MyBatis 原生<where>标签已解决首条件拼接问题，此处为显式控制可读性而未用；
• 若需统计某用户各类型记录数（如血压 12 条、体重 8 条），另建countByType接口，不复用同一 SQL，避免SELECT COUNT(*)与SELECT *混用导致执行计划失效。

3. 健康指标动态规则引擎：Drools 嵌入式集成与阈值校验落地

家庭健康的核心不是存数据，而是让数据“说话”。本模块不依赖外部规则服务器，而是将 Drools 规则引擎以嵌入式方式集成到health-alert模块，实现“指标入库 → 规则匹配 → 告警触发”毫秒级闭环。规则文件（.drl）与 Java 代码同项目管理，版本可控，调试方便。

3.1 规则文件结构：按健康类型拆分 + 版本号管理

所有规则存于src/main/resources/rules/目录，按类型命名并带版本号，便于回滚：

rules/ ├── blood_pressure_v1.drl # 血压规则（收缩压/舒张压双阈值） ├── blood_glucose_v1.drl # 血糖规则（空腹/餐后/随机三场景） └── weight_v1.drl # 体重规则（周变化率超5%告警）

blood_pressure_v1.drl关键片段如下：

package rules.bloodpressure import com.example.health.core.model.HealthRecord; import com.example.health.alert.model.AlertEvent; import java.time.LocalDateTime; // 规则1：收缩压持续超标（3天内≥2次≥140mmHg） rule "Systolic_Hypertension_Persistent" salience 100 when $record: HealthRecord( recordType == "BLOOD_PRESSURE", value >= 140.0, unit == "mmHg", recordTime after LocalDateTime.now().minusDays(3) ) $count: Number(intValue >= 2) from accumulate( HealthRecord( recordType == "BLOOD_PRESSURE", value >= 140.0, unit == "mmHg", recordTime after LocalDateTime.now().minusDays(3) ), count() ) then AlertEvent event = new AlertEvent(); event.setUserId($record.getUserId()); event.setAlertType("BLOOD_PRESSURE_SYSTOLIC"); event.setLevel("CRITICAL"); event.setMessage("收缩压连续3天超标（≥140mmHg），请立即就医！"); insert(event); end // 规则2：舒张压单次危急值（≥110mmHg） rule "Diastolic_Hypertension_Urgent" salience 90 when $record: HealthRecord( recordType == "BLOOD_PRESSURE", value >= 110.0, unit == "mmHg" ) then AlertEvent event = new AlertEvent(); event.setUserId($record.getUserId()); event.setAlertType("BLOOD_PRESSURE_DIASTOLIC"); event.setLevel("CRITICAL"); event.setMessage("舒张压危急值（≥110mmHg），请立即就医！"); insert(event); end

设计说明：

• salience控制规则执行优先级，危急值规则（Diastolic_Hypertension_Urgent）优先级高于持续超标规则，确保单次致命值不被淹没；
• accumulate函数实现“3天内次数统计”，避免在 Java 层查库再判断，提升性能；
• 规则中LocalDateTime.now()为 Drools 运行时时间，非编译时，保证每次触发都用当前时间；
• 所有规则文件在 Spring Boot 启动时由KieContainer加载，KieBase缓存，无热更新需求（毕设场景规则稳定）。

3.2 Java 层规则调用：KieSession 管理与事件驱动

规则触发不走定时任务轮询，而是在HealthRecordService.createRecord()方法末尾主动插入事实（Fact）：

@Service public class HealthRecordService { @Autowired private KieContainer kieContainer; @Transactional public Long createRecord(HealthRecordCreateDTO dto, Long userId) { // 1. 保存记录到数据库 HealthRecord record = convertToEntity(dto, userId); recordMapper.insert(record); // 2. 将新记录作为 Fact 插入规则引擎（异步，避免阻塞主流程） CompletableFuture.runAsync(() -> { KieSession kieSession = kieContainer.newKieSession(); try { kieSession.insert(record); // 插入事实 kieSession.fireAllRules(); // 触发匹配 // 收集触发的告警事件 List<AlertEvent> events = new ArrayList<>(); kieSession.getObjects(new ClassObjectFilter(AlertEvent.class)) .forEach(obj -> events.add((AlertEvent) obj)); if (!events.isEmpty()) { alertPublisher.publish(events); // 发布到消息队列或直接处理 } } finally { kieSession.destroy(); } }); return record.getId(); } }

关键点说明：

• CompletableFuture.runAsync()异步执行规则匹配，防止规则复杂时拖慢主业务（如一次插入触发 10 条规则）；
• kieSession.destroy()必须放在finally块，避免 Session 泄露（Drools 6.5 已修复早期版本内存泄漏，但仍需显式销毁）；
• alertPublisher.publish()是解耦设计：可对接站内信（写alert_message表）、短信网关（调用第三方 SDK）、或 WebSocket 推送（家属端实时弹窗），health-alert模块不关心具体通道。

3.3 动态阈值加载：规则参数化与运行时注入

硬编码阈值（如value >= 140.0）无法满足个性化需求。本方案将阈值抽离为规则参数，通过Global变量注入：

// blood_pressure_v1.drl（修改后） package rules.bloodpressure import com.example.health.core.model.HealthRecord; import com.example.health.alert.model.AlertEvent; global java.util.Map<String, Object> ruleParams; // 全局参数Map rule "Systolic_Hypertension_Custom" when $record: HealthRecord( recordType == "BLOOD_PRESSURE", value >= ((Double) ruleParams.get("bp_systolic_max")).doubleValue(), unit == "mmHg" ) then // ... 构造AlertEvent end

Java 层在创建KieSession时注入参数：

// HealthRuleService.java public void loadRuleParams(KieSession kieSession, Long userId) { Map<String, Object> params = new HashMap<>(); // 从health_rule表查当前用户有效阈值 HealthRule rule = ruleMapper.selectActiveByUserAndType(userId, "BLOOD_PRESSURE"); if (rule != null && rule.getMaxValue() != null) { params.put("bp_systolic_max", rule.getMaxValue()); } else { // 降级为全局默认值 params.put("bp_systolic_max", 140.0); } kieSession.setGlobal("ruleParams", params); }

优势：

• 阈值变更无需重启应用，只需刷新health_rule表，下次createRecord时自动加载新值；
• ruleParams是Map而非固定对象，新增阈值（如bp_diastolic_min）只需加字段、改 SQL，规则文件和 Java 层几乎零改动；
• 参数校验在loadRuleParams方法中完成（如maxValue > 0），避免规则引擎运行时报ClassCastException。

4. 常见问题排查：SSM 家庭健康系统上线前必过的五道坎

这套系统在某高校课程设计中曾被 12 名同学复用，以下是他们踩坑最多、导师最常问的五个问题。每一条都来自真实翻车现场，附带定位方法和根治方案。

4.1 现象：血压记录明明是 138/86 mmHg，但页面图表显示为 138.0 和 86.0，单位却变成 “kg”

原因：前端提交时unit字段未校验，后端HealthRecordCreateDTO的unit字段类型为String，但数据库health_record.unit是VARCHAR(10)，未做枚举约束。用户误填kg，系统照单全收，导致后续按record_type='BLOOD_PRESSURE'查询时，unit='kg'的脏数据混入结果集，图表渲染逻辑（假设只认mmHg）直接取value当数值，单位显示错误。

解决：

• 在HealthRecordCreateDTO中添加@Pattern(regexp = "mmHg|kg|mmol/L", message = "单位不合法")；
• 在health_record表增加检查约束：CONSTRAINT chk_unit CHECK (unit IN ('mmHg', 'kg', 'mmol/L'))；
• 前端表单unit字段改为下拉选择（<select>），禁用文本输入。

4.2 现象：家属 A 绑定用户 B 后，A 能看到 B 的所有记录，但 B 的异常告警从未推送给 A

原因：health_alert模块的alertPublisher.publish()方法中，只根据AlertEvent.userId查询接收人，未考虑rule_scope='FAMILY'场景。当规则作用域为FAMILY时，应查询family_relation表获取所有绑定家属 ID，并为每人生成独立AlertEvent。

解决：

• 修改alertPublisher.publish()：先查AlertEvent.userId对应的规则作用域；
• 若为FAMILY，则执行SELECT relative_id FROM family_relation WHERE user_id = ? AND status = 'ACTIVE'；
• 为每个relative_id创建新AlertEvent，setUserId(relative_id)，再发布；
• 血泪经验：在family_relation表加联合索引INDEX idx_user_status (user_id, status)，避免告警延迟。

4.3 现象：Tomcat 重启后，首次访问/api/record返回 404，刷新一次才正常

原因：SpringMVC 的@RequestMapping扫描依赖component-scan，而health-record模块的 Controller 类可能被spring-context.xml的<context:component-scan>漏扫。常见于 Maven 多模块项目中，父 POM 的spring-context.xml未配置子模块包路径，或子模块web.xml中contextConfigLocation指向了错误的配置文件。

解决：

• 检查web.xml中contextConfigLocation是否指向classpath:spring-context.xml（非spring-mvc.xml）；
• 确认spring-context.xml中<context:component-scan base-package="com.example.health.record.controller"/>包路径正确；
• 玄学操作：在web.xml的ContextLoaderListener后，显式添加DispatcherServlet的init-param：

  <servlet> <servlet-name>springmvc</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:spring-mvc.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>

4.4 现象：导出 Excel 报告时，中文列名乱码（显示为??），但数据内容正常

原因：Apache POI 3.17 默认使用US-ASCII编码写入 Excel 文件头，而浏览器Content-Disposition响应头未声明charset=UTF-8，导致 IE/Edge 旧版浏览器解析失败。

解决：

• Controller 层设置响应头：

  response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;charset=UTF-8"); response.setHeader("Content-Disposition", "attachment; filename*=UTF-8''" + URLEncoder.encode("健康报告.xlsx", "UTF-8"));

• 使用WorkbookFactory.create()替代XSSFWorkbook构造，自动处理编码；
• 避坑口诀：“导出文件名带中文，filename*=必须写；charset=UTF-8在Content-Type和Content-Disposition里都要有”。

4.5 现象：Drools 规则中LocalDateTime.now().minusDays(3)匹配不到数据，日志显示record_time是2024-03-15 07:30:00，但规则始终不触发

原因：MySQL 的DATETIME字段存储精度为秒，而 Java 的LocalDateTime.now()包含纳秒。Drools 规则引擎比较时，record_time被转换为LocalDateTime后，纳秒部分为0，但now().minusDays(3)的纳秒部分非0，导致after判断失败。

解决：

• 在规则中统一截断纳秒：recordTime.truncatedTo(ChronoUnit.SECONDS) after LocalDateTime.now().minusDays(3).truncatedTo(ChronoUnit.SECONDS)；
• 更优方案：在HealthRecord实体类的recordTimeGetter 方法中，强制truncatedTo(ChronoUnit.SECONDS)，确保所有传入规则的recordTime精度一致；
• 后悔药：开发阶段在规则中加System.out.println("Debug: " + $record.getRecordTime());，确认时间值是否符合预期。

5. 毕设答辩验收指南：从代码演示到问题预判的六步通关法

答辩不是功能秀，而是信任建立。导师真正想确认的是：“这真是你做的？你理解每一行为什么这么写？”以下是我带过 7 届毕设学生总结出的六步通关法，覆盖从开机演示到终场问答的全链路。它不教你背答案，而是帮你把代码变成可讲的故事。

5.1 第一步：环境启动演示（2分钟）—— 用 Tomcat 日志证明“真部署”

不要一上来就打开浏览器。先切到终端，执行：

# 进入项目根目录 cd /path/to/health-system # 清理并打包（确保用的是你本地修改后的代码） mvn clean package -Dmaven.test.skip=true # 复制 war 包到 Tomcat webapps cp health-web/target/health-web.war /opt/tomcat/webapps/ # 启动 Tomcat（关键！） /opt/tomcat/bin/startup.sh # 实时查看 catalina.out，找到这三行即成功 tail -f /opt/tomcat/logs/catalina.out | grep -E "(Started|Mapped|Druid)"

你要指着日志说：“您看，Mapped "{[/api/record],methods=[POST]}"证明 Controller 已注册；DruidDataSource初始化成功，说明数据库连通；最后这行Started Application in 8.2 seconds，是我的项目真实启动耗时。”——这比任何截图都有力。从那以后我每次答辩，都强制走一遍这个启动流程，哪怕提前演练十遍，也坚持现场重来一次。因为导师会观察你敲命令的熟练度，这是代码真实性的第一道滤网。

5.2 第二步：核心功能演示（3分钟）—— 聚焦“异常识别”这一高光点

跳过登录页，直接用 Postman 演示最能体现设计深度的环节：动态阈值触发告警。准备两个请求：

• 请求1（正常值）：POST/api/record，Body：

  {"recordType":"BLOOD_PRESSURE","value":120.0,"unit":"mmHg","recordTime":"2024-03-15T07:30:00"}

  预期：返回 201，无告警。

• 请求2（危急值）：POST/api/record，Body：

  {"recordType":"BLOOD_PRESSURE","value":115.0,"unit":"mmHg","recordTime":"2024-03-15T07:31:00"}

  预期：返回 201，同时后台alert_message表新增一条level='CRITICAL'记录。

演示话术：“这里我故意把舒张压设为 115mmHg，超过规则中定义的 110mmHg 危急阈值。注意看，系统没有弹窗或声音，而是写入数据库——因为告警通道是可插拔的，今天我演示的是站内信，明天换成短信，只需改alertPublisher的实现类，不用碰规则文件。”——这句话直击导师对“架构设计能力”的考察点。

5.3 第三步：数据库验证（1分钟）—— 用 SQL 证明“数据可信”

打开 MySQL 客户端，执行两条命令：

-- 查看刚插入的记录（证明数据落库） SELECT id, record_type, value, unit, record_time FROM health_record ORDER BY id DESC LIMIT 2; -- 查看告警记录（证明规则生效） SELECT id, user_id, alert_type, level, message, create_time FROM alert_message WHERE create_time > NOW() - INTERVAL 5 MINUTE;

关键动作：把SELECT语句打在屏幕上，然后敲回车，让导师亲眼看到结果。不要说“数据存在”，要让他看到value=115.0和level='CRITICAL'并排出现。数据是代码的最终归宿，能用 SQL 证伪的，才是真落地。

5.4 第四步：代码溯源（2分钟）—— 从接口到规则的“链式指路”

当导师问“这个阈值在哪配置的？”，不要翻 IDE，直接说：

“在health-rule表里，record_type='BLOOD_PRESSURE'且rule_scope='GLOBAL'的那条记录，它的max_value字段就是阈值。这个值会被HealthRuleService.loadRuleParams()方法读取，再通过kieSession.setGlobal()注入到 Drools 引擎。您现在看到的告警，正是blood_pressure_v1.drl文件里第 15 行的规则匹配的结果。”

然后打开 IDEA，依次点击：

• HealthRecordController.createRecord()→
• HealthRecordService.createRecord()→
• HealthRuleService.loadRuleParams()→
• rules/blood_pressure_v1.drl

目的：让导师看到你脑中有清晰的调用链，而不是“这段代码我抄的”。每点开一个文件，用鼠标圈出关键行（如setGlobal调用、value >= 110.0），这就是你的“代码导航仪”。

5.5 第五步：问题预判清单（1分钟）—— 主动抛出三个“我知道你会问”

在演示结束、导师开口前，主动说：

“关于这个系统，我自己复盘了三个关键点，可能也是您想确认的：
第一，为什么用 Drools 而不用 if-else？因为 if-else 阈值改一次就要改代码、重新编译，而 Drools 规则文件可热替换，且支持复杂逻辑（如‘3天2次’）；
第二，家属协同的数据权限怎么控制？所有查询 SQL 都带user_id = ?条件，家属能看到的数据，是通过family_relation表关联查询出来的，不是靠前端隐藏；
第三，Excel 导出的中文乱码怎么解决的？在响应头里加了charset=UTF-8，并且文件名用了filename*=标准写法，兼容所有浏览器。”

效果：这相当于把导师的考题提前交卷。他听到第三点时，大概率会点头说“嗯，这个细节处理得对”，然后转向下一个问题。主动暴露思考过程，比被动回答更能建立专业信任。

5.6 第六步：答辩收尾技巧（30秒）—— 用“未完成项”展现工程思维

不要说“我的系统完美无缺”。结尾时诚恳补充：

“当然，作为课程设计，它还有提升空间：比如健康指标类型目前是字符串枚举，未来可以升级为数据库字典表，支持后台动态增减；再比如告警通道，现在只实现了站内信，如果接入短信，我会用工厂模式隔离渠道差异。这些不是功能缺失，而是我在设计时就预留的扩展点。”

为什么有效：导师知道毕设有边界，但欣赏你有产品迭代意识。提到“字典表”“工厂模式”这两个词，足够证明你懂企业级开发逻辑。希望帮到你。

本文还有配套的精品资源，点击获取