基于 SpringBoot + Vue3 的社区医院管理系统实战（含 AI 问诊 + 电子病历 PDF 导出）

文章目录

• 基于 SpringBoot + Vue3 的社区医院管理系统实战（含 AI 问诊 + 电子病历 PDF 导出）
• • @[toc]
  • 一、项目背景与意义
  • 二、项目目标与建设范围
  • • 2.1 项目目标
    • 2.2 项目边界
  • 三、技术栈与选型说明
  • • 3.1 后端技术栈
    • 3.2 前端技术栈
    • 3.3 AI 集成
  • 四、系统架构设计
  • • 4.1 总体架构图
    • 4.2 分层架构说明
    • 4.3 前端架构
  • 五、功能模块设计
  • • 5.1 用户端模块
    • 5.2 医生端模块
    • 5.3 管理员端模块
  • 六、系统用例分析（可直接用于毕业论文）
  • • 6.1 参与者
    • 6.2 用例总表
    • 6.3 核心用例规约示例（UC-10 医生录入病例）
  • 七、关键业务流程设计
  • • 7.1 登录鉴权流程
    • 7.2 挂号到接诊闭环流程
    • 7.3 AI 问诊流程
    • 7.4 病历 PDF 导出流程
  • 八、数据库设计（核心）
  • • 8.1 数据表结构
    • 8.2 表关系
    • 8.3 状态机设计
  • 九、核心实现细节
  • • 9.1 权限控制
    • 9.2 挂号规则校验
    • 9.3 医生录入病例事务一致性
    • 9.4 AI 问诊稳定性策略
    • 9.5 PDF 导出可用性策略
  • 十、接口清单（核心）
  • • 10.1 认证
    • 10.2 用户
    • 10.3 医生
    • 10.4 管理员
  • 十一、系统测试设计
  • • 11.1 测试范围
    • 11.2 典型测试用例
    • 11.3 测试结论
  • 十二、部署运行说明
  • • 12.1 基础环境
    • 12.2 数据库初始化
    • 12.3 手动启动
    • 12.4 一键脚本
  • 十三、页面效果展示（替换为你自己的截图）
  • • 13.1 登录页
    • 13.2 系统首页
    • 13.3 在线挂号
    • 13.4 我的挂号
    • 13.5 AI 问诊
    • 13.6 电子病历
    • 13.7 PDF 导出效果
    • 13.8 医生工作台
    • 13.9 今日患者管理
    • 13.10 管理员看板
    • 13.11 科室管理
    • 13.12 医生管理
    • 13.13 用户管理
  • 十四、项目难点与优化方向
  • • 14.1 本项目实现过程中的难点
    • 14.2 可继续优化的方向
  • 十五、总结

一、项目背景与意义

在社区医院日常业务中，常见的痛点主要有三类：

1. 挂号流程线上线下割裂，患者需要反复排队、电话沟通，体验差。
2. 医生接诊状态不透明，患者不知道“何时轮到我”，医院也难做过程监管。
3. 病历数据留存分散，复诊时信息不完整，难以形成结构化的就医闭环。

为了解决上述问题，我基于 SpringBoot + Vue3 设计并实现了一个三角色协同系统，覆盖：

1. 用户端：在线挂号、我的挂号、AI 问诊、电子病历、个人中心。
2. 医生端：今日患者管理、接诊流转、病例录入、工作台统计。
3. 管理端：科室管理、医生管理、用户管理、挂号/病例监管、运营看板。

该项目特别适合作为本科毕业设计，因为它同时具备：

1. 完整业务闭环（挂号 -> 接诊 -> 病历 -> 导出）。
2. 主流工程技术栈（Java + Vue 前后端分离）。
3. 可扩展的 AI 能力（DeepSeek 问诊）。
4. 可展示的可视化效果（ECharts 看板）。

---

二、项目目标与建设范围

2.1 项目目标

1. 建立标准化门诊预约与接诊协作流程。
2. 实现基于角色的权限控制，保证数据边界安全。
3. 提供智能问诊入口，辅助患者快速定位就诊科室。
4. 提供电子病历 PDF 导出能力，满足归档与复诊场景。
5. 给管理员提供可视化运营监控能力。

2.2 项目边界

系统内：

1. 用户注册登录、JWT 鉴权、角色路由守卫。
2. 挂号业务流转、医生接诊、病例录入、病历导出。
3. 管理后台主数据维护和统计分析。

系统外：

1. DeepSeek API（AI 问诊建议）。
2. 操作系统层面的部署启动与停止（脚本支持）。

---

三、技术栈与选型说明

3.1 后端技术栈

1. Spring Boot 3：快速构建 REST 服务，生态成熟。
2. MyBatis：SQL 可控，便于复杂联表和业务优化。
3. JWT：轻量无状态鉴权，适合前后端分离项目。
4. MySQL 8：关系型数据稳定，适合结构化业务数据。
5. iText PDF：用于电子病历结构化导出。

3.2 前端技术栈

1. Vue3 + Composition API：逻辑聚合能力强，代码组织清晰。
2. Vite：开发热更新快，构建效率高。
3. Pinia：轻量状态管理，适配 Vue3。
4. Element Plus：后台类系统开发效率高。
5. ECharts：图表能力强，适合看板展示。

