其实做这类系统最烦的就是“毕设项目”变成“摆设项目”——数据库建好了、页面能跳转、演示一过就吃灰。这篇我打算换个思路聊：不是说怎么凑出一个能答辩的药房购药系统，而是把一个选题拆成一套真正有逻辑的业务闭环，从需求梳理到表结构、从库存并发到权限设计，尽量站在“以后还能往下做”的角度把每一步讲透。尤其适合正在做JAVA毕业设计、或者想拿现成源码却看不懂模块之间怎么协作的同学。
我自己用JAVA做过好几个类似的进销存、订单类系统，药房购药跟普通商城最大的区别是：它沾着“药品”两个字，就意味着库存要准、效期要盯、特殊药品要有记录，这不是单纯加个购物车那么容易。所以这篇文章会按照我自己写这类系统的思路来展开，包括为什么选用Spring Boot + JSP的单体结构、库存为什么用预扣减而不是直接改数量、金额为什么必须用BigDecimal、权限为什么不能只靠菜单隐藏。文章里所有代码片段都是从本项目里提炼出来的核心逻辑，骨架完整，你可以直接照着扩展。
1. 项目定位与整体设计思路
1.1 这个系统到底要解决什么问题
买药和买衣服不一样。买衣服你加入购物车、下单、支付，流程结束可能就完事了。买药牵扯的东西更多：得能看到药品的规格、厂家、批准文号，得知道库存还剩多少，得区分处方药和非处方药，有的药还要登记购买者的基本信息。这些约束决定了药房购药系统不是一个简简单单的“商城demo”，而是一个带行业约束的业务系统。
这个项目的选题叫“基于JAVA的药房购药系统的设计与实现”，核心要做的事可以拆成几条线：
- 面向顾客的在线购药流程：注册登录、浏览药品、搜索筛选、加入购物车、提交订单、模拟支付、查看订单状态。
- 面向药房工作人员的药品管理：药品上架、分类维护、库存盘点、效期预警、订单审核与发货。
- 面向系统管理员的权限与数据维护：用户管理、角色分配、订单全流程跟踪、基础数据配置。
- 支撑这些业务的基础能力：用户认证、统一异常处理、日志记录、数据统计。
这几个模块凑齐了，才叫一个“药房购药系统”，而不是一个“购物页面”。
1.2 为什么选JAVA + Spring Boot + JSP这套技术栈
JAVA在毕业设计里出现频率最高的原因，一是教学体系里JAVA是主力语言，二是JAVA的生态足够成熟，网上资料、框架文档、排错经验一抓一大把。但“JAVA”和“JAVA框架”是不同的概念，选型时我建议直接用Spring Boot，而不是Servlet + JSP全手写。
Spring Boot的好处不用多说，内嵌Tomcat、自动配置、起步依赖，写个接口几行代码就完事。很多同学担心用Spring Boot显得“不够底层”，答辩时老师问几句框架原理就答不上来。我给个实在建议：你可以用Spring Boot做项目主体，但你得把Spring MVC的请求处理流程、依赖注入的原理、MyBatis的Mapper代理机制弄清楚——毕设答辩不看你用了多新的技术，而是问你为什么这么设计、遇到问题怎么排查。
JSP在这套系统里承担的是视图层。现在前后端分离很流行，但毕设场景下JSP反而有优势：不用处理跨域、不用单独部署前端项目、开发调试直接改页面就能看到效果。药房管理后台这类系统对交互要求没那么高，JSP + Bootstrap就够用了。如果你想体现一点工程化意识，可以加一个Thymeleaf替代JSP，或者把Vue单独拎出来做前端，这要看你自己的精力。
1.3 单机单体架构还是微服务
听到“微服务”三个字很多同学就兴奋，但药房购药系统的真实业务量，单体架构完全能扛住。我甚至建议你在论文里写清楚：本系统采用单体架构，后续若业务量增长，可按照模块边界拆分为独立的用户服务、订单服务、库存服务。这句话既体现了设计思考，也避免了自找麻烦。
单体架构的模块划分依然要按照业务的边界来组织，否则代码很快就变成大泥球。我的习惯是先按功能分层，再按业务模块分包。举个例子：
com.pharmacy.system ├── common // 通用工具、统一返回、异常定义 ├── config // 配置类（拦截器、全局异常、跨域配置） ├── controller // 控制层，各业务模块的controller ├── service // 服务层，业务逻辑接口与实现 ├── mapper // 持久层，MyBatis的Mapper接口与XML ├── entity // 数据库实体对象 ├── vo // 视图对象，给页面或接口返回的数据结构 ├── dto // 数据传输对象，接收前端参数 └── interceptor // 自定义拦截器这样一个包里装了什么，从目录名就能看出来。模块之间通过service互相调用，避免controller直接操作别人的mapper。分层清楚的好处是：出了问题知道去哪翻代码，答辩时讲起架构也明明白白。
2. 核心业务模块与数据库设计
2.1 业务模块的全景拆解
药房购药系统的功能模块，我在设计时从来不上来就写代码，而是先列出一张业务流程图。画图不是为了交文档，而是为了理顺“谁、在什么条件下、能干什么”。下面是我整理出的核心模块清单，请对照着你的项目核对一下是不是都覆盖到了。
- 用户端模块：注册、登录、个人信息维护、收货地址管理、购药记录、收藏药品。
- 药品浏览模块：药品分类展示、关键字搜索、按价格和销量排序、药品详情查看。
- 购物车模块：加入购物车、修改数量、删除药品、清空购物车、计算总价。
- 订单模块：提交订单、订单确认、取消订单、订单支付状态更新、订单删除。
- 药品管理模块：药品新增、编辑、上下架、分类管理、库存设置、效期管理。
- 销售管理模块：订单列表查询、订单发货、销售统计、热销药品排行。
- 客户管理模块：客户列表、客户等级、购药记录跟踪。
- 系统管理模块：用户管理、角色管理、菜单权限、操作日志。
如果你拿到的是这套系统的源码，打开首页导航就能看到这些入口的雏形。每个模块之间不是孤立的，比如药品一上架，用户端马上能搜到；用户下单，库存就跟着扣减；支付成功，订单状态就流转到待发货。这就是模块之间“咬合”的地方，也是设计难点所在。
2.2 数据库表结构怎么设计才算合理
数据库设计是这类项目能不能落到实处的关键。药房购药系统的核心表我认为有八张，外加几张辅助表，下面给你逐个过一遍：
第一是用户表。除了基本的用户名、密码、手机号，要留一个role_id字段做角色区分。密码存储用加密方式，不要明文存，毕设答辩老师看到明文密码容易追问安全性。第二是药品分类表。一级分类和二级分类最好分开设计，比如感冒用药下面还有中成药和西药，用parent_id做自关联就可以支持无限层级。第三是药品表。字段要包含药品名称、通用名、规格、厂家、批准文号、零售价、进货价、库存、销量、上架状态、图片路径。零售价和进货价为什么分开？因为统计报表要看毛利的，随便写个total_price后期根本算不出利润。
第四是购物车表。设计要点是用户ID + 药品ID联合唯一，用户同一个药品只能存在一条记录，数量字段单独维护，这样加减数量时不用反复插删数据。第五是订单表。订单编号、用户ID、总金额、优惠金额、实付金额、订单状态、收货人信息、下单时间、支付时间。这里要提示一个常见错误：订单表里不要只存一个收件人姓名，电话、地址都要冗余进来，因为订单是历史快照，用户后来改了地址并不影响已下的订单。第六是订单明细表。每条明细对应订单里的一种药品，包含药品名称快照、单价、数量、小计。同样，药品名称、价格也要快照存储，否则药品改名或调价后，历史订单显示会出现错乱。
第七是库存表。很多同学把库存字段直接堆到药品表里，这样做不是不能用，但盘点、入库流水都不好追溯。我的习惯是单独建一张库存表，一个药品一条记录，字段包括总库存、锁定库存、可用库存。锁定的含义后面讲订单流程时会详细说。第八是操作日志表。谁在什么时间操作了什么，保底留一条记录，这在答辩时可以讲成“系统具备操作追溯能力，满足合规审计需求”。
下面是建表时可以抄作业的简化骨架，实际字段你在源码里能看到更完整的版本：
CREATE TABLE `drug` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL COMMENT '药品名称', `generic_name` varchar(100) DEFAULT NULL COMMENT '通用名', `category_id` int DEFAULT NULL COMMENT '分类ID', `specification` varchar(50) DEFAULT NULL COMMENT '规格', `manufacturer` varchar(100) DEFAULT NULL COMMENT '生产厂家', `approval_number` varchar(50) DEFAULT NULL COMMENT '批准文号', `retail_price` decimal(10,2) NOT NULL COMMENT '零售价', `cost_price` decimal(10,2) DEFAULT NULL COMMENT '进货价', `image` varchar(255) DEFAULT NULL COMMENT '药品图片', `status` tinyint DEFAULT '1' COMMENT '1上架 0下架', `prescription_flag` tinyint DEFAULT '0' COMMENT '0非处方 1处方药', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='药品信息表';价格字段用decimal(10,2)，这是常识但也是高发错误。用float和double存金额，算术运算会出现0.1 + 0.2 != 0.3这类问题，药房订单金额一旦产生小数尾差，对账就会对不上。JAVA侧对应使用BigDecimal，这个细节下面还会再讲。
2.3 数据库字段与页面展示的对应关系
设计和实现脱节是常见问题，表现为页面想要的数据查不出来，表里存的字段页面没用上。我的办法是做表结构时在注释里直接写明这个字段会在哪个页面、哪个位置展示。比如药品表的prescription_flag，用户端详情页就要靠它显示“处方药”标签，同时前端要限制：处方药不能直接点“立即购买”，页面要弹出提示框“该药品为处方药，请咨询药师后下单”。这个逻辑如果表和页面不对应，实现时很容易漏掉。
分类表和药品表之间的关联通过category_id完成，用户端导航栏的分类列表就是从分类表实时查出来的，不是写死的HTML。好处是运营人员在后台上架新分类，前台导航会自动更新。这种“一个改动全链路生效”的体验，是判断系统设计得好不好的直观标准。
3. 库存扣减与订单流转的核心流程
3.1 订单提交时库存是怎么一步步扣减的
药房库存管理比普通商品库存更敏感，药品卖完了就得等补货，超卖更不行——顾客付款后你去调货，体验极其糟糕。所以在订单提交这个环节，我设计了一套预扣减流程，你可以直接参考它的思路。
整个流程分三步走。第一步，用户提交订单时，系统检查每个药品的“可用库存”是否充足。第二步，如果充足，同时把“锁定库存”加上对应数量，这个操作叫预占库存，相当于把货先给你留住了。第三步，订单支付成功后，锁定库存正式转为已扣减状态，也就是“总库存减少、锁定库存减少”，同时增加销量。
这样做的好处是：从用户下单到支付完成这中间，药品不会被人抢走，而且不会出现库存负数的脏数据。如果用“直接扣减库存”的粗暴方式，用户下单还没支付，库存就减了，结果他最后没付款，库存却白白少了，每天跑一遍对账会发现差了超多货。
对应的可用库存计算SQL可以这么写：
UPDATE stock SET locked_stock = locked_stock + #{quantity}, available_stock = available_stock - #{quantity} WHERE drug_id = #{drugId} AND available_stock >= #{quantity}注意这个SQL是带条件的，available_stock >= #{quantity}就是一道保险锁，如果库存不够，受影响行数为0，代码里通过判断影响行数来决定是否回滚事务。这比先查库存、再更新这种“先查后改”的方式安全得多。
3.2 订单状态的流转设计
药房购药系统的订单状态，我经常看到有人用一串数字0到5表示，页面里到处switch判断，代码看着乱，逻辑也容易漏。我建议用一个常量类或者枚举把状态集中管理：
public enum OrderStatusEnum { PENDING_PAYMENT(0, "待付款"), PENDING_DELIVERY(1, "待发货"), DELIVERED(2, "待收货"), COMPLETED(3, "已完成"), CANCELLED(4, "已取消"), REFUNDING(5, "退款中"); private final Integer code; private final String desc; // 构造方法和getter省略 }状态机里的合法流转路径是固定的：待付款能走到待发货（支付成功）或者已取消（用户取消）；待发货只能走到待收货（发货完成）；待收货只能走到已完成（确认收货）。不该允许待收货直接跳已完成由用户操作，应该给一个“确认收货”接口，由前端按钮触发，后台校验当前状态后再更新。
每个状态变更时，我强烈建议同步写一条日志。比如“用户在2025-05-20 14:30把订单从待付款变更为已取消，原因为超时未支付”。后来做运营统计分析或者排查纠纷时，这些日志的价值远比你想象的大。
3.3 支付环节怎么模拟才显得专业
毕设项目对接真实支付通道不太现实，但也不能用“点击支付直接改成已支付”这么糊弄。我推荐的方案是引入一个支付单的概念，把支付动作和订单状态解耦。
核心思路是：建立payment_record表，包含订单号、流水号、支付金额、支付方式、支付状态。用户点击支付时，后台先创建一条支付单，状态为待支付；然后模拟一个“第三方支付网关处理中”；处理成功后回调更新支付单状态，再联动更新订单状态。这样做的好处是代码结构里payment、order两层分开，将来如果真要接入微信支付或支付宝，只需要替换支付网关的实现类，业务代码不用大动。
模拟支付的页面，你可以做成一个二维码占位图，旁边显示“请扫码支付（演示环境自动支付成功）”，几秒后前端轮询订单状态，发现已支付就跳转订单详情页。这个交互比“啪一下变成已支付”专业得多，答辩时也有东西讲。
3.4 金额计算的细节处理
金额计算在订单流程里的地位很容易被低估。小计、运费、优惠、合计，每个环节都可能出现精度问题。我定下的铁律是：所有金额字段一律用BigDecimal，禁止使用double和float。数据库里用decimal，JAVA实体里用BigDecimal，JSON传输时用字符串或者做好序列化配置，避免前端拿到浮点数丢失精度。
如果系统支持优惠券，一定要把优惠分摊到每个订单明细上，而不是只改订单总金额。因为后续如果做“订单退款”功能，退单里某一个药品时，要能算清楚这单个药品实际付了多少钱。同一个订单如果包含甲乙两种药，整单减了10元，退款时退甲的金额就不能瞎写。
订单总金额的计算我建议放在服务端的service层完成，不要信任前端传过来的金额参数。前端的合计仅供参考，服务端根据数据库里的单价和数量重新计算一遍再做校验，这是防止篡改价格的基础手段。
4. 权限模型与项目安全设计
4.1 用户角色怎么划分才够用
药房购药系统至少需要四类角色：顾客、药师、仓库管理员、系统管理员。有的系统里还会拆出收银员和店长，毕设里四个足够了。每类角色的菜单权限和操作权限不同，核心控制点如下：
顾客只能操作个人中心、购物车、订单和自己的收货地址，不能碰管理后台。药师除了基础功能，还能查看药品详情、处方药信息、审核特殊订单。仓库管理员可以管理药品库存、处理发货，但看不到销售统计报表。系统管理员拥有一切权限，包括用户管理、角色分配、日志查询。
关于权限的落地方式，市面上成熟的做法是RBAC模型——用户-角色-权限三层结构。数据库设计里加一张菜单表或权限表，一张角色菜单关联表，用户登录后把菜单权限加载进Session或Redis缓存，前端根据权限动态渲染菜单，后端根据权限拦截非法请求。
我这里想强调一个很多毕设里容易漏掉的点：前端隐藏菜单只是面子工程，后端必须做真正的权限校验。别人拿个工具直接调你的接口，菜单隐藏根本挡不住。所以服务端的拦截器里要校验用户角色是否匹配接口权限，或者直接在敏感操作的Controller方法上使用自定义注解做权限标记，比如@RequiresRole("ADMIN")。这部分代码完全可以在答辩时作为亮点提。
4.2 登录状态管理怎么做
登录状态管理涉及安全性，也是面试题和答辩常见追问点。用HttpSession存登录状态是最省事的方案，但存在一个隐患——用户关掉浏览器后Session失效，又要重新登录。更轻量、更常见的做法是使用JWT或者Redis + Token的认证方式。
毕设场景我用的是JWT方案，原因是不用额外搭Redis。用户登录成功后服务端签发一个带有效期（比如2小时）的Token令牌返回给前端，前端存到localStorage里，每次请求在Header里带上。后端配置一个拦截器，通过拦截器解析Token拿到当前用户信息，再放行请求。
JWT的组成你可以这么理解：头部声明加密算法和Token类型，载荷部分存用户ID、用户名、角色和过期时间，签名部分用服务端密钥对前两部分做签名防止伪造。写论文时把这套机制讲清楚，就是一个很好的“安全性设计”章节素材。
4.3 常见安全漏洞的防范意识
就算是个毕设项目，一些基本的防攻击意识也要有。第一是SQL注入。如果你用了MyBatis的#{}，它预编译参数可以防注入；但如果你图省事写${}拼字符串，那等于给攻击者开门。源码里所有动态查询请检查一遍，禁止出现${}拼接入参的情况。
第二是密码明文存储问题。我见过不少系统的数据库里password字段直接存123456，答辩时一旦被问到就很尴尬。至少要使用MD5加盐或者BCrypt做加密。Spring Security自带BCryptPasswordEncoder，单独引一个工具类也行。尽管是演示项目，你也要在论文里体现“密码加密存储”的安全考虑。
第三是越权漏洞。水平越权的典型场景：用户A查看或修改用户B的订单。解决办法是查询订单时，必须同时带上当前登录用户的ID作为条件，不能只通过前端传的订单号查询。垂直越权的典型场景是普通用户访问管理员接口，解决办法就是上面说的后端权限校验。这两类问题在真实项目里是高频漏洞，你能在自己的毕设里规避并且讲得出方案，是很大的加分项。
4.4 操作日志如何记录
操作日志这个模块往往被当成“锦上添花”，但药房系统这类涉及药品销售、库存调拨的业务系统，操作留痕是基本要求。我的实现方式是使用Spring AOP做一个切面，通过自定义注解标记需要日志记录的方法，方法执行完自动记录操作人、操作对象、操作类型、操作时间、请求参数和IP地址。
不用把日志和业务代码写在一起，避免代码到处都是System.out打印。AOP的好处是侵入性低，业务代码不用关心日志怎么记，只需要在方法上加一个@OperationLog("修改药品库存")注解。整理日志查询页面时，按用户、按时间区间、按操作类型筛选，一套就成型了。
5. 部署运行与高频坑位排查
5.1 环境准备与快速启动步骤
拿到源码之后，最怕的就是运行不起来。环境排查第一步，确认JDK版本和Spring Boot版本的匹配关系。如果源码用的Spring Boot 2.x，推荐JDK8或JDK11；如果Spring Boot 3.x，就必须JDK17及以上，用错版本启动直接报错。第二步，确保Maven配置了国内镜像（阿里云中央仓库），否则依赖下载能卡到你怀疑人生。第三步，配置MySQL数据库，版本建议5.7或8.0，导入项目里自带的sql文件。第四步，确认数据库连接信息在application.yml里的配置，账号密码不要写错。
启动成功跑起来之后，先不要急着点功能，建议按我刚才说的业务模块逐个验证：注册一个新用户，登录，看药品列表能不能加载；加几个药品到购物车，走一遍下单流程，重点看库存变化和订单状态；登录管理员账号，看看药品管理、订单管理、用户管理页面各自是否正常。
5.2 常见错误与排查清单
我在跑这类项目时，踩过不少坑，也帮人排查过不少类似项目的问题，把高频问题整理成一张速查表，希望能帮你省点时间：
| 常见报错 | 根本原因 | 排查方向 |
|---|---|---|
| 启动报端口被占用 | 8080被其他进程占用，或Tomcat配置冲突 | 命令行输入 netstat -ano | findstr :8080，找到进程PID后结束任务，或改yml里的server.port |
| 数据库连接失败 | 密码错误、数据库没启动、库名不对 | 核对application.yml的url、username、password，先通过数据库客户端连接验证 |
| 中文乱码 | 字符集配置不一致 | 数据库连接URL加useUnicode=true&characterEncoding=UTF-8，页面统一设置UTF-8，JSP顶部确认pageEncoding |
| 页面报404 | 请求路径或静态资源路径错误 | 检查Controller的@RequestMapping映射值是否和页面访问路径一致，检查静态资源是否放在static目录下 |
| 实体映射字段报null | 数据库下划线字段和实体驼峰字段没匹配 | MyBatis开启mapUnderscoreToCamelCase=true配置，或XML里给查询列加别名 |
| 启动报ClassNotFoundException | 依赖没有正确导入 | 在Maven面板执行reload，或者删掉本地仓库对应依赖目录重新下载 |
这里再补充一个比较隐蔽的坑：多个用户同时下单，商品库存出现负数或者超卖，说明你用的是先查询再更新，没有做好并发控制。解决思路前面已经提过，就是用带条件的UPDATE语句来判断库存是否充足，结合事务处理。
5.3 代码里值得深挖的切入点
拿到源码后，如果只想准备答辩，我的建议是把这几块代码吃透，面试和论文都用得上：一是登录认证的完整链路，从前端提交账号密码，到后端生成Token，再到拦截器的校验过程；二是订单提交的事务处理流程，怎么保证“订单生成+库存扣减+状态变更”同时成功或者同时回滚；三是MyBatis的Mapper接口和XML文件是怎么关联的，为什么接口方法名要和XML的id一致；四是Spring Boot启动类的注解，@SpringBootApplication组合了哪些注解。
如果源码里有Redis缓存药品列表、或者用了Spring AOP写日志，那更是加分点，优先把这两块读懂。能把“项目里用了什么技术”和“为什么要用”讲清楚，答辩基本稳了。
还有一个加分技巧，你可以给药品列表加一个简单的缓存设计：查询药品列表时先从Redis检查是否存在，没有则查数据库并写入Redis，设置5分钟过期。这在答辩时就是“提升系统性能的缓存策略设计”。注意，如果用缓存，药品上下架时要记得删除对应缓存，否则会出现前台已经下架但页面还能买到的逻辑错误。
5.4 后续扩展空间与升级路线
最后说点实在的。项目跑到这一步，你完全可以做几个延伸方向，难度递增，但工作量可控。第一方向是增加统计报表模块，基于订单数据按日、按月统计销售额、热销药品Top10、库存周转率，用ECharts画几张图表放到首页，这就是一个完整的“数据可视化”亮点。第二方向是接入WebSocket，顾客下单或退款后，后台收到实时通知，能体现你对实时通信的理解。
第三方向是把单体项目按模块拆分成微服务，虽然工作量不小，但可以只做“订单服务+药品服务”两个服务的拆分演示，配合Nacos注册中心，在架构上又是高阶加分项。所有扩展方向的前提是先把基础功能跑稳，主流程不出bug，再谈优化。
我个人在这些项目的实践里最大的体会是：很多看起来“高大上”的系统，最后跑不起来的核心原因都不是缺技术，而是没有把业务逻辑跟数据设计对齐，没有把关键的边界条件考虑进去。药房购药系统也是一样，你多花点时间在库存扣减的条件、订单状态的流转、金额精度的处理上，跑起来一定比那些只搭了CRUD框架的demo稳重得多。希望这篇能把你的思路理顺一些，接下来的代码调试阶段，遇到具体的报错再去查对应资料，效率反而最高。
