社区健康管理系统毕业设计实战：Vue+Spring Boot+AI风险预测

如果一个社区的居民健康管理还停留在纸质档案和Excel表格的阶段，光是整理高血压随访记录就能让人崩溃。青湖社区健康管理系统就是为这种场景做的：面向社区基层的健康管理平台，前端用Vue搭建，后端提供稳定接口服务，同时把AI能力放进核心流程里——对体检数据做异常识别、风险预测和健康建议生成，最后将源码、论文、答辩PPT整套沉淀成可直接复用的毕业设计成果。

这个题目放在本科软工或计算机类的毕设里相当有代表性：它不只是一个普通的增删改查系统，而是把Vue前端、Java后端、MySQL数据库和Python机器学习模型串成了一条完整链路。做这个项目的人能同时练到前后端联调、数据库设计、模型训练和系统部署，论文也有实打实的实验数据可写。我指导这类题目时最常说的话是：不要一开始就盯着大模型不放，先把这个系统的主干搭稳，再用一个轻量可解释的AI模块去撑起论文的研究价值和答辩亮点。

这篇拆解我会按实际做项目的顺序来展开——从需求怎么切，到技术选型为什么这么定，再到核心模块怎么实现、论文和PPT怎么准备，最后把我踩过的坑全部整理出来。

1. 毕业设计怎么切入：青湖社区健康管理系统的核心需求拆解

1.1 青湖社区的业务场景与功能清单

做系统之前先搞清楚一件事：这个系统到底给谁用、解决什么痛点。青湖社区是一个典型的城市社区，常住居民几千户，社区卫生服务中心日常承担居民健康档案建立、老年人免费体检、高血压糖尿病随访这些工作。以前的做法是信息登记在纸质表里，体检数据散落在各个Excel文件，社区医生随访全靠电话和微信提醒，居民的健康趋势根本看不出来。

这个系统要完成的业务闭环也很明确：建档 → 体检 → 评估 → 随访。围绕这条闭环，拆出六个核心功能模块：

这里要注意一个定位问题：它不是医院HIS系统，不做开药、不做住院管理，只做健康管理。这个边界必须卡死，否则需求越做越大，学生根本收不住。社区健康管理系统的数据量级也不需要高并发设计，MySQL单库完全够用，重点在业务逻辑完整性和AI模块的可解释性上。

1.2 模块划分为“管理+服务+AI”三条主线

整个系统如果按功能性质划分，可以分成三条主线，这三条线在写论文时也正好对应三个章节的重点。

第一条线是基础数据管理，即档案和体检记录的增删改查、分页筛选、Excel导入导出。这条线占了系统代码量的一半左右，难度不高但工作量大，它决定了系统是不是“完整能用”。

第二条线是可视化服务，用ECharts把历次体检的血压趋势、血糖波动画成折线图，用统计卡片展示社区重点人群数量。这条线决定了系统演示时“好不好看”。

第三条线是AI能力，通过体检特征预测慢病风险、自动生成健康建议，并通过定时任务推送提醒。这条线只占代码量三成左右，但撑起了论文的研究价值，也决定了答辩时评委愿不愿意追问下去。

把三条线在脑子里分开，写代码不会乱，写论文的章节结构也不会散。我见过很多学生把CRUD和图表代码混在一章里写，最后论文读起来就像功能说明书，没有主线。

1.3 这类选题为什么“好做”但“不撞车”

社区健康管理系统毕业设计并不是冷门选题，相反，它是每年都会出现的“高频题”，因为业务模式清晰、数据库表结构直观、技术栈通用。但正因为高频，很多同学做的版本大同小异：一个居民表、一个体检表、几个查询页面、几张图表就交差了，论文里没有任何分析性内容。

“好做但容易撞车”是这类题的真实状态。避免撞车的办法不是换一个更偏门的业务，而是在AI能力上做出差异化。同样是体检数据，别人只展示曲线，你在此基础上做风险预测和健康建议生成，选题的层级就出来了。这也是为什么题目里点名“基于AI功能”——它重新定义了项目的重心。

当然，给自己提个醒：AI部分不要贪大。做语音问诊、做医疗问答机器人、做医学影像识别，这些方向听上去高级，但本科毕设周期内很难交付完整，论文里也讲不清模型细节。做一个“慢病风险预测+规则化健康建议”的轻量AI模块，反而能扎扎实实讲透。

2. 技术选型分析：Vue 3做前端、Spring Boot做后端、AI服务单独拆

2.1 前端为什么用Vue而不是React

