简介：这是一套基于 Vue 与 SpringBoot 构建的智慧医院就诊系统完整毕业设计资源包，面向医疗信息化方向的高校学生、Java 全栈开发者及医院信息系统技术人员。系统覆盖预约挂号、智能问诊、医生工作台、科室排班、患者服务、系统日志与权限管理等核心模块，并将 DeepSeek 大语言模型融入诊疗流程，创新实现症状自查、结构化电子病历生成与临床建议辅助，有助于减少医生非临床工作负担。资源共 710 个文件，以 Java 源码、Vue 组件、JavaScript 脚本、CSS 样式、SQL 数据库脚本及说明文档为主，另含图片和动态演示素材，压缩包约 10.08MB，目录结构清晰，便于按模块阅读和二次开发。当前已有 243 人学习，适合用于理解医院就诊业务闭环，也可作为毕业设计答辩演示、功能扩展或代码重构的参考基础。
1. 把 Vue+SpringBoot 就诊系统讲透：DeepSeek 症状自查与电子病历生成的落地方案
做智慧医院就诊系统，最难的不是挂号、排队叫号那些常规模块，而是“怎么让系统看起来真的懂医疗”。大部分毕业设计开源项目止步于 CRUD 增删改查，界面再华丽，业务逻辑还是“查表 + 状态机”。这套基于 Vue 3 + SpringBoot 3 的就诊系统源码，真正不一样的地方在于接入了 DeepSeek 大语言模型，把症状自查、结构化电子病历生成、临床建议辅助这三件事做成了可运行的功能，而不是 PPT 上的概念。我拆完整个前后端代码和数据库脚本后确认，它适合两类人：一类是正在做毕设但不想只交“管理系统”的学生，另一类是准备把 LLM 塞进传统业务系统、想少走弯路的 Java 工程师。你能直接看到模型接口怎么封装、业务层怎么兜底、前端流式输出怎么接，这比从头读文档高效太多。
整套系统覆盖了患者端、医生端和管理员端三个角色，核心链路是“患者描述症状 → DeepSeek 返回候选疾病和问诊建议 → 医生选择生成结构化电子病历 → 系统给出临床建议”。源码里带有完整数据库建表脚本（MySQL），包含用户表、预约表、病历表、药品表、科室表等，视图和存储过程也有几个，能直接跑通预约挂号、门诊就诊、病历归档的闭环。我前后花了一个多星期把每个模块从“能跑”调试到“能讲”，下面这篇笔记按资源是什么、结构怎么拆、DeepSeek 怎么接、病历和症状自查怎么落地、坑在哪、怎么把系统做亮这几个顺序，把这份资源彻底讲清楚。
2. 系统架构与代码包结构：先看清前后端边界和 LLM 的介入位置
2.1 三层架构里的模型调用设计：为什么是 Vue3 + SpringBoot 而不是单体模板引擎
传统就诊系统常做在 JSP + Servlet 或 Thymeleaf 模板里，页面跳来跳去，前后端耦合严重。这套源码采用前后端分离，SpringBoot 提供 RESTful API，Vue 3 通过 axios 发起请求。这样设计不是图“时髦”，而是因为接入 DeepSeek 后，前端需要处理流式输出和异步状态，模板引擎在这种交互下会非常别扭。
后端模块我拆开看，主要分这几块：
- authentication：基于 JWT 的登录鉴权，医生和患者走不同角色拦截器
- business：挂号预约、分诊、收费、药房等传统模块
- ai：DeepSeek 调用封装，包括 prompt 构建、响应解析、异常兜底
- medical：病历管理、诊断建议、检验报告的结构化存储
单看模块划分不稀奇，关键在于 ai 模块的“隔离性”。项目把大模型调用单独放在一个 service 里，前端所有 AI 功能都经由/api/ai/*统一入口进入，不进业务表直接写数据库。这样做有实际意义：模型输出是不可控的，万一某次返回了非 JSON 内容，你不会把脏数据污染到病历表里；前端也可以根据接口状态单独展示“AI 生成中”的 Loading，而不会拖慢挂号接口。
前端项目结构里，重点看src/api和src/views/ai两个目录。前者是接口统一封装层，后者是症状自查和病历生成的前端交互页面。Vue 3 用组合式 API 写逻辑，状态管理只用了一个极简的 pinia store 来存用户信息和 JWT，没有过度设计。
提示：资源里自带的 README 有早期版本说明，里面“引入 DeepSeek”这几个字，实际实现比说明文档多了不少细节，建议以源码实际行为为准。
2.2 数据库表设计：病历表、用户表、症状表如何支撑“结构化”需求
结构化电子病历的“结构化”，不是指前端把文本塞进textarea就叫结构化，而是数据库里要有明确的字段承接不同粒度的医疗数据。打开sql目录里的建表脚本，核心表有这么几张：
user：患者和医生共用一张表，用role字段区分，存姓名、手机号、加密后的登录密码department：科室表，关联医生排班appointment：预约挂号表，包含时间槽和就诊状态medical_record：病历主表，涵盖主诉、现病史、既往史、初步诊断、处理建议和开药信息symptom_check：症状自查记录表，存用户输入的自然语言症状文本和模型返回的结构化结果（JSON 字段）ai_log：AI 调用日志表，记每次请求的输入 token、输出 token 和耗时
这里的symptom_check和ai_log两张表是这套资源区别于普通管理系统的地方。symptom_check表里有一个result_json字段，类型用了TEXT，专门承接 DeepSeek 返回的嵌套 JSON 数据——包括候选疾病列表、匹配度评分、建议就诊科室。这不是偷懒的做法，因为模型输出结构不固定，用TEXT存 JSON 比强行拆几十个字段更现实，读取后再用 Jackson 解析成 Java 对象。
ai_log表值得一提：查问题的时候你能回看每一次模型调用，哪些 prompt 导致了 token 浪费、哪些输入让模型回复了非预期内容，一目了然。这是从业者的习惯，很多毕设根本没有这个表。
2.3 核心参数配置：application.yml 里的模型与数据库连接解读
后端src/main/resources/application.yml里，除了常规的 MySQL 数据源、Redis 配置、JWT 密钥，还有一个独立的deepseek配置段：
deepseek: api-key: ${DEEPSEEK_API_KEY:your-key-here} base-url: https://api.deepseek.com model: deepseek-chat max-tokens: 2048 temperature: 0.3 timeout: 60这段配置的意思是：API Key 通过环境变量DEEPSEEK_API_KEY注入，避免把密钥写死在代码里；base-url是 DeepSeek 官方接口地址；model指定使用deepseek-chat，这是 DeepSeek 对外提供的通用对话模型，支持显式上下文；max-tokens控制单次返回的最大 token 数，temperature=0.3是为了让输出更稳定、更少随机。医疗场景不像写诗，不需要高温度值，温度调低一点，模型输出的可预测性高很多；timeout设成 60 秒，是考虑到长文本病历生成时，模型推理时间可能超过普通 HTTP 请求的默认超时。
数据库连接部分你根据自己的 MySQL 版本改url、username、password就行。资源自带的是 MySQL 5.7 适用的建表语句，如果要跑在 MySQL 8.0+，注意默认密码插件不同，驱动版本选对即可。
3. DeepSeek 接入实战：从 HTTP 封装到流式输出的完整链路
3.1 AI 接口封装：用 WebClient 调 DeepSeek Chat Completion 接口
后端 AI 模块核心代码是封装了 DeepSeek 的 Chat Completion 接口。这里不用 RestTemplate，因为它是同步阻塞模型，高并发场景下容易吃满 Tomcat 线程。SpringBoot 3 自带的 WebClient 走响应式链路，单次调用不阻塞业务线程。下面这段是资源里DeepSeekClient.java的核心逻辑精简版：
@Service public class DeepSeekClient { private final WebClient webClient; private final DeepSeekProperties properties; public DeepSeekClient(DeepSeekProperties properties) { this.properties = properties; this.webClient = WebClient.builder() .baseUrl(properties.getBaseUrl()) .defaultHeader("Authorization", "Bearer " + properties.getApiKey()) .defaultHeader("Content-Type", "application/json") .codecs(configurer -> configurer.defaultCodecs().maxInMemorySize(10 * 1024 * 1024)) .build(); } public String chatCompletion(List<ChatMessage> messages) { Map<String, Object> requestBody = new HashMap<>(); requestBody.put("model", properties.getModel()); requestBody.put("messages", messages); requestBody.put("temperature", properties.getTemperature()); requestBody.put("max_tokens", properties.getMaxTokens()); requestBody.put("stream", false); return webClient.post() .uri("/chat/completions") .bodyValue(requestBody) .retrieve() .bodyToMono(String.class) .timeout(Duration.ofSeconds(properties.getTimeout())) .block(); } }逻辑说明：WebClient在构造时读配置里的地址和 Key，每次调用走POST /chat/completions。关键参数messages是数组，每个数组元素带role（system / user）和content，这是 DeepSeek 接口识别对话角色的标准方式。system角色用于设定 AI 行为，user角色用于传用户输入。stream=false表示非流式返回，整体把模型回答一次性拿回来，适合后期解析 JSON；如果做前端打字机效果，需要改用流式（stream=true，返回 SSE）并在前端用fetch读ReadableStream。
参数说明：maxInMemorySize别小看，不配的话默认 256KB，病历生成动辄几千 token 很容易超限报错，这也是一个典型坑。block()方法在 WebClient 里是同步等待，好在timeout兜底了最长等待时间。
3.2 Prompt 构建与业务解析：让模型按 JSON Schema 返回
调通接口只是第一步，真正难的是让模型输出“可解析的”结构化内容。源码里的PromptBuilder.java把整个 prompt 模板和 JSON Schema 固定下来，我看完之后强烈建议你直接抄这份模板，而不是自己现造。
public String buildSymptomCheckPrompt(String userInput) { return "你是一名具有丰富临床经验的导诊医生。" + "用户的症状描述如下：" + userInput + "请严格按以下 JSON 格式回复，不要输出任何多余文字：" + "{\"candidate_diseases\": [{\"disease_name\": \"疾病名称\", \"probability\": 0.85, \"department\": \"建议就诊科室\"}], " + "\"questions\": [\"为确认诊断，你需要追问患者的问题1\", \"追问问题2\"], " + "\"urgent\": false}"; }逻辑说明：system提示词固定了“医生”角色，user内容是对用户输入的封装。JSON Schema在 prompt 里的作用，是告诉模型输出结构——候选疾病数组带疾病名、概率、科室，追问问题数组，以及一个urgent布尔值表示是否需要立即急诊。这个结构要和前端 Vue 页面里的v-for列表相对应。
参数说明：probability用 0-1 小数，方便前端渲染百分比；urgent字段直接驱动分诊逻辑——为 true 时界面跳出红色警示条。candidate_diseases数组长度最好限制 3 到 5 个，太多会让患者焦虑，太少参考价值低。
解析端用 Jackson 把模型返回字符串反序列化成SymptomCheckResult对象，如果解析失败则走兜底逻辑。兜底逻辑很重要：模型偶尔会输出纯文本或 Markdown，直接转对象会抛异常，项目里专门写了一个fallbackParse()，把文本按回车拆成临时疾病描述，保证用户永远看得到反馈，而不是报错白屏。
3.3 流式输出的可选实现：SSE 让病历生成像“打字机”一样展示
资源里的非流式实现已经够完成毕设，但如果你想拔高亮点，可以把病历生成改成走 SSE（Server-Sent Events）。很多现场演示翻车，就是因为点击“生成病历”后界面白等 10 秒没反馈，评委以为系统死掉了。改成流式以后，用户能实时看到模型吐字，体验完全不同。
后端在DeepSeekClient里加一个流式方法，走WebClient的retrieve().bodyToFlux(String.class)，响应体是text/event-stream格式，前端用原生EventSource或fetch读流。核心改动就两点：请求体里stream=true，以及前端不再等完整 JSON，而是每收到一个data:块就 append 到页面。
但这有个代价——流式输出没法保证一次返回完整 JSON，所以自动生成结构化病历不能直接用流式结果入库，比较合理的做法是“流式展示 + 完整返回入库”双通道：前端展示用流式接口，落库用非流式接口二次调用。资源里非流式版本已经能跑通全流程，我建议先跑通再去改流式。
4. 症状自查与结构化电子病历生成：把模型输出变成业务资产
4.1 症状自查模块：前端输入与后端结果剪裁
前端页面SymptomCheck.vue的思路很简单：一个多行文本输入框，用户用自然语言描述症状，比如“最近三天头晕、头痛、恶心，伴随腹泻”，提交后后端把这段文本连同病历上下文拼进 prompt，发给 DeepSeek，返回候选疾病概率列表和追问问题。页面核心代码如下：
<template> <div class="symptom-check"> <el-input type="textarea" v-model="symptomText" placeholder="请描述你的症状，比如：头痛、发烧、咳嗽持续两天" :rows="4" /> <el-button type="primary" :loading="loading" @click="submitSymptom"> {{ loading ? 'AI 分析中…' : '开始自查' }} </el-button> <div v-if="checkResult" class="result-panel"> <div v-for="disease in checkResult.candidate_diseases" :key="disease.disease_name"> <span>{{ disease.disease_name }}</span> <span>{{ Math.round(disease.probability * 100) }}%</span> <el-tag>{{ disease.department }}</el-tag> </div> </div> </div> </template> <script setup> import { ref } from 'vue' import { checkSymptom } from '@/api/ai' const symptomText = ref('') const loading = ref(false) const checkResult = ref(null) async function submitSymptom() { loading.value = true try { const res = await checkSymptom({ text: symptomText.value }) checkResult.value = res.data } finally { loading.value = false } } </script>逻辑说明：checkSymptom调用后端/api/ai/symptom-check，后端返回的对象里有candidate_diseases、questions、urgent三个字段。模板里用v-for循环候选疾病并展示概率和科室；如果urgent为 true，再加一条el-alert提示紧急情况。这个页面在演示时非常出效果，尤其是概率数字滚动出现的时候。
参数说明：:loading在请求期间锁住按钮，防止重复提交；接口层要加错误处理，因为 DeepSeek 偶尔超时，超时后给用户提示“网络不稳定，请重试”。千万不要把模型超时错误直接透传到界面，看起来很不专业。
4.2 结构化电子病历：从听诊记录到字段落库
医生端“生成病历”功能的核心价值是，在医生填完主诉和现病史后，系统能帮他把这些自然语言文本自动扩展成一份可查询的病历草稿。源码里AutoGenerateMedicalRecord()这个服务的逻辑是：拼一个要求模型“生成结构化 SOAP 格式病历”的 prompt，然后把模型输出按{subjective: 主诉, objective: 体格检查, assessment: 诊断依据, plan: 治疗建议}的 JSON 结构拆开，落到medical_record表对应的字段里。
需要注意，模型生成的内容再完整，也不能直接盖过医生手写结论。资源设计里有个很聪明的点：AI 生成的内容只作为“草稿”预填到表单，医生最终要点击“确认保存”后才会落库。这避免了“AI 写的诊断被当成医生确诊”这种在医疗场景里不可接受的错误。如果你在答辩时被问到“AI 出错怎么办”，这个设计就是你最好的回答：模型只是辅助录入，权威性在医生手里。
落库后，病历数据会被整理成record_view视图，关联患者档案、处方、检查单，前端“历史病历”页面直接查这些关联表，还能做关键词搜索。这套数据模型虽然不是国标级别的结构化，但足以支撑完整的业务演示。
4.3 AI 日志与 token 成本控制：别让演示崩在余额上面
一次症状自查平均消耗 300-500 token，一次完整病历生成可能消耗 1000-2000 token。如果你把 demo 演示沓三五次，账户余额就肉眼可见地往下掉。项目里的ai_log表除了记内容，还记录每次调用消耗的 token 数和耗时。我建议在调通后，把max-tokens从 2048 降到 1024，并给 prompt 里加一句“控制在 300 字以内”，对毕设演示完全够用，成本直接砍半。
另外要警惕循环调用。后端接口没有做 Redis 限流，如果被频繁刷请求，AI 费用会疯涨。准备在公网演示时，一定要在网关或过滤器层做一个基于用户 ID 的简单限流：同一个用户一分钟最多调用 10 次 AI 接口。代码量不大，但能防止你演示现场被无意识 F5 刷爆。
5. 三个必踩的坑和我的排查记录：从接口 401 到 JSON 解析失败
5.1 现象一：DeepSeek 接口一直返回 401 认证失败
第一次启动项目，ai_log表里出现一堆 401 错误。排查后发现是application.yml里${DEEPSEEK_API_KEY:your-key-here}这个配置的问题——本地环境变量没设，配置直接读成了字面量your-key-here，密钥当然无效。解决方法是确保启动脚本中export DEEPSEEK_API_KEY=sk-xxxx或者用 IDE 环境变量面板注入。血泪经验：写配置时，别把假 Key 放在默认值位置，宁可留空并在启动时校验。
5.2 现象二：病历生成偶尔出现“半截 JSON”导致前端白屏
有一次演示，点击生成病历后前端一直转圈，控制台报JSON parse error。原因是请求超时设置太短，模型生成到一半被timeout掐断，返回了不完整的 JSON。解决方法是把timeout从 30 秒提高到 60 秒，并在后端加一个“解析失败→返回友好提示”的兜底。从那以后我每次改 prompt 模板，都强制跑一遍“长文本 + 短超时”两个边界用例。
5.3 现象三：前端 axios 拿不到 AI 接口的响应头
页面可以通过api/ai/*正常拿数据，但用@CrossOrigin配的 CORS 拦不住自定义 header。排查发现是网关层没有把Authorization头透传给前端跨域预检请求。解决方式是使用 Spring 官方CorsFilter配置，显式允许Authorization和Content-Type两个请求头。如果你用的是网关，记得在路由配置里把这两个头加入 allowedHeaders。
5.4 现象四：JWT 在 Redis 里过期后，用户下次操作仍显示“登录过期”
因为资源里 JWT 没有接 Redis 统一校验。用户已登录期间如果 Redis 重启，token 验证照样通过，因为 JWT 是无状态签名，服务端不存储会话。解决方法是把 Redis 缓存放进 JWT 拦截器里做二次校验——查user_session表，token 对应记录为空直接返回 401。这是一个在答辩演示时非常容易出丑的坑，务必提前处理。
5.5 现象五：MySQL 5.7 建 SQL 跑在 MySQL 8.0 时报时区错误
这个问题是环境差异，不是代码问题。MySQL 8.0 默认时区与 5.7 不同，启动报The server time zone value 'xxx' is unrecognized。解决方法是连接串加上serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true。也就是每次拆这种带数据库的源码，第一件事先看 MySQL 版本和驱动版本是否匹配。
6. 把这个系统做亮的三个进阶技巧：答辩演示的临门一脚
6.1 用“追问闭环”让症状自查更有医疗逻辑
原始资源的症状自查是单轮问答：输入症状 → 返回结果。我后来自己加了一个追问闭环：每当返回候选疾病时，同时把questions数组展示在界面底部，让用户再回答一轮“头痛持续多久了，有没有呕吐”，把第二次问答的结果拼进初始文本，再次调用模型。这样一来，交互深度明显提升，答辩时你能现场演示“AI 主动向用户提问”，这比一次输到底的方案更能体现业务思考。
实现起来不难：前端维护一个conversationHistory，用数组存{role: 'user' | 'assistant', content}，提交时把所有聊天记录一起传给后端，后端全部塞进messages。模型会基于上下文修正诊断，比每次只传一句话准确得多。
6.2 通过ai_log做“费用看板”，展示系统可观测性
把ai_log表里的token_count和cost_estimate聚合统计，在管理员页面做一个简单的折线图——按天展示 AI 调用次数和 token 消耗。这一步代码量不大，但答辩时你告诉评委“系统能定量观测 AI 资源消耗”，瞬间拉开和普通管理系统的差距。具体做法很直接：后端写一个/api/ai/dashboard接口，SQL 里GROUP BY DATE(create_time)并按 token 求和，前端用 ECharts 画折线。既然资源里已经存了日志，这个功能只是三小时工作量。
6.3 用 SSE 把病历生成的“打字机”效果做出来
前面提过流式输出的价值。具体落地时，前端不要用EventSource，因为 DeepSeek 接口需要自定义 Header。用原生fetch发 POST 请求，读取response.body.getReader()，每次读到一段字符就 append 到目标div。核心代码段如下：
const response = await fetch('/api/ai/medical-record/stream', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ caseId }) }) const reader = response.body.getReader() const decoder = new TextDecoder() while (true) { const { done, value } = await reader.read() if (done) break contentText.value += decoder.decode(value, { stream: true }) }逻辑说明：reader.read()每次返回一个 chunk，用TextDecoder转成字符串后直接追加。这样页面会看到逐字输出，虽然不是逐 token 平滑打字，但也有明显的流式效果。后端在流式接口里要注意关闭响应缓冲，否则前置的压缩或缓冲组件会让流式失效，这是一个反复出现的坑。
每当我拆到类似的 AI 业务系统，我最先确认的就是三件事：模型输出有没有留痕（日志表）、失败时用户看到什么（兜底文案）、以及数据是否被不可控内容污染。从那以后我跑这套系统，第一件事是拿“长文本症状 + 短超时”和“空输入”两个用例把 AI 接口打一遍，确认不会白屏，然后才敢正式演示。这份资源最大的价值不只是能跑通的代码，而是把大模型怎么融入传统业务系统的工程思路完整演示了一遍。希望这套源码和你照着做的过程，能帮你顺利通关毕业答辩，也能让你以后做类似功能时，少踩我踩过的那些坑——用它当骨架，把业务细节补成你自己的作品，祝你好运。
本文还有配套的精品资源，点击获取
