先聊点实在的。这类“社区医疗信息系统”的题目在计算机毕业设计里属于出现频率极高的老面孔。每年春招秋招前后后台私信问我要源码的十个里有三四个都在做类似的方向。原因不复杂这类系统有明确的管理端、用户端、业务流转逻辑技术上既能用SSM框架讲传统三层架构也能换Spring Boot Vue玩前后端分离工作量可控演示效果好答辩时还能顺着“社区医疗覆盖居民健康管理”的业务逻辑往深处聊。但很多同学拿到的所谓“可用源码”要么缺依赖跑不起来要么数据库脚本和代码字段对不上要么界面还是十年前的表格式布局。这篇博文不打算重复粘贴项目报告里那些套话而是把我自己拿到这套21829号项目源码之后从解压、配库、启动、拆模块、梳理技术栈到最终完成部署的完整过程以及这套系统在设计上的可取之处和明显短板全部摊开来讲。本文适合谁看两类人。一类是正在做社区医疗、医院门诊、健康档案管理方向毕设或课程设计的同学需要一份能真正跑起来、能讲清楚设计思路的参考实现另一类是刚学完Spring Boot和Vue想找一个完整业务案例练手、搞懂一个全栈项目如何从零组织代码的初学者。我会把中间涉及的核心表结构、典型业务接口、角色权限设计、以及我从这套源码里挖出来的雷区都拆开说。1. 这套社区医疗信息系统整体上做了什么先不看代码从需求层面理解这套系统。社区医疗信息系统在国内医疗信息化语境下一般指面向社区卫生服务中心、乡镇卫生院这类基层医疗机构的管理软件。它和大型三甲医院的HIS系统有本质区别三甲HIS强调高并发、高可用、设备对接、跨科室多级计费而社区系统更看重业务覆盖面的完整性和操作便捷性。这套编号21829的系统解决方案采取的设计思路很标准面向多角色用户的业务管理平台。系统内主要拆出了两类用户身份系统管理员和医生部分版本会再加一个挂号收费员角色这版没有。围绕这两类身份系统实现了患者档案管理、医生排班管理、挂号信息记录、门诊诊疗记录、药品库存管理、健康档案建档等一套从患者进社区到完成就诊的核心业务闭环。从演示效果上讲这套项目的完成度属于中上水准。管理端和医生端做在同一个系统里通过登录后的角色判断渲染不同菜单。前端不是简单的Table堆砌页面布局用了响应式设计列表页支持分页查询和条件筛选表单页带基本的必填校验。虽然整体交互谈不上惊艳但作为毕业设计展示已经比很多只有CRUD的空壳项目丰满得多。1.1 核心功能模块拆解从患者建档到药品出库我把这套系统的功能模块按业务流转拉了一张脑图式清单方便你对照源码里的页面和接口系统登录与权限验证按用户名密码登录后端生成Token保存会话状态不同角色进入后菜单和可操作接口不同。患者档案管理维护社区内居民的基本信息姓名、身份证、手机号、家庭住址、过敏史、既往病史支持新增、编辑、删除、分页搜索。医生排班管理管理员维护医生的出诊时间为挂号模块提供数据来源。挂号收费患者前来就诊时选择科室/医生建立挂号记录记录挂号和诊疗费用状态。门诊诊疗医生在接诊时查看患者档案根据问诊情况填写诊断信息、开具处方。药品信息管理维护药品字典、库存数量、售价、生产厂家等基础数据。药房发药退药根据处方完成发药操作扣减库存退药时回补库存。健康档案统计按年龄段、性别、疾病类型等维度简单统计社区内居民的健康数据。刚拿到源码时我第一反应是看这些模块之间的耦合度。做得不好的项目最典型的表现是患者管理模块里直接操作挂号表药品模块和处方模块各写一份库存数量。这套代码在模块划分上比较规矩业务逻辑集中在Service层Controller层很薄这点值得学习。1.2 为什么社区医疗选题在毕设里经久不衰讲个实在的体会。每年毕业设计题目里社区医疗、社区超市、社区物业这三个“社区”系列是永远的常青树。原因归结起来有三个第一业务边界清晰。社区医疗系统不需要考虑跨院转诊、医保实时结算、医保控费等复杂业务核心就是“居民建档-挂号-看病-开药”这条线下流程的线上化。流程简单意味着数据库设计和代码实现都有成熟的参考范式新手不至于一开始就被复杂的业务弄晕。第二角色划分天然适配RBAC权限模型。管理员、医生、药房如果单独拆角色之间的权限边界天然清晰。用Spring Security或者Shiro来做权限控制讲解时逻辑非常自洽。第三和当下的政策热点能挂上钩。答辩的时候导师必然会问“你这个系统解决了什么问题有什么社会价值”社区医疗对应的词是“基层医疗”“分级诊疗”“居民健康管理”这些都是能展开讲的内容不会被导师追问到无法回答。2. 系统技术栈选型与源码目录结构解析这一节我们来揭开代码底层的秘密。这套21829项目的技术栈属于国内毕设项目中最主流的一套组合前后端分离架构后端Spring Boot 2.x具体小版本号看pom文件我拿到这版是2.3.7、MyBatis Plus、MySQL 5.7、Maven构建、内置Tomcat。前端Vue 2.x Element UI Axios Vue Router Vuex。额外工具Lombok、Hutool工具包、Apache Commons Lang。这套组合典型的“中小型管理系统全家桶”。Spring Boot的自动配置能力和生态成熟度保证了开发效率MyBatis Plus把单表CRUD的模版代码几乎清零Vue Element UI能快速搭建出风格统一的后台管理界面。选它作为学习项目当你把这条技术栈彻底摸透之后市面上大部分管理系统类项目你都能直接上手改。2.1 后端目录结构里的那些熟悉面孔先看后端项目的包结构基本就是教科书式的分层src/main/java/com/community/medical/ ├── controller/ # 控制器层接收请求参数校验调用service ├── service/ # 业务逻辑层写真正的业务规则 │ └── impl/ # service接口的实现类 ├── mapper/ # MyBatis的Mapper接口 ├── entity/ # 数据库实体映射类 ├── dto/ # 数据传输对象用于接口参数接收 ├── vo/ # 视图对象主要用于响应给前端的数据结构 ├── config/ # 配置类比如跨域配置、MyBatis Plus分页插件配置 ├── common/ # 公共类统一返回结果类、异常处理器、全局常量 ├── utils/ # 工具类比如JWT工具、MD5加密工具 └── MedicalApplication.java # Spring Boot启动类这个结构是Java后端开发最标准的风格适合初学者记忆。Controller用来接收参数Service来承载业务逻辑Mapper负责数据库交互。需要注意实体类entity和数据库字段之间用驼峰命名的对应关系如果用MyBatis Plus默认开启了下划线与驼峰的自动映射所以数据库字段user_name对应Java字段userName不用手动转换。2.2 前端源码结构与权限路由的配合再看前端的结构src/ ├── api/ # 封装axios请求按模块拆分的接口文件 ├── assets/ # 静态资源文件 ├── components/ # 公共组件 ├── router/ # vue-router路由配置 ├── store/ # Vuex状态管理存token、用户信息等 ├── utils/ # 请求封装、权限判断工具 ├── views/ # 页面视图组件 │ ├── admin/ # 管理员角色看到的页面 │ ├── doctor/ # 医生角色看到的页面 │ └── login/ # 登录页前端通过路由守卫来处理访问权限。具体逻辑是登录成功后把token存到Vuex和localStorage哪里需要知道用户信息就根据token调后端接口解析出用户角色路由跳转前判断角色是否在允许列表中。如果未登录或者越权访问路由守卫直接重定向到登录页。源码里的权限判断逻辑不算复杂但作为讲解了已经足够用了。2.3 数据库设计里最值得看的五张核心表数据库脚本是这套源码里含金量比较高的部分。虽然只有十几张表没有像大型HIS那样几十上百张但表结构设计覆盖了主线业务。我挑五张核心表拆解一下sys_user表用户表字段主要包括id、username、password、real_name、role_id、status、create_time。这张表承载了登录账号信息。重点看password字段——源码里用的是MD5加盐的方式但加盐逻辑写得很简单基本固定盐值这在生产环境是绝对不可取的毕设场景可以解释为“算法演示用”。patient_info表患者档案表设计了id、pid患者编号、name、gender、age、id_card、phone、address、allergy_history、past_history、create_time等字段。过敏史和既往病史这两个字段虽然简单却是整个系统里最有“医疗特色”的地方展示了对患者数据的实际管理维度。doctor_schedule表医生排班表包含doctor_id、schedule_date、time_slot、capacity等字段。这个表是挂号模块的数据基础按日期和时段记录某个医生的可挂号数量。registration表挂号表patient_id、doctor_id、schedule_id、registration_time、fee、status。这个表是业务的核心枢纽串联起患者、医生、排班三个维度的信息。prescription表处方表及prescription_detail表处方明细表主表存就诊记录、诊断结果、医生id、患者id明细表存具体开了哪些药品、数量、用法用量。一张处方主表对应多张明细表这是典型的一对多设计是“主从表”结构的教学范本。整体看下来表结构没有严重的冗余问题外键逻辑不依赖数据库物理外键而是靠Java代码在Service层维护关联关系这也是现在业界比较推荐的做法避免了数据库外键对性能的损耗和删除时的僵化。3. 从打包到部署本地把项目跑通的全过程记录这一节是很多人卡住的地方。拿到源码后跑不起来可能是环境问题也可能是代码本身有坑。我把自己在这套项目上从零部署的全过程写出来每一步都记录实际发生过的问题和踩墙过程。3.1 环境准备建议照着我的版本清单去装先把环境统一起来避免出现各种版本兼容问题JDK1.8不要用11或更高版本这套源码的pom配置没有针对新版做适配MySQL5.78.0也可以但需要改驱动配置和连接参数建议用5.7减少不必要的麻烦Maven3.6.3以上Node.js14.17以上Vue2项目用高版本Node有时构建会报错最好锁定14系列开发工具后端IDEA前端VSCode用IDEA全家桶也可以安装Vue插件即可版本选择这件事我说下为什么这么坚持。Spring Boot 2.3.7这个版本官方标注的JDK支持范围是8到13如果你直接用JDK 11以上虽然也能启动但部分底层依赖比如旧版javax.*包会编译报警。题目选了稳妥路线跟着源码的默认环境走启动成功的概率最大。3.2 数据库初始化与配置文件修改第一步新建数据库。推荐用Navicat或命令行执行CREATE DATABASE community_medical DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE community_medical; SOURCE /你的解压路径/sql/community_medical.sql;这里提醒一句执行SQL脚本时注意看是否报错。我遇到过一次脚本后半段插入语句报错原因是编码问题导致的乱码冲突。如果报错把SQL文件用Notepad或VS Code打开确认编码是UTF-8另存为时选择“UTF-8无BOM”格式再重新导入即可。数据库初始化之后打开后端的application.yml文件检查并修改数据库连接spring: datasource: url: jdbc:mysql://localhost:3306/community_medical?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你自己的密码 driver-class-name: com.mysql.cj.jdbc.Driver这里特别说一下serverTimezone参数。很多第一次用Spring Boot连MySQL的同学报错信息里出现The server time zone value Öйú±ê׼ʱ¼ä就是没设时区。直接加上serverTimezoneAsia/Shanghai就能解决。3.3 后端启动过程与常见报错处理后端项目导入IDEA的流程是File - Open选择后端的pom.xml所在目录IDEA会识别为Maven项目并自动下载依赖。依赖下载这一步很多人会卡很久建议在Maven的settings.xml里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror配置完镜像后依赖下载速度能从“等十分钟”变成“十秒钟一个包”的水平。等右下角进度条走完无红色报错再找到主启动类MedicalApplication右键Run。启动日志里看到Tomcat started on port(s): 8080这个字样说明后端已经启动成功了。但如果你直接测试登录接口大概率会得到一个意料之外的报错——别急下面前端启动完一起处理。3.4 前端依赖安装与启动过程前端项目我使用VSCode打开然后打开终端执行npm installnpm install这个命令在前端项目里是最考验耐心的环节。因为你不知道它什么时候会无声无息地失败。如果下载速度极慢或者报各种网络错误同样建议切换镜像源npm config set registry https://registry.npmmirror.com切换后再重新执行npm install。依赖装完之后执行npm run serve编译完成会提示App running at: http://localhost:8081。这里要特别注意前端的默认端口是8081因为后端占据8080前端开发环境通过端口区分。如果8081也被占用会提示你输入another port选y自动换端口。前端启动后解决前后端联调的关键一步是检查前端src/utils/request.js或者src/api/目录下的封装的接口基础路径中配置的接口前缀是http://localhost:8080还是http://localhost:8080/api。这套源码里后端Controller的RequestMapping是直接挂在类名上没有统一加/api前缀前后端需要保证路径完全一致否则即使前后端都起来了页面也无法正常调用后端接口。3.5 第一次完整登录的系统初始化体验使用管理员账号登录后第一眼看到的是系统首页面——一个简洁的欢迎界面加几个统计卡片展示患者总数、今日挂号数、药品数量等信息。可以从“患者档案管理”菜单进入尝试新增一个测试患者能正常保存并回显然后去“排班管理”里给某位医生建立一条今天出诊的排班再去“挂号收费”里选择这个患者、选择排班完成挂号最后切换到医生账号在“门诊诊疗”里看到这位患者并进行接诊开方。这一条完整链路走通说明这套项目的主流程在本地运行已经顺利实现。我实测下来的感受是页面响应速度不错Element UI组件的使用很熟练数据回显和表单校验都做得合理。唯一不太尽如人意的是部分删除操作没有二次确认弹窗误点就可能直接删掉一行数据这点我在后文问题清单里会展开。4. 源码核心实现逻辑与关键设计思路解读部署成功只是第一步要将它转化为自己的知识体系还需要理解各部分“为什么这样设计”。这一节我挑几个比较有代表性的实现细节来讲解。4.1 登录认证机制Token存哪、怎么验用户登录流程看起来简单但里头的知识密度一点也不低。前端提交用户名密码到后端/user/login接口后端从库里查出用户用MD5加密后的密码与传过来的密文比对比对成功就生成一个Token。这个Token的处理方式属于“无状态会话”将用户ID、用户名和角色ID封装进去然后返回给前端。前端拿到Token后第一步存到localStorage里保证页面刷新不丢失第二步存到Vuex里保证组件内访问方便。后续每次发请求Axios的请求拦截器自动在Header里附加这个Token后端通过拦截器解析Token得到用户信息。这套逻辑是当前前后端分离项目中最常见的会话控制方式。源码里有一个不太推荐的做法Token过期时间设置得非常长我看了下代码里没有显式timeout配置也就是说用户登录之后几乎永久有效。这在毕设答辩时如果被问到“如何防止token泄露”可能会成为扣分点建议拿到源码后自己去查一下JWT工具类加上一个过期时间参数比如配置成24小时这也是一个很好的优化点。4.2 MyBatis Plus的CRUD模板与分页查询的落地方式这套源码用MyBatis Plus之后大部分单表操作不需要写XML里的SQL语句。在Mapper接口里直接继承BaseMapperUser就自动拥有了selectById、selectList、insert、updateById、deleteById等一系列方法。这也是MyBatis Plus最吸引人的特性——把程序员从繁杂的基础SQL中解放出来。分页查询是用MyBatis Plus的分页插件实现的。具体逻辑是先添加一个PaginationInterceptor的配置类然后在Service层里调用PageUser page new Page(current, size);和userMapper.selectPage(page, queryWrapper)插件会自动拦截SQL并追加limit语句最终从Page对象里取记录集合和总条数。这套写法如果之前没用过手写分页SQL的同学会有种大丰收的感觉——从前要加的count查询和limit计算统统不需要了。但要提醒一句MyBatis Plus虽好用遇到多表关联查询时它就派不上用场了源码在统计报表模块里依然手写了XML里的SQL。所以使用MyBatis Plus的正确姿势是单表操作用内嵌方法多表关联用自定义SQL。两种方式混合使用这也是源码里体现出来的一个开发经验。4.3 角色权限控制前端菜单按角色渲染的完整逻辑这套系统的两种角色在功能上有重叠也有隔离。管理员能看到患者、药品、排班、所有的挂号记录医生只能看到自己的排班、自己的患者、自己的接诊记录。角色的控制机制体现在两个层面前端层面路由表里每个路由配置了meta: { roles: [admin] }或roles: [admin, doctor]。动态生成路由的时机是登录后通过Vuex里的用户角色信息过滤出这个角色能访问的路由表再用router.addRoutes()动态添加。这样做的好处是一旦登录角色确定前端根本不会生成其他角色的路由地址越权访问无从谈起。后端层面拦截器或切面里根据请求url判断是否匹配当前角色的权限列表。不过这套源码在后端接口层面只控制了登录状态没有做更细粒度的操作权限区分。比如两个角色都可能调用了添加患者档案的接口但是前端把入口隐藏了。这种依赖前端隐藏的方案在企业项目里是不推荐的从安全角度讲后端接口必须做二次校验。这个问题在答辩时也容易被问到建议提前打草稿想好怎么圆。4.4 药品库存扣减中的并发问题源码方案与改进思路药品发药时要扣减库存这套代码的做法是在Service层执行两步操作第一步查药品表拿到当前库存数第二步判断库存大于0后减一更新。这个逻辑在单机、低并发场景下完全可行但在真实的高并发场景中却存在明显的隐患——两个请求同时读到了库存1都判定可扣最终减成了-1。安全天地不在这里过度貌低并发场景的毕设项目能达到演示效果已是目标但如果是想把这个项目作为找工作的项目经验写进简历里可以在面试前补充一个乐观锁方案。具体实现也很简单给药品表加一个version字段更新时在SQL里加上where id ? and version ?条件更新的同时set version version 1。如果更新的影响行数为0说明版本号变了数据已被其他事务修改需要重新查询判断。这套方法不需要引入额外中间件逻辑直观也是非常经典的面试考点。5. 这套系统里比较明显的缺陷与项目优化思路任何一套毕业设计源码都不可能是完美的。我客观评价一下这套21829项目的优缺点多数问题在同类项目里也普遍存在了解这些问题你在答辩时反而能展现出对项目更深入的思考。5.1 缺少必要的数据权限隔离最大的安全隐患是医生角色可以查看全部患者列表。在实际的社区医疗场景里医生应该只能看到自己负责的患者或在本机构建档的患者不能让每个医生随意浏览所有居民的健康档案。这既是操作习惯问题也是个人隐私数据合规性的原则问题。如果要优化最简单的方案是在查询患者列表的接口上增加一个参数比如doctorId在SQL里用department字段过滤或者建立一张医生-患者关联表。这里的核心点是数据权限的隔离问题比功能权限的隐藏更值得做。这种优化涉及数据库表结构调整和DAO层逻辑改动工作量不小但做出来之后项目层次会明显提升。5.2 没有审计日志功能医疗系统对操作留痕的要求很高。谁在什么时间修改了哪个患者的档案谁删除了一条挂号记录这些操作日志在真实业务系统中是强制要求这套源码里是完全缺失的。如果订单表里被误删除一条记录肇事者是谁根本无从查起。在已有框架上增强审计最简单的手段是利用Spring AOP写一个切面拦截所有Controller方法解析注解或方法名把操作者、操作时间、请求参数、响应结果统一写入一张sys_oper_log表。AOP做日志的最大好处是逻辑无侵入不用改动任何业务代码也是面试时非常容易讲出亮点的一个功能点。5.3 业务细节存在大量的“石膏线”式假象这个词我想了很久。所谓系统能跑通能增删改查但很多细节经不起业务推敲。比如挂号费在代码里是一个固定值没有按科室类型或医生职称来区分药品库存的变更只有发药退药两个入口没有入库管理和采购流程处方明细没有判断药品库存与处方药数量的关系健康档案统计的图表只有柱状图和饼图各一个维度也很简单。这些地方都是拿源码后可优化的空间。我个人的建议是如果你决定用这套系统作为毕业设计主线不要照抄源码交差了事重点挑选其中两到三个模块进行二次开发深化。比如增加一个“数据统计与分析”模块用ECharts展示居民疾病的年龄段分布、药品消耗排行。这样翻新后的系统既保留了原有框架验证过的合理性又体现出你不只是复制粘贴而是真的理解并改进了这个项目。6. 常见问题速查我跑这套源码时踩过的九个坑这一节写给正在自己动手操作的同学。下面每一条都是我在实际部署和使用过程中真实遇到过、并且已经找到解决方案的问题整理成表格方便你对照处理。问题现象可能原因解决方案后端启动直接报错提示数据库连接失败application.yml中数据库名、账号、密码错误或者MySQL服务未启动检查MySQL是否在运行核对yml配置文件中的url、username、passwordMaven依赖下载缓慢或失败默认连接Maven中央仓库国内网络不稳定在settings.xml配置阿里云镜像重新reimport项目前端npm install卡住不动默认连接npm官方源网络无法稳定访问执行npm config set registry https://registry.npmmirror.com后重新安装前端启动成功登录时一直提示“请求失败”或Network Error前后端端口不一致或接口地址写错检查前端request.js或.env.development文件中的BASE_URL是否指向后端实际地址登录时报401或token无效后端接口有拦截器校验Token未正确传入或Token过期检查前端登录成功后Token是否已存到localStorageAxios请求拦截器是否设置了Authorization头点击菜单页面有表格但没有数据数据库为空对应表没数据按业务顺序先创建患者再创建排班、挂号等数据不要跳级操作中文乱码数据库表字符集不是utf8mb4修改数据库连接url加characterEncodingutf8mb4确认建库时指定字符集前端页面白屏控制台报JavaScript报错依赖版本冲突或代码有console错误查看浏览器F12控制台具体报错信息一般是组件未正确引入或数据undefined8080端口被占用其他程序已使用该端口后端启动类中配置server.port修改为8081等未被占用端口或找到占用进程后关闭6.1 最容易出问题的跨域配置实战前端端口是8081后端端口是8080虽然本地开发调试时通过代理的方式避免了跨域问题但如果你直接从前端发请求到后端接口浏览器会因为同源策略拦截请求。源码里后端是有一个跨域配置类的用的是Spring Boot的CorsFilter。我看到这版实现是允许所有来源allowedOrigins(*)这在开发环境没有问题但如果你部署到生产环境建议把允许来源限制为具体的域名这也是一个值得在答辩时提到的安全加固点。Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); // 生产环境应改为实际前端域名或IP如 http://localhost:8081 config.addAllowedOrigin(*); config.addAllowedMethod(*); config.addAllowedHeader(*); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }6.2 演示时突然数据库表被锁或卡死的应急处理有一次我演示时执行一个删除操作前端按钮一直转圈过一会儿后端日志报了个MySQL锁等待超时的错误。这个场景虽然不常见但如果答辩现场出现就非常尴尬了。出现的原因大概率是某个事务没有正确提交表级的行锁一直被占用。应急处理的方法是登录MySQL执行以下命令查看并杀掉卡住的进程-- 查看当前有哪些线程在执行 SHOW PROCESSLIST; -- 找到状态为Waiting for table metadata lock或者其他长时间未结束的线程执行 KILL 线程ID;如果时间紧张不处理也没关系重启MySQL服务可以强制释放所有锁。但这只能应对突发要让系统更稳还是要规范事务的写法避免在一个事务里做耗时操作。7. 复盘总结拿到了源码之后你该怎么办最后回到原始的关键词源码、社区医疗信息系统、设计与实现。这套21829项目给我的整体印象是代码风格统一、业务覆盖完整、前端交互流畅是一套质量中等偏上、非常适合二次开发的毕设项目。拿到源码的当下把项目跑通只是最基本的一步之后的消化吸收才是真正拉开差距的地方。我的实际操作顺序建议是先从数据库入手把每张表的关系画成E-R图然后以后端为主线逐个模块走一遍代码理解每一个接口的输入输出和Service层业务逻辑再切到前端对着页面找到它调用的接口位置把页面流和接口流一一对应起来最后尝试自己独立把功能修改源代码再实现一遍比如把固定挂号费改成按医生职称动态计算或者增加一个药品入库功能。如果你是学生、想拿着这套源码作为自己的毕业设计作品我强烈建议不要只做表面功夫对系统的理解深度会在答辩中直接影响导师的评分。多花一周时间去读代码、画图、梳理业务好过最后答辩时支支吾吾说不出接口逻辑被导师连环追问。我在拆这套源码时比较意外的是它的处方明细表设计了用法用量字段但没有做药品相互作用和过敏原自动提醒。如果精力允许给系统增加一个“患者过敏药物提示”——在医生开处方时如果所开药品在患者的过敏史记录中命中系统自动弹出红色警告。这个功能贴合实际需求微信里的案例模板聊到这里几乎都点到即止了只有把这个细节挖出来实现掉项目才会真正在答辩时让人眼前一亮。最后分享一个部署层面小技巧。如果你准备在答辩现场用自己电脑演示强烈建议把后端和前端的启动命令写成两个脚本一键启动。后端用mvn spring-boot:run启用前端用npm run serve启用。如果到了现场才发现端口被占用或者数据库没启动那种手忙脚乱的状态很容易影响整体表现。提前演练两遍完整启动流程确保演示万无一失。