很多同学在选题时纠结前端框架，我给出的建议通常很直接：团队里没人的情况下就选Vue。理由不是React不行，而是这个项目的规模和目标决定了Vue的开发效率更高。

第一，Vue模板语法对表单、表格这类密集交互的界面更友好，组件结构直观，调试成本低；第二，Element Plus组件库本身就是为后台管理系统设计的，表格分页、表单弹窗、树形控件直接拿来用，不用自己造轮子；第三，中文社区资料非常丰富，一个“表格分页+搜索”的问题能搜出几十篇有效答案；第四，Vite构建工具的启动速度非常快，现场演示时改代码热更新基本无感。

前端目录建议按模块划分，不要把所有页面堆在views里：

src/ api/ # axios接口封装，按模块拆分文件 assets/ # 静态资源 components/ # 通用组件（图片上传、文件导入等） router/ # 路由配置，带权限拦截 store/ # Pinia状态管理（用户信息、菜单权限） views/ resident/ # 档案管理页 health/ # 体检数据页 assess/ # AI评估页 system/ # 系统管理页

顺序别看乱，实际开发中越早把目录规范定好，后面写代码越省心。很多学生一开始图方便把文件乱放，最后光找文件就能耽误一天。

axios请求需要统一封装，拦截器里带上token和错误提示：

import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { config.headers['Authorization'] = localStorage.getItem('token') return config }) service.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { router.push('/login') } return Promise.reject(error) } )

2.2 AI功能选“轻量可解释”路线的三个理由

这个项目的AI部分最容易走偏。不少人一听到“AI功能”就想到调用大模型接口做智能问答，其实那个方案在毕设里风险很高：接口依赖外部服务，演示时断网就瘫了；论文里没法讲清楚模型训练过程；答辩时导师问“这个模型你怎么改的”，答案是“商家平台配置”，场面会很尴尬。

所以我给A同学定的方案是“规则引擎+机器学习模型”组合，不是大模型，理由有三点。

第一，规模匹配。社区体检数据的本质是结构化表格数据，不是长文本，一个几百条样本的训练集就足够支撑随机森林这类模型跑出稳定结果。第二，可解释性。风险预测结果可以输出命中特征和概率区间，社区医生看到的是“收缩压156mmHg超标、年龄68岁、BMI 27.1超标，综合风险等级中高”，而不是一个黑盒。第三，实验可复现。整个训练过程在本地用Scikit-learn就能完成，不需要GPU，不依赖第三方服务，代码量也刚刚好适合写进论文。

2.3 完整技术栈与项目目录结构

这个系统的技术栈是一个典型的“毕设最优解”组合：

部署时三端分开：前端跑在5173端口，后端跑在8080端口，AI推理服务单独跑在8001端口，前端通过Vite代理转发后端接口，后端通过HTTP调用AI服务。这条链路在论文架构图里画出来非常清晰：一个请求从浏览器到后端再到AI服务，三个进程各司其职。

用FastAPI把AI服务单独拆出来的好处是，训练和部署解耦，模型可以离线反复调，不影响主系统开发进度。这也是我反复强调的一点：AI模块一定要做成独立服务，不要直接把Python代码塞进Spring Boot里，分开之后两边改起来都轻松。

3. 核心实现过程：从健康档案到AI风险评估的完整链路

3.1 健康档案模块：索引查询、生命周期状态与Excel导入

档案模块是所有业务的基础，数据表设计决定了后续模块好不好做。居民档案表我建议至少包含这些字段：

CREATE TABLE resident ( id BIGINT PRIMARY KEY AUTO_INCREMENT, id_card VARCHAR(18) UNIQUE NOT NULL COMMENT '身份证号', name VARCHAR(50) NOT NULL, gender TINYINT COMMENT '0男1女', birth_date DATE, phone VARCHAR(20), address VARCHAR(200), height DECIMAL(5,2), weight DECIMAL(5,2), bmi DECIMAL(4,2), chronic_disease VARCHAR(100) COMMENT '慢病标签', allergy_history VARCHAR(200), status TINYINT DEFAULT 1 COMMENT '1在管0注销', created_at DATETIME, updated_at DATETIME );

身份证号加唯一索引是一条很关键的业务规则。社区建档时同一个居民可能被重复录入两次，不加唯一索引就会出现一人多档的脏数据，后续所有统计都会失真。

页面端是典型的“搜索条件+表格+分页”结构。搜索条件包括姓名、身份证号、慢病标签、年龄段。使用MyBatis Plus的LambdaQueryWrapper做条件拼装，注意慢病标签的筛选字段不要直接拼进SQL，一定要走参数绑定。

