企业官网建设流程全解析

做过几个医疗类管理项目，再看到“springboot中医诊所病历系统——附源码46724”这套源码时，我第一反应是：这类项目比普通CRUD管理系统有意思得多，因为它里面带了中医诊所特有的“辨证论治”流程。系统本质是围绕“患者—病历—辨证—处方”这条主线做闭环管理，Spring Boot负责后端接口和页面渲染，源码完整的话拿来就能跑。对做Java课程设计、毕业设计，或者刚学Spring Boot想找一个真实项目练手的人来说，都值得认真拆一遍。这篇文章我会从需求拆解、数据库设计、核心功能实现，到源码导入运行，把整套系统讲透，顺手把我自己踩过的坑也一并交代。

1. 项目概述与需求拆解

1.1 中医诊所病历系统到底要解决什么问题

很多小型中医诊所到现在还是纸质病历，患者进门先写一张个人信息卡，医生接诊时手写主诉、舌象、脉象、证型，再手写一张方剂。纸质记录有三个致命问题：第一是没法检索，想统计一下这个月“气滞血瘀”型患者有多少，几乎要翻一整天；第二是复诊时医生只能靠记忆和患者口述，很难快速调出这位患者半年前用的什么方子；第三是字迹容易认错，尤其是中药名和剂量写得不清楚，抓药时容易出偏差。

这套系统瞄着这些痛点去做，核心就是把病历电子化、结构化。它不是一个泛泛的进销存，也不是医院那种大型HIS（医院信息系统），而是更适合个体诊所、中医馆、或者院校实训用的轻量业务系统。技术侧Spring Boot是主角，配合MySQL存储业务数据，前端通过Thymeleaf模板或静态页面渲染，整体工程量适中，逻辑却足够典型。

适合谁看？如果你是正在做毕业设计的学生，想找一个有实际业务场景、又不至于复杂到看不懂的Spring Boot项目，这个选题很合适；如果你是在职开发者想快速了解一个小型医疗系统的建模方式，这套源码同样有参考价值。它比“图书管理”这类纯增删改查的项目多了辨证和处方的一对多关系，难度曲线刚好。

1.2 从业务原始需求到功能地图

拿到源码之后，我习惯先把功能点列出来，再对照代码。一个完整可用的中医诊所病历系统，通常要包含以下模块：

其中“新增病历”和“处方管理”是核心中的核心。一个病历主表记录这次就诊的辨证信息，一个处方明细表记录医生开的每一味药。这样做的好处是：历史处方可以长期保存，下次复诊只需一键复制上次处方，医生只需要在原有基础上加减几味药就行，效率能明显提升。

很多课程设计容易犯的错误是上来就做一堆功能，比如预约挂号、收费管理、库存管理、会员卡，结果每个模块都只写了半吊子代码。我的观点是优先保证病历+处方闭环，再考虑报表，其他模块能砍则砍。这套源码核心功能扎实，也是它能作为完整项目输出的原因。

1.3 为什么选Spring Boot而不是其他框架

早几年前做SSM（Spring + SpringMVC + MyBatis）整合，配置繁琐到什么程度？一个web.xml、一个spring-mvc.xml、一个spring-mybatis.xml，还有一堆jar包版本冲突，光调通环境就能耗掉一天。Spring Boot把这些东西全部自动化，内嵌了Tomcat，加一个spring-boot-starter-web就能启动HTTP服务，源码里带application.yml一个配置文件就能搞定数据源、端口、日志等。

对于中医诊所病历系统这种中小型业务系统，Spring Boot的自动配置和起步依赖能省掉大量重复工作。另外，现在网络上能找到的Java后端项目源码，绝大多数基于Spring Boot，遇到问题搜索解决方案的成本很低。如果你非要上个Spring Cloud微服务，那反而是过度设计，一个诊所系统拆成五六个服务，运维代价远大于收益。

还有一点很实际：源码附带的依赖版本通常在2.x左右，用JDK8或JDK11就能跑，不需要追新。这也是为什么很多课程设计和毕业设计都愿意选Spring Boot的原因——环境友好、资料多、上手快。

