企业官网建设流程全解析

把 Spring Boot 医疗管理系统作为毕业设计，这几年几乎成了 Java 方向学生的“标配”选题。原因很直接:医疗行业的业务链条足够完整——患者、医生、科室、药品、挂号、病历、处方、收费、统计——每一块都能对应上数据库设计和业务逻辑考察点,同时又不是纯粹的 CRUD 堆砌,稍微往里做一步就能碰到权限控制、并发挂号、事务处理这类真正有价值的难点。相比图书管理、学生管理这类“一眼到底”的系统,医疗管理系统在答辩时明显更有话可讲。

这篇文章我会从“如果是我自己做这个毕设”的角度,把整个项目的设计思路、数据库建模、后端核心实现、前端方案选型,以及我踩过的坑,完整过一遍。无论你是打算直接用这个题目,还是想借鉴里面的模块设计,都能拿到一套可以直接落地的方案。文章会尽量兼顾初学者的理解水平,但不会刻意灌水——该上代码的地方上代码,该讲原理的地方讲原理。

1. 项目整体设计与技术选型思路

1.1 毕设项目的核心需求拆解

医疗管理系统听起来很宽泛,但落到毕业设计这个场景,功能范围其实是有“约定俗成”的边界的。我做过的和见过的同类题目,核心模块基本都围绕这几块:

• 患者管理:建档、信息维护、查询。
• 医生与科室管理:科室分类、医生排班信息、医生所属科室。
• 挂号管理:在线挂号(或前台挂号)、号源管理、取消挂号。
• 门诊病历与处方:医生为患者写病历、开处方,处方关联药品。
• 药品管理:药品入库、库存维护、药品信息 CRUD。
• 收费与退费:处方产生的费用结算。
• 系统管理:用户登录、角色权限、菜单管理、操作日志。
• 数据统计:门诊量、科室收入、药品消耗等基础统计图表。

这八个模块基本覆盖了一个小型医院信息系统的核心业务流。在毕设答辩时,老师的提问逻辑通常是:先问你系统能干什么,再问你某个模块怎么实现的,最后往深了问——挂号并发怎么处理、权限怎么控制的、数据如何统计的。所以你在设计阶段就要给这些“深度问题”留好接口,而不是只做一堆增删改查页面。

从项目规模上看,我建议把重心放在“业务闭环”而不是“功能数量”。也就是说,挂号→就诊→开方→收费→药品扣减,这条链路必须完整跑通。很多同学喜欢拼命加功能,什么健康档案、体检报告、消息通知全塞进去,结果每个功能都做得半吊子,答辩时一问细节就露馅。一条业务主链路做扎实,比十个孤立的页面有价值得多。

1.2 技术栈选型的底层逻辑

技术栈方面,标题已经定死了 Spring Boot,那么围绕它怎么搭配就是一个值得认真思考的问题。我先说结论,再解释为什么。

我的推荐组合是:

• 后端:Spring Boot 2.7.x + MyBatis Plus + MySQL 8.0 + Sa-Token(或 Spring Security)
• 前端:Vue 3 + Element Plus + Axios(前后端分离),或者 Spring Boot + Thymeleaf + Bootstrap(非分离)
• 工具:Redis(可选,用于验证码和缓存)、Maven、IDEA、Navicat

为什么 Spring Boot 2.7.x 而不是 3.x?这是一个非常实际的问题。Spring Boot 3.x 要求 JDK 17,如果你电脑装的是 JDK 8,那直接用 3.x 会在环境上折腾很久。而且很多教学资料、博客、毕业设计参考代码都停留在 2.x,遇到问题更容易搜到解决方案。除非你是冲着面试加分想熟悉新版本,否则毕设不建议追新。

为什么 MyBatis Plus 而不是 MyBatis 或 JPA?MyBatis Plus 在 MyBatis 基础上做了大量增强,单表 CRUD 不需要写 SQL,代码生成器还能一键生成 entity、mapper、service、controller 层,这对毕设开发效率的提升是肉眼可见的。JPA 虽然也快,但国内企业用 MyBatis 系的更多,写 SQL 也更直观,答辩时更容易讲清楚。记住一个原则:毕设技术栈要稳,要用自己讲得明白的东西,不要选一个自己都解释不清楚的“高级框架”给自己挖坑。

权限这块,Spring Security 功能强大但学习曲线陡;Sa-Token 轻量、文档中文友好、API 简单,非常适合毕设这种中小型系统。如果你对 Security 不熟,我建议直接上 Sa-Token,省下来的时间足够你多做两个功能模块。