Excel批量导入是社区场景的刚需。很多社区卫生中心的体检数据本身就在Excel里，辛辛苦苦整理成几百行数据，如果系统不支持导入，录入工作量会劝退使用者。导入使用EasyExcel，先做表头和必填项校验，再校验手机号、身份证号格式，最后批量插入数据库。数据量几千条时，一条条insert速度很慢，必须用批量插入，实测下来秒级完成。导入结束后弹出结果提示：成功X条、失败Y条，并支持下载错误清单。

3.2 体检数据看板：ECharts趋势图与异常标红

体检记录表是AI风险评估的直接数据源，字段设计要和模型特征对齐：

CREATE TABLE health_check_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, resident_id BIGINT NOT NULL, check_date DATE, systolic_bp INT COMMENT '收缩压mmHg', diastolic_bp INT COMMENT '舒张压mmHg', fasting_glucose DECIMAL(4,2) COMMENT '空腹血糖mmol/L', total_cholesterol DECIMAL(4,2), triglyceride DECIMAL(4,2), hdl DECIMAL(4,2), ldl DECIMAL(4,2), diagnosis_notes VARCHAR(500), create_time DATETIME );

看板页面的核心是趋势图。选中某个居民后，ECharts折线图展示近几次体检的收缩压、舒张压、空腹血糖变化，并用markLine在图上标出正常范围上下限。社区医生不需要看数字列表，眼睛扫一眼折线就知道这位居民的血压是不是在持续爬升。这就是可视化的价值。

异常标红的逻辑不要散落在页面里写死。建议抽象成一个指标判断工具类，比如：

public class IndicatorChecker { // 收缩压 ≥ 140 或 舒张压 ≥ 90 判为偏高 public static boolean isHighBloodPressure(int systolic, int diastolic) { return systolic >= 140 || diastolic >= 90; } }

把阈值集中管理，原因有两个：第一，不同社区可能采用不同标准，集中配置方便调整；第二，论文里写“参考中国高血压防治指南判定标准”时，你有一个能自圆其说的出处。表格里异常指标行用红色字体标出，附上“偏高/偏低”标签，社区医生处理起来效率高得多。

3.3 AI风险预测模块：数据预处理、模型训练与模型部署

这个模块是整个系统的技术核心，也是论文里唯一需要“做实验”的地方。先说明白思路：用历史体检记录作为训练数据，特征取年龄、BMI、收缩压、舒张压、空腹血糖、总胆固醇、甘油三酯、高密度脂蛋白、低密度脂蛋白、是否吸烟、是否饮酒共11个字段，标签是“是否属于高风险人群”——定义可以为是否发生过心脑血管相关异常记录，或长期多项指标超标。

拿到训练数据后，预处理三个关键动作：

第一，缺失值处理。体检数据总有空值，比如某人没查血脂，甘油三酯就是空。处理方式用中位数填充而不是均值填充，因为血压、血糖指标容易出现极端值，均值会被极端值拉偏，中位数更稳健。

第二，标准化。树模型其实不太依赖标准化，但论文里如果想同时对比逻辑回归，就必须先做StandardScaler，不然逻辑回归收敛会出问题。

第三，样本平衡。高风险人群数量通常远少于低风险人群，模型会倾向预测多数类。处理方案是训练时给RF传入class_weight='balanced'参数，或者提前用SMOTE过采样。

模型训练代码示例：

from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report, roc_auc_score import pandas as pd df = pd.read_csv('health_data.csv') X = df[['age', 'bmi', 'systolic_bp', 'diastolic_bp', 'fasting_glucose', 'total_cholesterol', 'triglyceride', 'hdl', 'ldl', 'smoker', 'alcohol']] y = df['high_risk'] X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42, stratify=y) model = RandomForestClassifier( n_estimators=200, max_depth=6, class_weight='balanced', random_state=42) model.fit(X_train, y_train) y_pred = model.predict(X_test) print(classification_report(y_test, y_pred)) print('AUC:', roc_auc_score(y_test, model.predict_proba(X_test)[:, 1]))

写论文时一定要做模型对比。至少跑逻辑回归和随机森林两个模型，输出混淆矩阵、ROC曲线、特征重要性条形图。我印象很深的是，某次答辩评委直接指着特征重要性图问“哪个特征对预测影响最大”，因为论文里明确写了收缩压和年龄排在前两位，现场回答非常顺。