2. 技术架构与源码结构解析

2.1 工程分层与源码目录

拿到源码包46724，解压后应该能看到一个标准的Maven工程。我建议第一步先看目录结构，不要直接点运行。一个清晰的后端工程大致是这样的：

src/main/java/com/example/clinic/ ├── controller/ # 控制层，接收前端请求 │ ├── UserController.java │ ├── PatientController.java │ └── MedicalRecordController.java ├── service/ # 业务层 │ ├── UserService.java │ └── impl/ │ └── UserServiceImpl.java ├── mapper/ # 数据访问层 │ ├── PatientMapper.java │ └── MedicalRecordMapper.java ├── entity/ # 实体类，对应数据库表 │ ├── Patient.java │ ├── MedicalRecord.java │ └── PrescriptionDetail.java ├── dto/ # 前端入参/返回参数封装 │ ├── LoginDTO.java │ └── MedicalRecordDTO.java ├── config/ # 配置类 │ ├── MybatisPlusConfig.java │ └── WebMvcConfig.java ├── common/ # 统一返回结果、异常处理 │ └── Result.java └── ClinicApplication.java # 启动类 src/main/resources/ ├── mapper/ # MyBatis的XML文件 ├── static/ # 静态资源（CSS/JS/图片） ├── templates/ # Thymeleaf模板页面 └── application.yml # 全局配置

这种分层的核心思想是“各司其职”。Controller只做参数接收和结果包装，Service负责业务规则，Mapper只跟数据库打交道。比如“复制上次处方”这个操作，Controller里不应该直接写SQL，而是调到Service层的getLastRecordByPatient方法，这样测试和维护都更方便。

源码里如果用了MyBatis-Plus，你会发现mapper目录下很多接口只是继承了一个BaseMapper，连最简单的增删改查SQL都不用写，这能大幅减少代码量。但要注意，像“统计各证型数量”这类聚合查询，还是需要自定义SQL或注解SQL。

2.2 核心技术栈选型与版本建议

拿我习惯的搭配做一个表格，这套源码大概率也是类似的选型思路：

为什么用MyBatis-Plus而不是Spring Data JPA？因为病历查询经常会带多条件动态查询，比如“按患者姓名模糊查病历”“按日期范围查就诊记录”，MyBatis-Plus的LambdaQueryWrapper写起来非常直观，而且对SQL的可控性更好。JPA虽然也能做，但很多刚接触的人容易被它自动生成的复杂SQL带偏。另外，源码里如果有MyBatis的XML文件，也可以很清楚地看到手写SQL的位置。

前端没有用特别重的框架，模板页面加Bootstrap就足够了。如果你看到的源码是前后端分离的，那前端会单独有一个Vue或React工程，打包后把dist目录里的文件放到Spring Boot的static目录下，同样能跑。这两种方式并不冲突，后端接口设计保持REST风格，前端怎么套都行。

2.3 源码包46724的导入前检查清单

很多人下载了源码包，第一件事就是双击ClinicApplication.java运行，结果报错一堆。我的习惯是先做三分钟检查：

第一，看包内有没有sql目录或db目录，数据库脚本是否齐全。一般项目都有clinic.sql或schema.sql，没有的话你要么自己建表，要么就要查代码里的建表注解。

第二，看pom.xml里的Spring Boot版本和JDK版本是否匹配。如果Spring Boot是2.3.x，你用JDK17跑容易出现javax包不存在的问题；如果是Spring Boot 3.x，则要JDK17以上。源码项目为了稳妥，通常用2.x。

第三，看application.yml里的账号密码是不是写死的。很多作者喜欢用root/123456，你本地MySQL密码如果不是这个，启动就会失败，需要先改配置。

这三件事做完，再根据后面的运行步骤去操作，会比盲目双击启动顺利得多。

3. 数据库表设计与核心业务逻辑

3.1 核心表结构设计思路

病历系统最重要的资产是数据，所以表结构一定要看清。我在这里按典型源码的设计，抽四张核心表出来讲解。

患者档案表：