前端选 Vue 还是 Thymeleaf,主要看你自己的基础。如果你前后端分离开发经验不多,Thymeleaf 其实更稳——它和后端在同一个工程里,不用考虑跨域、不用单独部署前端,复制到哪都能跑。如果你已经熟悉 Vue 那一套,分离开发演示效果会更好,看着也更专业。后面我会单独用一节来比较这两种方案。

2. 数据库设计与核心模块拆解

2.1 数据库设计的基本原则与建模过程

医疗管理系统的数据库设计是整个项目的地基,地基不牢,后面写代码会处处别扭。我见过不少同学上来就建二十多张表,字段随意定,结果写业务的时候发现表之间缺关联、字段不够用,又反过来改表结构,连带着 entity、xml、前端页面全要动,非常痛苦。

正确的做法是:先画业务流程图,再根据流程提炼实体,最后确定表结构和关系。以“患者就诊”这条流程为例:

患者建档 → 选择医生挂号 → 医生查看挂号记录 → 医生写病历开处方 → 处方关联药品 → 收费窗口结算 → 药房发药扣库存。

顺着这条流程,实体自然就出来了:患者、用户(医生/管理员)、科室、挂号记录、病历、处方、处方明细、药品、收费记录。再加一个系统管理侧的角色和菜单,核心表就是这十来张。

我强烈建议你在建表之前先花两个小时用纸笔把 ER 图草图画出来,哪怕画得丑也没关系。你自己能不能理清表之间的关系,直接决定了后续开发的顺畅程度。数据库设计这一块在答辩时也是高频提问区域,老师很容易问“为什么这个字段要冗余”“外键为什么不用”“这个表的唯一索引是什么”,你如果建表的时候就没想清楚,很难现场编出合理答案。

2.2 核心数据表的结构设计与字段说明

下面我挑几张核心表,给出实际可用的建表 SQL 和设计说明。完整的表结构不用一次性设计完美,但这些核心表一定要经得起推敲。

患者表patient

CREATE TABLE `patient` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `patient_no` VARCHAR(32) NOT NULL COMMENT '病历号/就诊卡号', `name` VARCHAR(50) NOT NULL COMMENT '姓名', `gender` TINYINT DEFAULT NULL COMMENT '性别 1男 0女', `age` INT DEFAULT NULL COMMENT '年龄', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `id_card` VARCHAR(18) DEFAULT NULL COMMENT '身份证号', `address` VARCHAR(255) DEFAULT NULL COMMENT '家庭住址', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_patient_no` (`patient_no`), KEY `idx_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='患者信息表';

这里要注意几个点:患者号patient_no一定要唯一且业务生成,比如“P + 日期 + 流水号”,不要用自增主键直接对外展示。id_card是可选字段,很多新手把它设为非空,结果测试的时候到处造身份证号,纯粹给自己添麻烦。另外请务必统一用utf8mb4字符集,别问,问就是踩过坑——存个 emoji 或者生僻字直接乱码。

挂号记录表registration

CREATE TABLE `registration` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `reg_no` VARCHAR(32) NOT NULL COMMENT '挂号单号', `patient_id` BIGINT NOT NULL COMMENT '患者ID', `doctor_id` BIGINT NOT NULL COMMENT '医生ID(用户表)', `dept_id` BIGINT NOT NULL COMMENT '科室ID', `reg_date` DATE NOT NULL COMMENT '就诊日期', `time_slot` TINYINT NOT NULL COMMENT '时间段 1上午 2下午', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态 0待就诊 1已就诊 2已取消 3已过号', `fee` DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '挂号费', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_reg_no` (`reg_no`), KEY `idx_patient_date` (`patient_id`, `reg_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='挂号记录表';

挂号记录表是整个系统里业务逻辑最密集的表之一:要控制同一个患者同一天不能重复挂同一个医生;要限制号源数量;要处理取消挂号、过号等状态流转。reg_no、status这些字段设计看起来简单,但写代码的时候你会发现每一个字段都在对应一条业务规则。所以建表时把字段含义和业务对应好,后面写 Mapper 和 Service 会轻松非常多。

病历表medical_record和处方表prescription