3.3 AI 集成

1. DeepSeek API：用于智能问诊问答。
2. 后端统一拼接 System Prompt 和历史上下文，控制模型输出结构。

---

四、系统架构设计

4.1 总体架构图

4.2 分层架构说明

1. Controller 层：接收请求、参数绑定、响应封装。
2. Service 层：业务规则实现、事务控制、异常治理。
3. Mapper 层：持久化访问，联表查询和状态更新。
4. DTO/VO 层：请求响应模型隔离，提升可维护性。
5. Security 层：JWT 解析、AuthContext 注入、角色鉴权。

4.3 前端架构

1. Router：基于角色元信息控制访问路由。
2. Store：统一管理 token/user 数据，支持登录态持久化。
3. API 模块：按角色分组接口，职责清晰。
4. 视图层：用户/医生/管理员模块分目录管理。

---

五、功能模块设计

5.1 用户端模块

1. 在线挂号：选择科室、医生、日期、时段并提交症状。
2. 我的挂号：查看状态（PENDING/IN_PROGRESS/COMPLETED/CANCELED），待接诊可取消。
3. AI 问诊：微信式聊天窗口，支持历史会话切换。
4. 电子病历：查看历史病例并导出 PDF。
5. 个人中心：维护姓名、手机号、性别、年龄、密码。

5.2 医生端模块

1. 工作台：今日总患者、待接诊、接诊中、已完成统计。
2. 今日患者：按队号查看排队患者，一键开始接诊。
3. 病例录入：录入诊断、医嘱、处方，提交后挂号状态自动完成。

5.3 管理员端模块

1. 运营看板：总量指标 + 近 7 天趋势 + 科室分布。
2. 科室管理：增删改查科室主数据。
3. 医生管理：维护医生账号与医生档案。
4. 用户管理：按角色筛选并进行账号治理。
5. 挂号/病例管理：全局业务巡检与追溯。

---

六、系统用例分析（可直接用于毕业论文）

6.1 参与者

1. 游客（未登录）
2. 普通用户（USER）
3. 医生（DOCTOR）
4. 管理员（ADMIN）
5. 外部 AI 服务（DeepSeek）

6.2 用例总表

用例ID	用例名称	参与者
UC-01	用户注册	游客
UC-02	用户登录	游客
UC-03	在线挂号	用户
UC-04	取消挂号	用户
UC-05	AI 智能问诊	用户
UC-06	查询我的病例	用户
UC-07	导出病例 PDF	用户
UC-08	医生查看今日患者	医生
UC-09	医生开始接诊	医生
UC-10	医生录入病例	医生
UC-11	管理员维护科室	管理员
UC-12	管理员维护医生	管理员
UC-13	管理员维护用户	管理员
UC-14	管理员查看运营看板	管理员

6.3 核心用例规约示例（UC-10 医生录入病例）

前置条件：

1. 医生已登录。
2. 存在状态为 IN_PROGRESS 的挂号记录。

主流程：

1. 医生在病例录入页选择挂号单。
2. 输入诊断结果、医嘱、处方。
3. 提交病例。
4. 系统保存病例并将挂号状态更新为 COMPLETED。

异常流程：

1. 挂号不存在或不属于当前医生 -> 返回“挂号记录不存在”。
2. 已存在病例 -> 返回“该挂号已录入病例”。
3. 诊断或医嘱为空 -> 参数校验失败。

后置条件：

1. 病例归档成功。
2. 患者在电子病历页面可查看并导出。

---

七、关键业务流程设计

7.1 登录鉴权流程

7.2 挂号到接诊闭环流程

7.3 AI 问诊流程

7.4 病历 PDF 导出流程

---

八、数据库设计（核心）

8.1 数据表结构

1. sys_user：用户账号与身份信息。
2. department：科室主数据（名称、说明、位置）。
3. doctor：医生档案（职称、擅长、挂号费），关联 sys_user。
4. registration：挂号记录（就诊日期、时段、排队号、状态、症状）。
5. medical_record：病例记录（诊断、医嘱、处方）。

8.2 表关系

1. doctor.user_id -> sys_user.id
2. registration.user_id -> sys_user.id
3. registration.doctor_id -> doctor.id
4. registration.department_id -> department.id
5. medical_record.registration_id -> registration.id
6. medical_record.user_id -> sys_user.id
7. medical_record.doctor_id -> doctor.id

8.3 状态机设计

挂号状态流转：

1. 新建挂号：PENDING
2. 医生开始接诊：IN_PROGRESS
3. 病例录入完成：COMPLETED
4. 用户主动取消（仅待接诊）：CANCELED

---

九、核心实现细节

9.1 权限控制

后端通过角色注解进行接口保护，前端通过路由元信息进行页面级拦截，双重保障。

核心思路：

1. 后端校验“能不能访问”。
2. 前端控制“看不看得见”。

9.2 挂号规则校验

在创建挂号时，必须同时满足：

1. 医生存在
2. 科室存在
3. 医生与科室匹配
4. 就诊日期 >= 当天
5. 计算队号（同医生+同日期+同时段）