模型部署建议用FastAPI独立服务。先把训练好的模型用joblib保存，再写一个预测接口：

from fastapi import FastAPI from pydantic import BaseModel import joblib app = FastAPI() model = joblib.load('risk_model.joblib') class HealthFeature(BaseModel): age: float bmi: float systolic_bp: float diastolic_bp: float fasting_glucose: float total_cholesterol: float triglyceride: float hdl: float ldl: float smoker: int alcohol: int @app.post('/predict') def predict(f: HealthFeature): sample = [[f.age, f.bmi, f.systolic_bp, f.diastolic_bp, f.fasting_glucose, f.total_cholesterol, f.triglyceride, f.hdl, f.ldl, f.smoker, f.alcohol]] prob = model.predict_proba(sample)[0][1] risk = '高风险' if prob >= 0.8 else ('中风险' if prob >= 0.5 else '低风险') return {'risk_level': risk, 'probability': round(prob, 4)}

Spring Boot后端通过RestTemplate调用这个服务：

RestTemplate restTemplate = new RestTemplate(); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); Map<String, Object> params = new HashMap<>(); params.put("age", 68); params.put("bmi", 27.1); params.put("systolic_bp", 156); // 其余特征字段按序补齐 HttpEntity<Map<String, Object>> entity = new HttpEntity<>(params, headers); ResponseEntity<Map> resp = restTemplate.postForEntity( "http://localhost:8001/predict", entity, Map.class);

有一个必须注意的坑：前端传给Java后端的字段顺序、Java传给Python服务的字段顺序、模型训练时的特征列顺序，三处必须完全一致。顺序错了，模型拿到手的特征语义全变，预测结果完全不可信。最稳妥的解法是推理服务内部固定一个特征顺序列表，不依赖请求里的字段枚举顺序。

3.4 健康建议与提醒：规则引擎与服务推送

风险预测出来只完成了一半。如果没有后续动作，AI模块就只是一个“算概率的计算器”。健康建议模块的设计思路是：命中哪些异常指标，就拼接对应的建议文案；AI预测出高风险，再叠加“尽快复诊”等提示。

建议内容存在health_advice表里，由系统管理员后台维护。比如收缩压偏高时拼接一条“建议每日早晚各测一次血压，减少钠盐摄入，规律服用降压药”；空腹血糖偏高时拼接“建议控制主食量，增加蔬菜摄入，连续三天监测空腹血糖”。这种规则组合的文案比较容易让居民看懂，也方便社区医生后续审核。

提醒服务用一个定时任务实现，每天19点扫描一次慢病随访表，把“距离上次随访超过90天”的患者整理出来，在系统内生成待办提醒。短信提醒需要接入第三方网关，毕设里没有必要，站内信已经足够演示完整流程。这个设计的好处是真实：社区随访本来就是周期性工作，定时任务就是技术上的自然表达。

4. 论文怎么写、PPT怎么讲：毕设文档与答辩经验

4.1 论文结构：需求分析要画用例图，AI部分要有实验对比

毕业设计论文有固定套路，完成度高低全看细节。按标准模板建议分七章：

1. 绪论：背景与意义、国内外研究现状、论文组织结构
2. 相关技术概述：Vue 3、Spring Boot、MySQL、Scikit-learn
3. 系统需求分析：功能需求、非功能需求、用例图、业务流程图
4. 系统设计：总体架构图、功能模块设计、数据库ER图、AI模型方案
5. 系统实现：各模块页面截图、核心代码片段、运行效果说明
6. 系统测试：功能测试用例表、AI模型评估表、兼容性测试
7. 总结与展望：成果归纳、不足、后期规划

需求分析这章是很多学生的重灾区。用例图一定要和系统菜单对应，别拿了网上的通用医疗系统用例图直接改个名字交差。我见到最多的问题就是：用例图里有“药品管理”，系统里根本没有这个界面，答辩现场一翻就穿帮。业务流程图可以画“建档→体检→风险评估→随访提醒”这条主线，一幅图画清楚。

实现章不要整段贴200行代码，截取核心片段加简短说明就够了。每张页面截图必须配一段“功能描述+操作方式+预期结果”，这部分写扎实了，论文的页数字数都好看，答辩时讲起来也有依据。

AI实验部分单独做成一张对比表，这是全文的核心数据亮点：

实验数据必须是真实跑出来的。理论上随机森林会略优，解释时不要只说“RF更好”，加上一句“体检数据中多个指标存在非线性关系，随机森林能更好地捕捉这些交互影响”，论述立刻有深度。