CREATE TABLE `patient` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '患者姓名', `gender` varchar(10) DEFAULT NULL COMMENT '性别', `age` int DEFAULT NULL COMMENT '年龄', `phone` varchar(20) DEFAULT NULL COMMENT '联系电话', `allergy_history` varchar(500) DEFAULT NULL COMMENT '过敏史', `created_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '建档时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='患者档案';

病历主表：

CREATE TABLE `medical_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `patient_id` bigint NOT NULL COMMENT '患者ID', `visit_date` datetime NOT NULL COMMENT '就诊时间', `chief_complaint` varchar(500) DEFAULT NULL COMMENT '主诉', `inspection` varchar(500) DEFAULT NULL COMMENT '望诊所见', `tongue` varchar(200) DEFAULT NULL COMMENT '舌象', `pulse` varchar(200) DEFAULT NULL COMMENT '脉象', `syndrome` varchar(100) DEFAULT NULL COMMENT '证型诊断', `treatment` varchar(200) DEFAULT NULL COMMENT '治法', `doctor_id` bigint DEFAULT NULL COMMENT '接诊医生ID', PRIMARY KEY (`id`), KEY `idx_patient` (`patient_id`), KEY `idx_visit_date` (`visit_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='病历主表';

处方明细表：

CREATE TABLE `prescription_detail` ( `id` bigint NOT NULL AUTO_INCREMENT, `record_id` bigint NOT NULL COMMENT '病历ID', `herb_name` varchar(50) NOT NULL COMMENT '中药名', `dosage` varchar(50) DEFAULT NULL COMMENT '剂量，如10g', `remark` varchar(200) DEFAULT NULL COMMENT '煎服法', PRIMARY KEY (`id`), KEY `idx_record` (`record_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='处方明细';

证型字典表：

CREATE TABLE `syndrome_dict` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '证型名称', `description` varchar(500) DEFAULT NULL COMMENT '证型说明', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='证型字典';

从字段能看出来，这个系统把中医问诊里比较关键的内容都结构化下来了：主诉、望诊、舌象、脉象、证型、治法。这些字段在源码里通常就是实体类的属性，前端表单一提交，后端统一封装成MedicalRecord对象。

3.2 表关系解读：为什么病历和处方必须分开存

如果第一次做病历设计，很容易把处方直接写成病历表里的一个文本字段，比如prescription字段里存一串“当归15g、黄芪20g”。这样设计查询的时候极其痛苦：想统计“黄芪用了多少次”，只能靠like模糊匹配；想对比复诊药方变化，根本没法做。

正确的做法是拆成主表和子表。medical_record是一，prescription_detail是多，一个病历对应多味药。这样每次开方都是独立的多行记录，任何一味药都可以做到结构化查询。更重要的是，复诊复制上次处方的时候，只需根据record_id查出所有明细，再重新插入到新病历下面，逻辑非常清晰。

还有一个细节值得表扬：prescription_detail里冗余了herb_name字段，而不是只存herb_id。这叫什么？快照设计。如果中药字典里某个药名改了，历史病历中的处方明细依然保留开单当时的名称，不会因为字典更新而把旧病历内容也改了。这种“宁可冗余，不可追溯失败”的思路，在医疗场景非常重要。

3.3 保存病历和处方的原子性事务控制

添加一个病历，不是只插一条记录那么简单，它至少要插一条medical_record主表数据，再插多条prescription_detail明细数据。这两步必须保证“要么都成功，要么都失败”。

如果主表插入成功，明细插入到一半数据库报错，那就会产生一条没有处方的“幽灵病历”。我做项目时真踩过一次：当时明细循环里有一味药的剂量字段超长，数据库直接抛异常，但主表已经提交了，前端提示“保存失败”，实际上病历已经写出去了，患者复诊时发现多了一条不完整记录，非常尴尬。

解决办法就是在Service方法上加事务注解：

@Transactional(rollbackFor = Exception.class) public Long addRecord(MedicalRecordDTO dto) { MedicalRecord record = new MedicalRecord(); BeanUtils.copyProperties(dto, record); medicalRecordMapper.insert(record); if (dto.getPrescriptionItems() != null) { for (PrescriptionItemDTO item : dto.getPrescriptionItems()) { PrescriptionDetail detail = new PrescriptionDetail(); detail.setRecordId(record.getId()); detail.setHerbName(item.getHerbName()); detail.setDosage(item.getDosage()); prescriptionDetailMapper.insert(detail); } } return record.getId(); }

写rollbackFor = Exception.class非常关键，因为Spring默认只回滚RuntimeException，如果明细插入抛的是检查异常，不加这个参数事务会失效。这个细节以前很多人忽略。

4. 核心功能实现与源码解读

4.1 登录认证与权限控制

先看系统的入口。一个病历系统不可能允许没有身份的人随便进来修改患者数据，所以登录模块是必备的。源码里大概率采用Session拦截器方式做登录校验，流程是：用户输入用户名密码，后端校验通过写Session，再通过拦截器拦截未登录请求。

登录Controller可以这样写：

@PostMapping("/login") public Result login(@RequestBody LoginDTO loginDTO, HttpSession session) { User user = userService.login(loginDTO.getUsername(), loginDTO.getPassword()); if (user != null) { session.setAttribute("loginUser", user); return Result.ok(user); } return Result.error("用户名或密码错误"); }

这里的userService.login内部会先按用户名查用户，再用加密后的密码做比对。源码如果使用的是MD5，那是为了演示简单；你在真实项目里最好换成BCryptPasswordEncoder。

拦截器的作用是保护所有需要登录的接口：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

然后在WebMvcConfig里注册拦截规则：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/css/**", "/js/**", "/images/**"); } }

为什么不用Spring Security？诚实地讲，如果接入了Security，这套源码的学习门槛会高一大截。课程设计和毕业设计阶段，能理解拦截器原理就够了。生产环境再升级到Sa-Token或Security也不迟，核心登录逻辑是相通的。

4.2 患者档案与病历管理分页查询

患者档案和病历列表都是典型的分页查询需求。MyBatis-Plus提供了分页插件，但必须先配置：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

没有这个配置，selectPage是查不出分页效果的，只会把所有记录全查出来，这也是很多人复现项目时发现“分页不生效”的原因。工具类Result做了统一返回包装，Controller侧代码就非常清爽：

@GetMapping("/medicalRecord/list") public Result list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer limit, String patientName) { Page<MedicalRecord> result = medicalRecordService.pageQuery(page, limit, patientName); return Result.ok(result); }

ServiceImpl里用LambdaQueryWrapper构造查询条件，操作直观又防SQL注入：

LambdaQueryWrapper<MedicalRecord> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.isNotBlank(patientName)) { wrapper.like(MedicalRecord::getPatientName, patientName); } wrapper.orderByDesc(MedicalRecord::getVisitDate);

实际开发中，病历列表还需要关联患者姓名，这就可能要在SQL里做表连接。推荐在Mapper层用自定义SQL实现，比如selectRecordPage关联patient表。

4.3 复诊一键复制上次处方

这是整套源码里我最喜欢的一个功能点。它的场景很具体：患者两周前因为“失眠”来就诊，你开了酸枣仁汤，今天又来复诊，说“好一些，但还有点口苦”，你希望在原方基础上把黄芩加上去，而不是重新录入整张方剂。

前端的按钮叫“复制上次处方”，后端对应的Service逻辑大概是这样的：

public MedicalRecordVO getLastRecordByPatient(Long patientId) { LambdaQueryWrapper<MedicalRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(MedicalRecord::getPatientId, patientId) .orderByDesc(MedicalRecord::getVisitDate) .last("LIMIT 1"); MedicalRecord last = medicalRecordMapper.selectOne(wrapper); if (last == null) { return null; } List<PrescriptionDetail> items = prescriptionDetailMapper.selectList( new LambdaQueryWrapper<PrescriptionDetail>() .eq(PrescriptionDetail::getRecordId, last.getId())); MedicalRecordVO vo = new MedicalRecordVO(); BeanUtils.copyProperties(last, vo); vo.setPrescriptionItems(items); return vo; }

这段代码里最核心的是last("LIMIT 1")，它保证了只取最新一条病历。很多人一开始会直接list然后取第一条，但别忘了如果列表没有按visitDate倒序，取出来的就是最早一条。这里通过orderByDesc + limit 1实现“最近一次”，逻辑完全可靠。

拿到数据后，前端把prescriptionItems渲染到表格里，医生改几味药再点保存，后端又走一遍带事务的addRecord方法，新记录存储为新病历。复诊效率就上来了。

4.4 中医证型分布统计

统计模块是给诊所管理者看的。它可以从数据库聚合出各种维度的数据，最常见的两个统计是证型分布和就诊人次趋势。

证型分布的核心SQL其实就一行：

SELECT syndrome AS name, COUNT(*) AS value FROM medical_record GROUP BY syndrome ORDER BY value DESC;

在MyBatis里可以用@Select注解直接写：

@Select("SELECT syndrome AS name, COUNT(*) AS value FROM medical_record GROUP BY syndrome ORDER BY value DESC") List<Map<String, Object>> countBySyndrome();

Controller把结果包成统一格式返回，前端用ECharts渲染饼图：

$.get('/medicalRecord/statistic', function (res) { var chart = echarts.init(document.getElementById('syndromeChart')); chart.setOption({ series: [{ type: 'pie', radius: '60%', data: res.data }] }); });

这个统计对诊所实际经营是有意义的。比如数据显示“脾虚湿盛”这个证型占了四成，那就可以提前储备对应的茯苓、白术等药材，也能在宣传上更有针对性地做调理活动。课程设计里加上这一块，答辩时很容易讲出亮点。

5. 源码导入与运行全流程

5.1 环境准备与版本匹配

我假设你本机已经装了Java开发环境。运行之前，建议先检查一下版本：

java -version mvn -v mysql --version

如果你用的是IDEA，打开项目后右下角会提示Maven依赖导入。如果下载依赖特别慢，可以切换阿里云镜像，在Maven的settings.xml里加：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/central</url> </mirror>

要注意Spring Boot源码的JDK兼容性。大多数Spring Boot 2.x项目用JDK8最稳，用JDK17的话，如果报package javax.servlet does not exist，说明引入的依赖和JDK不匹配。不是代码不行，是版本环境不对。

5.2 导入IDEA并配置数据库

第一步，解压源码包46724，先找到数据库脚本，通常叫clinic.sql或者db.sql。用MySQL命令行或者Navicat执行前，建议先创建数据库：

CREATE DATABASE clinic DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE clinic; SOURCE /你的路径/clinic.sql;

把脚本导入成功后，理论上表都已经建好，如果脚本里带了初始管理员数据，登录就不用自己注册了。

第二步，修改application.yml数据源配置。标准配置是这样：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/clinic?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true

serverTimezone=Asia/Shanghai必须要加，不然MySQL 8会报时区相关的异常；map-underscore-to-camel-case开启后，数据库的visit_date字段才能自动映射到Java的visitDate属性。

第三步，用IDEA打开工程，右上角找到Maven面板，先点击刷新，让依赖下载完成。接着定位到ClinicApplication.java，右键运行。控制台出现Tomcat started on port(s): 8080就是启动成功。

第四步，浏览器访问http://localhost:8080，用源码自带的账号登录。初始账号常见的有admin/admin123或者doctor/123456，具体看SQL初始化脚本里的数据。

5.3 源码运行中常见报错及解决办法

我把一路跑下来比较容易遇到的报错整理成一张表：

这几种问题我全部遇到过，尤其是时区和Mapper路径两个，最隐蔽。时区报错在网上搜会看到一堆时区名词，其实设置成Asia/Shanghai就行。Invalid bound statement多半是XML文件放在resources下的mapper目录，但配置里写的路径不对，改成classpath*:mapper/**/*.xml就能解决。

6. 真实踩坑记录与个人扩展建议

6.1 我做这类源码项目时踩过的三个坑

第一个坑是字典数据缺失。表结构里有syndrome_dict，但SQL脚本只建了空表，没有初始化数据，导致前端下拉框全是空的。解决方法是手动往字典表里插常用证型，或者写一个CommandLineRunner在启动时自动初始化。你拿到源码如果发现“证型列表选不了”，先查数据库字典表是不是没有数据。

第二个坑是逻辑删除。患者档案和病历表如果直接使用物理删除，一旦误操作，历史病历就彻底没了。很多源码为了简单直接写DELETE，但生产环境不应该这么干。我改造的思路是加一个deleted字段去实现逻辑删除，MyBatis-Plus里直接用@TableLogic注解就能完成，查询时会自动带上deleted = 0条件。这套源码如果想接真实诊所业务，逻辑删除建议必须加上。

第三个坑是时间格式。前端传过来的就诊时间通常是2024-05-20 09:30这种字符串，如果实体里的字段是LocalDateTime且没有配置@JsonFormat，后端解析就报格式错误。统一处理方式是在配置类里加全局Jackson配置，或者保证前端传ISO标准格式。application.yml里的spring.jackson.date-format只是规范序列化，反序列化某些场景还是会有问题，最保险的办法是在实体字段上用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。

6.2 源码学习路线：不要把“附源码”变成“抄代码”

说句掏心窝的话，看源码和写源码完全是两回事。如果只是把项目跑起来，然后交一份实验报告，那等于白拿了这份源码。我推荐三步走。

第一步“跑通验证”：先按前面运行流程把系统完整跑起来，每个页面点一点，弄清楚这个系统到底有哪些功能和限制。

第二步“断点跟流程”：在登录、新增病历、复制上次处方这三个关键地方打上断点，跟着请求从Controller到Service再到Mapper，把一次请求生命周期看明白。这个阶段能搞清楚Spring Boot的请求流转、MyBatis的参数映射和事务控制。

第三步“改造提需求”：自己给自己派需求，比如给患者表增加一个“医保卡号”字段，给病历列表增加一个“导出PDF”按钮，或者把证型统计改成柱状图。哪怕只是加一个字段，都要走一遍实体、数据库、Mapper、页面全套流程，做完以后再回头看原版代码，你会对它服气得多。

6.3 从小项目到小诊所生产落地的优化方向

如果你不满足于完成课程设计，而是想让这套源码真正用在小型中医诊所，下面几个方向值得考虑。

前后端分离改造。现在的模板渲染够用，但如果后面要出移动端或者对接挂号小程序，后端接口最好是标准的RESTful API。可以把Vue项目打包，把dist目录下的静态文件放进Spring Boot的static目录，接口继续复用，这种部署方式简单又实用。

增加舌象照片存档。中医讲究望闻问切，舌象照片是非常有诊断价值的影像资料。可以在病历表加图片字段，前端用文件上传把图片存到本地磁盘或云存储，后端记录URL地址。这样一段时间后回看患者病情变化，有图有真相。

引入Redis缓存字典数据。证型字典、常用方剂这些数据不经常变，每次查数据库有点浪费。把字典表加载到Redis里，接口先从缓存拿数据，能在高并发下明显减少数据库压力。虽然诊所并发不大，但作为技术亮点写进简历很好用。

用Docker Compose做一键部署。生产上最省心的部署方式是把Spring Boot和MySQL都用Docker容器跑起来，一个docker-compose.yml文件就可以同时管理数据库和应用。配合宝塔面板操作，比在本机装一堆软件省事得多。

这套系统后续可以扩展的点非常多，关键是先把核心的业务闭环吃透。病历是数据底座，处方是高频操作，统计是决策辅助，三个环节打通之后，上游接挂号、下游接抓药都是自然而然的事。

最后说句实在话：拿到一份附源码的项目，别急着问“能不能直接答辩”，先打开SQL脚本读一遍，再对照着本文的模块结构走一遍，最后启动起来亲手点一遍。这样完成一整套流程之后，你对Spring Boot业务系统开发的理解，绝对比单纯背面试题要扎实得多。