病历表主要存患者的诊断信息,处方表和处方明细表是一对多的关系。这里我特别想提醒:病历和处方一定要通过挂号记录关联到患者和医生,而不是直接一个patient_id就完事。从业务上讲,一次挂号对应一次就诊,一次就诊对应一份病历和若干处方,这个链条保持一致,统计和回溯才讲得通。有些同学图省事把病历表独立出来,只存患者 ID,结果问“这个病历是哪个医生在哪个时间段写的”完全答不上来,这就很尴尬。

2.3 角色权限模型设计

权限模型我直接推荐经典的 RBAC(基于角色的访问控制),也就是“用户-角色-权限”三层。医疗系统天然需要权限区分:患者能看自己的挂号记录,医生能写病历开处方,管理员能维护基础数据,药房人员能处理药品和发药。如果没有权限控制,所有登录用户都能访问所有接口,这个系统在答辩时会被一票否决。

Sa-Token 实现 RBAC 非常简单:

// 登录时给用户赋予角色标识 StpUtil.login(userId); StpUtil.getSession().set("role", user.getRoleCode()); // 接口鉴权:只有医生或管理员能访问 @SaCheckRole("doctor") @PostMapping("/prescription") public Result createPrescription(@RequestBody PrescriptionDTO dto) { return Result.success(prescriptionService.create(dto)); }

数据库层面至少要有三张表:sys_user(用户)、sys_role(角色)、sys_menu(菜单/权限),以及两张关联表sys_user_role、sys_role_menu。如果你用 MyBatis Plus 的代码生成器,这些表的 CRUD 几乎不用自己写代码,重点是把菜单树的层级关系和角色分配的逻辑想清楚。

3. Spring Boot 后端核心实现与避坑指南

3.1 项目初始化与目录结构规划

很多初学者在创建 Spring Boot 项目这一步就会被卡住,尤其是 IDEA 创建项目时连接 start.spring.io 超时,这是国内网络的经典问题。解决方案很简单:在 IDEA 的 Spring Initializr 配置里把 Server URL 改成阿里云镜像https://start.aliyun.com,创建速度和成功率立竿见影。

项目结构方面,不要搞那种几百个包的大分层,毕设项目按功能模块分包最实用:

com.example.medical ├── MedicalApplication.java ├── common // 通用类:统一返回结果、异常处理、常量 ├── config // 配置类:跨域、拦截器、Sa-Token ├── controller // 控制层 ├── service // 接口 + 实现 ├── mapper // MyBatis Plus Mapper ├── entity // 数据库实体 ├── dto // 前端传入的数据对象 ├── vo // 返回前端的数据对象 └── utils // 工具类

我特别想强调dto和vo这两个包。很多同学的代码里,Controller 直接接收 Entity,返回的也是 Entity,这确实省事,但当你的页面需要多表联查结果、或者提交的数据和表结构不一致时,就会开始疯狂往 Entity 里加无关字段,最后实体类变得一团糟。合理做法是:接收前端数据用 DTO,返回前端数据用 VO,Entity 只在 Service 层和 Mapper 层内部使用。这个习惯在毕设里不一定被强制要求,但答辩时有老师问“你的数据是怎么在层与层之间传递的”,你能讲出 DTO/VO 的设计意图,会是一个明显的加分项。

3.2 统一返回结果与全局异常处理

这一节属于“每个 Spring Boot 项目都应该有”的基建。没有统一返回体的项目,每个接口返回格式都不一样,前端对接时恨不得一把火烧了后端。我习惯的返回体格式是:

{ "code": 200, "message": "操作成功", "data": { } }

对应的 Java 类一般这样写:

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

全局异常处理用@RestControllerAdvice实现,把业务异常、参数校验异常、未知异常统一拦下来,转成上面的返回结构。这一步做完,你的 Controller 里面就不用再写一堆 try-catch,代码会干净很多。而且答辩时演示“传入非法参数也不报 500 白屏”,这个细节很能体现工程素养。

3.3 配置文件管理:多环境与密文处理

关于 Spring Boot 配置,最近网上讨论挺多的一个点是 yml 密文。说白了就是数据库密码、Redis 密码这些敏感信息,直接明文写在 application.yml 里,项目代码一旦泄露密码也就跟着泄露了。毕设虽然不是什么高安全场景,但如果你在简历上写“熟悉配置安全”,那这个点就值得做好。

常见的做法是使用 Jasypt 对配置项加密。步骤很简单:

1. 引入依赖:

<dependency> <groupId>com.github.ulisesbocchio</groupId> <artifactId>jasypt-spring-boot-starter</artifactId> <version>3.0.5</version> </dependency>