4.2 PPT设计：核心演示时序与设计套路

所谓“精美PPT”，审阅人关注点不是动画花哨，而是结构清楚、能用图片说清系统全貌。建议控制在18—22页：封面、目录、背景与意义、相关技术、需求分析、系统设计、核心功能演示、AI实验、系统测试、总结展望、致谢。

每个页面只讲一件事。架构图、ER图、功能结构图这“三张图”是PPT的骨架，必须做得干净。“功能展示”页面直接放系统截图，不要贴大段代码。配色控制在两种主色内，正文不小于16号字，专业术语首次出现加中文注释。

答辩现场演示建议提前准备三组数据串成一条故事线：第一组是一个正常档案，演示查询和基本信息；第二组是血压持续上升的档案，演示趋势图和异常标红；第三组是AI判定为中高风险的档案，演示风险评估和建议推送。按这条线走下来，系统所有亮点自然串联，比随机点几个页面要有效得多。

4.3 答辩高频问题与应对思路

答辩前把下面这些问题提前过一遍，心里就有底了：

这些回答思路要提前埋进论文里。比如论文里写了“采用class_weight='balanced'处理样本不均衡”，答辩时就可以直接引用；论文里单独写一小段“数据脱敏与隐私保护”，回答隐私问题时就有内容可讲。

5. 常见问题与避坑速查：实地调试过的典型坑

5.1 环境搭建与前后端联调相关

毕设翻车最多的场景集中在环境搭建和联调阶段，提前踩过的坑都列在这里：

有一条印象很深的坑：Vite代理路径和后端@RequestMapping前缀大小写不一致，接口一直返回404，排查了两个小时，最后发现只是路径里少了一个斜杠。这种问题没有任何技术含量，但极其消耗情绪，建议联调第一天就把代理配置反复确认好。

5.2 AI模型部署相关

AI模块的坑比常规Web开发多一层，主要集中在模型版本、特征顺序和编码问题上。

Scikit-learn版本不匹配是头号问题。训练环境装的0.24，部署环境升级到1.2，joblib加载旧模型时大概率报错。解决办法是写死requirements.txt，部署环境严格按照文件安装，不轻易升级。模型重新训练后记得覆盖导出文件，不然就会出现“新代码配旧模型”的低级事故。

特征顺序问题前面已经强调过。还有一个容易被忽略的细节：训练数据里的分类特征（比如吸烟、饮酒）如果原始数据是“是/否”文本，模型训练前转成了1/0整数，部署时前端传过来的值也必须是整数0或1，传成字符串“1”就可能被pandas解析成完全不同的类型，导致预测崩溃。

还有数据的缺失值处理：Excel导入时漏掉某个指标字段，整行数据传到AI服务后模型预测接口会直接报错。正确做法是接口层做兜底校验，空值直接填充该特征的训练集中位数，不要让前端承担这个责任。

5.3 交付资料规范：源码、数据库脚本、说明文档

毕业设计交上去的不只是能跑的代码，而是一整套完整资料。源码要分目录整理，根目录必须有README，写清楚启动步骤、默认账号密码、测试数据说明。数据库既要给建库SQL，也要给带测试数据的SQL脚本，并标注MySQL版本。

项目根目录里放一份“启动说明.md”，按顺序写清楚四件事：初始化数据库、启动AI推理服务、启动后端、启动前端。每一次演示翻车都是启动顺序不对造成的，这个文档就是在给自己留后路。

还有一个在答辩时很加分的交付细节：源码里的git提交记录要分阶段留，不要只在最后一次性提交完。我见过一个学生整个仓库只有一个commit，老师一眼看穿没有过程。改成“初始化框架→完成档案模块→完成体检模块→接入AI推理服务→优化图表展示→完善权限控制”的提交历史，反而给导师一种“过程完整、思路清晰”的好印象。

做这类带AI功能的软件工程毕业设计，我自己最深的体会是：不要试图在每个环节都做到极致，把“管理、服务、AI”三条线分别稳住就够了。管理线保证系统完整可用，可视化线保证展示效果好，AI线保证论文有研究价值。三条线都站稳，源码、论文和PPT的框架就会很自然地立起来。

如果你正在做类似的社区健康管理系统，我的建议是先把AI推理服务单独跑通，再回头联调前端页面，模型部署问题千万别拖到最后才处理。后面想扩展的话，可以把指标异常检测做成动态阈值调整，把建议文案升级成在线规则库，这些都是在现有架构上顺手就能加的功能。项目本身不难，难的是把每个环节都认真打磨到位。