珍妮之吻做中药材店铺管理系统这个题目，其实比很多人想象的要有意思。乍一看就是个进销存系统，无非就是商品管理、订单管理、库存管理那一套常规操作。但真正动手做下来，你会发现中药材这个品类给系统设计埋了不少暗坑，而且这些坑恰恰是让这个项目区别于普通超市管理系统的价值所在。我这两年带过好几个做这个方向的同学，也自己完整重构过一版，今天把这套基于 SpringBoot 的中药材店铺管理系统从设计到部署的完整思路捋一遍，希望能帮到正在做同类项目的朋友。
1. 整体设计思路：为什么中药材店铺系统不能只做增删改查
先说个最关键的判断：如果你的毕设或者商业项目只是把一张商品表四个字段（名称、价格、库存、分类）做成 CRUD，那这个系统没有任何竞争力。中药材管理有一个天然的特性——批次与品质的强绑定。同一味黄芪，产自甘肃陇西和产自山西浑源，价格和药效完全不同；同一批党参，存放半年和存放两年的含水量、色泽、有效成分也差很多。这就意味着系统的核心不是“商品”，而是“批次库存”。
所以我搭这套系统时，数据模型的核心不是商品表，而是批次库存表。围绕这个核心，业务链路自然分成两条：一条是采购进来的批次入库、质检、养护、库存变动，另一条是销售出库时的批次扣减、溯源查询、临期预警。这种建模思路，才真正呼应了“中药材店铺管理系统”的“中药材”三个字，而不是随便换个商品名称就能套用的通用模板。
技术选型上，我最终确定的是 Spring Boot + MyBatis-Plus + MySQL 的组合，前端为了部署方便选了 Thymeleaf + Bootstrap，没有做前后端分离，而是用了服务端渲染。可能有同学会问，现在不都流行 Vue + SpringBoot 前后端分离吗？我的看法是——如果目标是快速交付一个完整可用、边学边改的项目，服务端渲染的维护成本低很多，部署也省事，直接打成 jar 包扔服务器就完事，不用再单独维护一套 Nginx 来托管前端静态资源。这套方案对个人学习和毕设场景非常友好，哪怕你是第一次接触 SpringBoot，也完全可以在两到三周内跑通全流程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计：把中药材的“灵魂”塞进表结构
2.1 核心表结构：药材档案、批次和库存的关系
我在第一版设计里犯过一个错误，就是参照超市系统的库存表设计，用 product_id 作为唯一维度来记录库存数量，结果后面加了批次字段后，整张表的逻辑全乱套了。后来我重新拆分，把数据模型调整为三张核心表：
- drug_info（药材档案表）：记录药材的名称、别名、性味归经、功效主治、产地、规格、计量单位、储存条件、图片路径、状态。这里要特别说明，药材档案并不是“库存”，它只是基础字典，类似于商超系统的商品主数据。
- drug_batch（批次表）：每个入库批次对应一条记录，字段包括批次号（业务生成，比如采购单号加序号）、药材ID、供应商ID、采购单价、采购数量、入库日期、生产日期（采收日期）、有效期（保质期）、储存位置、养护说明、品质等级、当前剩余数量。
- inventory_stock（库存表）：以 batch_id 为粒度维护当前库存余量，同时冗余一份 drug_id，方便按药材聚合查询总库存。
为什么要单独拆 inventory_stock 而不是直接在 batch 表上更新剩余数量？因为在大多数业务场景下，我们要区分“某批次的初始入库量”和“当前剩余量”，这两个数字对经营分析都很重要——前者体现采购规模，后者体现当前可售状态。如果只留一个字段，历史统计就会失真。
三张表之间的关系用一句话概括：drug_info 是静态字典，drug_batch 是一次一次垒起来的历史记录，inventory_stock 是实时状态。这样设计之后，后面做溯源查询就非常顺——用户在前台看到某味药材，点开详情，可以直接查到当前所有在售批次，每个批次的产地、入库时间、品质等级一目了然，这就是“中药材店铺”区别于“便利超市”的体验细节。
2.2 库存预警与养护记录：容易被忽略的两张表
除了上面三张主表，还有两张表如果你没做，系统会显得很“业余”。第一张是 stock_warning_log（库存预警记录表）。中药材行业对缺货和临期都非常敏感，缺货影响日常销售，临期则直接关系到用药安全。预警不能只在页面展示一条临时信息，最好每次触发都写入日志表，这样后期可以统计“哪几种药材频频临期”“哪个供应商的批次品质波动大”，这就是店铺经营层面的数据资产。
第二张是 drug_care_log（养护记录表）。懂行的人都清楚，中药材在库房里的养护是个持续过程，需要定期检查是否受潮、生虫、霉变，翻垛晾晒也要留记录。虽然在“毕设级别”的系统里这个模块往往做成简单的添加和列表，但表结构一定要提前留好——药材ID、批次ID、养护日期、养护方式、发现的问题、处理结果、操作人。这就让系统从单纯的销售工具变成了有一定业务深度的管理工具。
这两张表的设计思路，我给一个建议：不要等需求文档里写了才做，自己主动加上去，这在答辩时是一个非常亮眼的差异化亮点。同样的功能，你做出来了并且能讲清楚为什么做，效果完全不一样。
3. 后端模块实现：从登录到报表的完整链路
3.1 项目初始化和依赖如何选
项目我用的 Spring Boot 2.7.18，这是 2.x 系列的最后一个版本，稳定而且和大多数教程兼容。为什么不用 Spring Boot 3.x？核心原因在于 3.x 要求 JDK 17，而很多实训环境、服务器上跑的还是 JDK 1.8，如果为了赶新潮选了 3.x，在部署环节很容易被环境折腾到崩溃。Spring Boot 2.7 配合 JDK 1.8 和 MyBatis-Plus 3.5.x，是一套在