2. 生成密文:

java -cp jasypt-1.9.3.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI input="root" password="你的盐值" algorithm=PBEWithMD5AndDES

3. yml 里这样写:

spring: datasource: username: ENC(xxx加密后的内容) password: ENC(xxx加密后的内容) jasypt: encryptor: password: ${JASYPT_PASSWORD}

注意盐值通过环境变量传入,不要把盐也写死在 yml 里,否则密文等于白加。毕设阶段能做到这一步,已经比大多数同学专业了。

配置多环境也是我一直强调的好习惯。一套application.yml放公共配置,再分application-dev.yml和application-prod.yml,启动时用spring.profiles.active=dev切换。实际开发时本地数据库和服务器数据库很可能不是同一个,没做多环境隔离的话,每次部署都要改配置文件,非常容易出错。

3.4 核心业务实现:挂号与并发控制

挂号和普通 CRUD 最大的区别在于:它涉及“号源扣减”这个典型的并发场景。如果不做控制,两个患者同时挂最后一个号,两个请求都查到剩余号源为 1,然后都执行插入挂号记录,最后就会出现超卖。答辩时老师只要问“如果 100 个人同时抢一个号怎么办”,这个问题能直接区分你是“会写代码”还是“理解业务”。

解决方案从简单到复杂有几种:

方案一:数据库乐观锁

在医生排班表或号源表上加一个版本号字段version,更新时校验版本号:

UPDATE doctor_schedule SET remaining = remaining - 1, version = version + 1 WHERE id = #{scheduleId} AND remaining > 0 AND version = #{version}

如果UPDATE影响行数为 0,说明号源已被抢完或版本冲突,就返回“挂号失败”。这种方案实现简单,性能也够用,是毕设场景下性价比最高的选择。

方案二:数据库悲观锁(行锁)

在查询号源时用SELECT ... FOR UPDATE把行锁住,事务提交后才释放。能保证绝对不出超卖,但并发性能会比乐观锁差,而且要注意锁必须在事务内才能生效。

方案三:Redis 预扣减

把号源数量放在 Redis 里,用DECR命令原子扣减,扣减成功后再异步落库。这个方案性能最好,但引入了 Redis 的依赖,而且 Redis 和数据库的数据一致性处理起来比较复杂,毕设如果没把握不建议上。

我的建议是:方案一为主,数据库层面再加一个唯一索引兜底(比如patient_id + reg_date + doctor_id唯一),双保险。答辩时你能把这个链路讲清楚,老师基本不会再在这个点刁难你。

3.5 MyBatis Plus 使用要点与“自动建表”方案

MyBatis Plus 在毕设里的核心价值就是“少写 SQL”。配置好代码生成器之后,单表的 CRUD 几乎是一键生成,你只需要在 Service 里填业务逻辑。有几个注意点我提一下:

• 分页插件要单独配置PaginationInnerInterceptor,否则Page对象不生效。
• 字段自动填充(create_time、update_time)用@TableField(fill = FieldFill.INSERT)配合MetaObjectHandler实现,不要每次插入都手动 set。
• 逻辑删除配置@TableLogic,做删除操作时自动变成UPDATE ... SET deleted = 1,避免物理删除数据导致后期统计对不上。

网上热词里提到的“当表不存在自动建表”,在 MyBatis Plus 里其实不能直接实现,它只是一个 ORM 框架,不做表结构管理。如果你想实现这个效果,有两个思路:一是用 Spring Boot 的spring.sql.init配置,在启动时执行schema.sql建表脚本;二是集成 Flyway 做数据库版本管理,不仅能在表不存在时建表,还能管理后续的表结构变更。Flyway 在真实项目中用得非常多,简历上写一句“使用 Flyway 管理数据库版本”会有不错的加分效果,而且它的配置并不复杂,启动时自动执行classpath:db/migration下的 SQL 脚本,推荐有余力的同学了解一下。

3.6 文件上传与定时任务等实用功能

医疗系统里可能会涉及头像上传、报告上传等场景。Spring Boot 做文件上传的核心代码并不复杂,但要注意几个坑:上传文件大小默认限制是 1MB,要在 yml 里调大:

spring: servlet: multipart: max-file-size: 50MB max-request-size: 50MB

还要考虑文件存储路径:开发时可以存本地磁盘,生产环境一般用对象存储。毕设阶段做本地存储完全没问题,但要注意把路径配到配置文件里,不要写死,否则换一台电脑跑项目就要改代码。

