李祥JasonLee每年到做毕设和课程设计的季节，我总能收到同一类问题：“基于SpringBoot的中药材店铺管理系统怎么做？源码有了但不会部署怎么办？”说实话，这种带源码、带部署文档、带讲解视频的项目包，是很多同学的第一选择，但真到自己手上，从启动到跑通，每一步都可能卡住。这篇博客我就结合这个项目，把SpringBoot中药材店铺管理系统从技术选型、数据库设计、核心业务实现到部署上线的全流程拆开讲清楚，顺便把那些“带源码也搞不定”的坑都给你填上。
这套系统本质上是一个典型的中小规模进销存管理系统，但它比普通的“学生管理系统”“图书管理系统”更有意思的地方在于：中药材这个业务领域有大量特有的规则——产地、等级、炮制方法、克斤换算、批次效期、湿度存储要求，都要落进系统里。也正因为如此，它非常适合用来练手SpringBoot + Vue前后端分离、MyBatis Plus操作MySQL、JWT鉴权、定时任务、文件上传、Docker部署这一整套现代Java Web开发的主流技能栈。
如果你正在选毕设题目，或者刚拿到一份SpringBoot项目的源码但不知道从哪下手，这篇内容可以帮你把整个项目从“能看懂”推进到“能自己跑起来、能讲明白、能应付答辩”的程度。
1. 系统整体设计与技术选型拆解
1.1 为什么是SpringBoot而不是SSH或SSM
很多同学的课程里还在教SSH（Struts2 + Spring + Hibernate）甚至更老的技术，但到了毕业设计阶段，我强烈建议你选SpringBoot。原因很直接：SpringBoot不是取代Spring，而是把Spring的配置复杂度收走了。以前SSM项目里要写一大堆XML——数据源配置、事务管理配置、MyBatis的Mapper扫描配置、包扫描配置——在SpringBoot里大部分变成了自动装配和约定优先。你只需要在pom.xml里加上依赖，再写一个application.yml，项目就能跑起来。
从答辩角度来说，SpringBoot这个选型本身就意味着你了解行业现状，因为现在绝大多数Java后端岗位面试讲的就是SpringBoot、Spring Cloud、微服务这套生态，而不是SSH。用人单位看你的简历上写着“基于SSH做的XX管理系系统”，第一反应通常是停留在五年前的水平。面试官也更愿意问SpringBoot自动装配原理、Starter机制这类有深度的问题。
另外，SpringBoot对中小型系统非常友好。像中药材店铺管理系统，用户量不大，并发不高，单体架构完全够用，不需要上微服务那套。用SpringBoot做单体应用，结构清晰、部署简单，一个jar包扔到服务器上就能跑。你与其为了简历好看硬上一个微服务组件，不如先把单体项目做扎实。
1.2 技术栈搭配与版本选型的逻辑
这个项目的技术栈是经典的“SpringBoot + MyBatis Plus + MySQL + Vue”，我用了很长一段时间，非常稳。具体版本选择上，这是第一个要命的地方，因为SpringBoot版本差异非常大。
如果你用的是JDK 8，SpringBoot就老老实实选2.7.x系列，不要上3.x。SpringBoot 3.0以后强制要求JDK 17，默认使用Jakarta EE命名空间——最直观的变化是javax.servlet变成了jakarta.servlet，MyBatis Plus也有专门的对应版本。很多同学拿到源码后直接把SpringBoot升级到最新版，结果一堆注解报错、依赖冲突，其实不是代码问题，是版本不匹配。
我当时用的是SpringBoot 2.7.18，这是2.x系列的最后一个版本，也是JDK 8下最稳妥的选择。MyBatis Plus用的3.5.x，对应MyBatis 3.5以上版本，分页插件、代码生成器都齐全。MySQL用的5.7，虽然8.0也兼容，但5.7对JDBC驱动的兼容性更好，部署时不容易出幺蛾子。前端如果是Vue项目，注意Node版本，Vue 2项目用Node 14/16，Vue 3项目用Node 16以上，这也是前端跑不起来的常见原因。
用表格总结一下我推荐的版本组合，方便对照：
| 组件 | 推荐版本 | 原因 |
|---|---|---|
| JDK | 1.8 | 与SpringBoot 2.x完全兼容，部署环境普及度最高 |
| SpringBoot | 2.7.18 | 2.x最后一个版本，稳定且资料多 |
| MyBatis Plus | 3.5.x | 内置分页插件、条件构造器，开发效率高 |
| MySQL | 5.7 | 稳定，JDBC兼容性好 |
| Node.js | 14或16 | 对应Vue 2项目构建要求 |
| Maven | 3.6.x | 兼容JDK 8，配置简单 |
1.3 项目目录结构与分层设计
拿到源码后，第一步不是急着启动，而是先看懂目录结构。这个项目采用的是标准的Maven多模块思想下的单模块分层：Controller层负责接收请求、Service层负责业务逻辑、Mapper层负责数据库操作、entity/domain层放实体类。只不过在SpringBoot项目中，这些目录都在同一个module下面，按包名区分。
看源码的时候我建议你按这个顺序去读：先看实体类（entity包），搞清楚数据库里有哪些表；再看Controller层，了解系统对外提供了哪些接口；然后看Service层，理解核心业务是怎么流转的；最后看Mapper层，重点看那些复杂的SQL是怎么写的。这个顺序能让你在最短时间内建立起对系统的整体认知。
这种分层设计的好处非常明显——职责单一、易于测试。如果答辩时老师问“为什么要把Controller和Service分开”，标准回答是：Controller层只负责参数接收和结果返回，不包含业务逻辑；Service层承载具体业务规则，可以独立进行单元测试；Mapper层屏蔽SQL细节，便于后续优化或替换持久层方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心业务模块与数据库设计思路
2.1 中药材特有属性建模，比普通商品表复杂在哪
中药材店铺管理系统不是简单的商品增删改查，关键在于“药材”这个业务对象有很多普通商品没有的属性。产地、等级（一级/二级/统货）、炮制方法（生用/炒制/蜜炙）、采收年份、储存条件——这些信息不仅要在商品表里体现，还会影响定价和库存策略。
在设计数据库时，主表是商品表（或者叫药材表），但绝不是只有名称、价格、库存这三个字段。我建议至少包含以下字段：药材名称、拼音码（方便快速检索，因为收银员很多时候记不住全名）、别名、产地、规格等级、炮制方法、单位（是“克”还是“斤”还是“袋”）、零售价、进货价、库存总量、预警阈值、存放位置、图片URL。
其中最容易出问题的是“单位换算”。中药材行业有个特殊习惯，进货可能是按“公斤”进，开方销售时按“克”出，有些贵细药材甚至按“克”进、“克”出。如果系统里只用单一单位，就会出现库存数字对不上的情况。设计时我建议单独建一个单位换算表，或者至少在主表里同时保存基本单位和换算比率。
另一个容易忽略的是“批次与效期”。中药材不是永久存放的，特别是一些果实种子类药材，超过保质期就要下架。因此库存表建议设计成批次维度——每次采购入库生成一个批次号，记录生产日期和有效期，销售出库时按