9.3 医生录入病例事务一致性

录入病例时采用事务控制：

1. 插入病例 medical_record
2. 更新挂号状态 registration.status = COMPLETED

两步任意一步失败都会回滚，保证数据一致性。

9.4 AI 问诊稳定性策略

1. 对历史消息截断（只保留最近 N 条），控制 token 成本。
2. 对返回结果做 JSON 解析兜底。
3. 若 DeepSeek 异常，前端显示“服务繁忙”而不是页面报错。

9.5 PDF 导出可用性策略

1. 导出前先做 userId 归属校验，防越权。
2. 采用结构化模板输出，便于医院归档。
3. 嵌入中文字体，避免不同阅读器出现缺字问题。

---

十、接口清单（核心）

10.1 认证

1. POST /api/auth/login
2. POST /api/auth/register
3. GET /api/auth/me

10.2 用户

1. GET /api/user/profile
2. PUT /api/user/profile
3. POST /api/user/registrations
4. GET /api/user/registrations
5. PUT /api/user/registrations/{id}/cancel
6. POST /api/user/ai-consult
7. GET /api/user/records
8. GET /api/user/records/{id}/export

10.3 医生

1. GET /api/doctor/dashboard
2. GET /api/doctor/registrations/today
3. PUT /api/doctor/registrations/{id}/start
4. POST /api/doctor/records

10.4 管理员

1. GET /api/admin/dashboard
2. GET/POST/PUT/DELETE /api/admin/departments
3. GET/POST/PUT/DELETE /api/admin/doctors
4. GET/DELETE /api/admin/users
5. GET /api/admin/registrations
6. GET /api/admin/records

---

十一、系统测试设计

11.1 测试范围

1. 功能测试：业务流程是否正确。
2. 权限测试：越权访问是否被拦截。
3. 兼容测试：主流浏览器与不同分辨率。
4. 性能测试：关键接口响应时间。

11.2 典型测试用例

用例ID	测试点	步骤	预期结果
TC-001	正常登录	admin/123456 登录	登录成功并进入首页
TC-002	密码错误	admin/错误密码	返回错误提示
TC-003	挂号日期校验	选择昨天日期提交	提示“就诊日期不能早于今天”
TC-004	医生科室不匹配	选择错误科室组合	返回匹配错误
TC-005	取消非 PENDING	取消接诊中挂号	返回“当前状态无法取消”
TC-006	医生开始接诊	点击一键接诊	状态变为 IN_PROGRESS
TC-007	病例重复录入	同挂号再次录入	返回“该挂号已录入病例”
TC-008	导出 PDF	点击导出按钮	下载成功、可打开、中文正常
TC-009	用户越权	USER 访问 /api/admin/users	返回无权限
TC-010	导出他人病例	A 用户导出 B 病例	返回 404/无权限

11.3 测试结论

在当前版本中，核心闭环流程、权限边界与 PDF 导出能力均通过测试，系统可满足课程设计/毕业设计答辩演示要求。

---

十二、部署运行说明

12.1 基础环境

1. JDK 17
2. Maven 3.9+
3. Node.js 18+/20
4. MySQL 8.x

12.2 数据库初始化

source backend/src/main/resources/sql/schema.sql;

12.3 手动启动

# 启后端
cd backend
mvn spring-boot:run

# 启前端
cd frontend
npm install
npm run dev

12.4 一键脚本

# macOS / Linux
chmod +x start-all.sh stop-all.sh
./start-all.sh
./stop-all.sh

Windows 直接双击：

1. start-all.bat
2. stop-all.bat

---

十三、页面效果展示（替换为你自己的截图）

下列位置直接换成你的图床链接即可。

13.1 登录页

13.2 系统首页

13.3 在线挂号

13.4 我的挂号

13.5 AI 问诊

13.6 电子病历

13.7 PDF 导出效果

13.8 医生工作台

13.9 今日患者管理

13.10 管理员看板

13.11 科室管理

13.12 医生管理

13.13 用户管理

---

十四、项目难点与优化方向

14.1 本项目实现过程中的难点

1. 多角色权限与前后端一致性控制。
2. 挂号状态流转与事务一致性保障。
3. AI 返回内容的不确定性解析与兜底。
4. PDF 中文字体在不同阅读器的兼容问题。

14.2 可继续优化的方向

1. 增加医生排班与号源库存模块。
2. 引入 Redis 做热点缓存与限流。
3. 增加消息通知（短信/站内信）。
4. 引入自动化测试（接口 + E2E）。
5. 容器化部署（Docker + Nginx + CI/CD）。

---

十五、总结

该系统完整覆盖了社区医院门诊管理的关键环节，既能展示清晰的业务价值，也能体现规范的软件工程实现能力。
作为毕业设计，它具有以下优点：

1. 业务链路完整，答辩演示清晰。
2. 技术栈主流，代码结构规范。
3. 功能点丰富，含 AI 与 PDF 两个加分项。
4. 文档和部署齐全，具备可交付性。

如果你也在做 Java + Vue 毕设，这个项目是一个非常稳妥、可扩展、可落地的方向。