定时任务也是一个能体现“加分意识”的功能点。比如超过 30 分钟未支付的挂号记录自动取消,释放号源。用 Spring Boot 自带的@Scheduled注解轻松实现:

@Component public class RegistrationTask { @Autowired private RegistrationService registrationService; // 每隔 5 分钟执行一次 @Scheduled(cron = "0 */5 * * * ?") public void cancelTimeoutRegistrations() { registrationService.cancelTimeoutRecords(30); } }

不要小看这个功能,很多毕设系统是没有定时任务的。你做一个“超时自动取消挂号,释放号源”,业务闭环完整度立刻提升一个档次,而且@Scheduled的 cron 表达式也是面试常问的知识点。

4. 前端方案与权限控制实战

4.1 前后端分离还是模板引擎:怎么选

前端方案我前面留了个扣,这里展开说。两种方案各有各的适用场景,我帮你把决策条件列清楚:

前后端分离(Vue + Element Plus):

• 优点:页面美观、交互流畅、技术栈更符合当前企业主流,简历上写“熟悉前后端分离开发”更有说服力。
• 缺点:要单独跑一个前端工程,要配跨域解决,部署时要打包后放入后端静态目录或单独部署,流程更多。
• 适合:对前端有一定基础,或者有精力去学 Vue 基础的同学。

服务端渲染(Thymeleaf + Bootstrap):

• 优点:一个工程搞定前后端,不用解决跨域,开发调试更简单,部署就是一个 jar 包。
• 缺点:页面交互相对受限,复杂功能(比如实时聊天、复杂图表)做起来费劲,技术栈显得偏老。
• 适合:前端基础薄弱、时间紧张、追求“能跑能演示”的同学。

我的个人建议是:如果离答辩还有一个月以上,尽量选前后端分离。现在企业里 Vue 几乎是 Java 后端的标配搭档,你即便不做毕设,也应该会一点。而且 Element Plus 的表单组件、表格组件非常成熟,你不需要会写多少 CSS,照着官方文档拖组件都能把界面做得像模像样。如果时间只剩一周,那就老老实实用 Thymeleaf,稳妥第一。

4.2 登录鉴权与密码加密的落地实现

登录模块涉及两个核心问题:密码存储和会话保持。

密码存储千万不要明文存数据库,最低要求也要用 MD5 加盐,更稳妥的是 BCrypt。Spring Boot 的spring-security-crypto单独引进来就能用BCryptPasswordEncoder,即使你没用 Spring Security,也可以单独使用它来做加密:

// 加密 String encoded = BCryptPasswordEncoder().encode("123456"); // 校验 boolean matches = BCryptPasswordEncoder().matches("123456", encoded);

BCrypt 的好处是每次加密结果都不同,但校验时依然能匹配,而且自带盐,安全性远超 MD5。答辩时如果有人问你“密码加密怎么做”,一口答出 BCrypt 会显得很专业。

会话保持用 Sa-Token 的话,登录成功调用StpUtil.login(userId)后,前端会在响应头里拿到 token,后续请求带上 token 即可。如果做前后端分离,还要在 Sa-Token 配置里开启 CORS 跨域,允许前端携带 token。

4.3 前端页面与后端接口对接的实操经验

如果你选了 Vue 方案,项目里一定要有一个统一的 axios 封装,所有请求都走封装好的实例,统一带上 token、统一处理响应错误码、统一提示后端返回的 message。没有这层封装,每一处的业务代码都会变成“请求 + 处理 + 弹窗”的重复劳动。

接口对接时最容易犯的一个错是:后端返回的字段命名是下划线风格(patient_no),前端 JS 习惯用驼峰(patientNo)。要么在 VO 里直接转成驼峰,要么在 Jackson 配置里设置spring.jackson.property-naming-strategy: SNAKE_CASE统一风格。没有统一约定的话,前端会反复因为字段名对不上而出 bug,而且这种 bug 排查起来非常费时间。

我建议后端所有 VO 字段直接用驼峰命名,配合 MyBatis Plus 的map-underscore-to-camel-case自动映射数据库下划线字段,这是最顺滑的组合,基本不用额外写配置。

5. 常见问题与排查技巧实录

5.1 环境与启动类问题

我每年都能看到大量同学卡在“项目启动不起来”这个阶段。这里把最常见的问题和解决方案整理成一张速查表:

Spring Boot 版本太高导致的兼容性问题也很常见。比如 Spring Boot 3.x 里javax包改名为jakarta,很多老代码直接搬过来就报错。这就是我前面建议用 2.7.x 的原因之一。不是新版本不好,而是毕设时间有限,没必要在环境兼容性上浪费宝贵的开发时间。

5.2 数据库连接与查询问题

• 时区报错:The server time zone value 'Öйú±ê׼ʱ¼ä'。在数据库连接 URL 后面加上serverTimezone=Asia/Shanghai。
• 连接被拒:Access denied for user 'root'@'localhost'。密码不对,或者用户没有远程访问权限。毕设基本都在本地,检查本机密码即可。
• 中文乱码:数据库连接 URL 加characterEncoding=utf8,建表语句统一用utf8mb4,另外 IDEA 的Help → Edit Custom VM Options加一行-Dfile.encoding=UTF-8防止编译器乱码。
• 使用 SSH 连接远程数据库:当时网上的一个热词是“springboot 连接 mysql 但是有 ssh 认证”,这种情况如果在毕设里遇到,通常是你想连服务器上的数据库,但服务器只开放了 SSH 端口。解决办法有两种:一是用 Navicat 的 SSH 隧道连上去把数据导到本地;二是用 IDEA 的 Database 工具配置 SSH 隧道。Spring Boot 项目本身连数据库时是不走 SSH 的,如果非要在生产环境这么连,需要自己写 SSH 端口转发,但毕设完全没有必要这样搞,直接把数据库装本地或者放开数据库端口即可。

5.3 业务功能 Bug 与答辩演示技巧

功能层面最常见的坑集中在挂号状态流转和处方金额统计。状态流转的逻辑一定要用常量或枚举管理,不要写散落的魔法数字。比如挂号状态 0、1、2、3,建议定义枚举类:

public enum RegStatus { PENDING(0, "待就诊"), FINISHED(1, "已就诊"), CANCELED(2, "已取消"), MISSED(3, "已过号"); private final int code; private final String desc; }

否则代码里到处都是if (status == 0),看两个月之后你自己都记不清 0 代表什么。

演示答辩时有一个技巧:提前准备一套“有故事的数据”。比如患者张三挂了心内科李医生的号,李医生写了病历、开了两种药,收费处完成结算,药房完成发药。这套数据要预先插入数据库,演示的时候按这个流程点一遍,业务闭环一目了然。很多同学平时测试都是随手乱输数据,什么“测试123”“abc”,到演示那天数据混乱不堪,老师看着就皱眉。

另外,演示前一定要提前检查图片上传路径、本地数据库是否启动、前端依赖是否安装完毕。我在带学生做毕设时发现,起码有一半的演示翻车事故不是系统有问题,而是“数据库没开”“前端 node_modules 没装”“文件上传路径不对”这种低级环境问题,提前半小时彩排一遍,能避免绝大多数尴尬。

6. 实操总结与个人经验分享

能坚持看到这里的,大概率是真的打算把这个系统做出来。我再送你几句掏心窝的话。

第一,不要追求功能的“大而全”。与其做二十个用不上的模块,不如把挂号、就诊、开方、收费这条主链路打磨到无懈可击。我见过太多人在系统管理、日志管理这些边缘功能上死磕,结果核心业务漏洞百出,到答辩前一周还在改 Bug。

第二,命名规范和代码整洁度值得你额外花点时间。老师不一定逐行读你的代码,但如果你把 Controller、Service、Mapper 分层写清楚,类名、方法名、数据库表名都符合规范,代码整体看起来赏心悦目,这个第一印象非常重要。反过来,即便功能都实现了,代码堆成一坨,老师大概率会觉得你只是“抄来的”。

第三,把核心难点写在 README 里。我建议每个人都在项目根部写一个 README,内容包括:项目介绍、技术栈、如何启动、核心业务流程、自己在开发中遇到的难点和解法。这份文档不仅是给老师看的,更是给你自己准备的答辩提词器。

第四,也给自己留一个“拔高点”。权限控制、并发挂号、定时任务、yml 密文、Flyway 版本管理,这些点不需要全做,挑一个做深做透,答辩时重点讲这个,效果比你平平无奇地讲完整套 CRUD 好十倍。我在实际参与毕设指导时反复说的一句话就是:毕业设计不是比谁功能多,而是比谁能证明自己真正理解了这个系统是怎么跑起来的。挑一个点钻下去,你就赢了大多数只做增删改查的同学。