药品管理系统这题目每年毕业设计都能见到一大把但说实话大部分人做出来的东西本质上是个改了个药品名字的超市进销存。药品经营的核心逻辑——批号追踪、效期预警、GSP记录、处方药管制、特殊药品限量——全都没做进去。这篇文章我从业务本质讲到代码落地把基于SpringBoot的药房进销存一体化平台、医药供应链协同管理系统这类毕业设计里最容易被忽略、但恰恰是区分度高价值强的部分完整拆开讲一遍。适合正在做药品管理类毕设的学生也适合想转行医药信息化的开发同行参考。1. 药房进销存和超市进销存究竟差在哪先搞懂业务再谈设计很多同学拿到“药品经营管理系统”这个题目第一反应是去搜“进销存系统”的模板然后套一个商品表、订单表、库存表就开写了。真这么做答辩的时候老师随便问一句“你怎么处理同一种药多个批次的问题”基本就卡住了。药品经营管理和普通零售进销存的差异点核心在三件事第一是批次与效期。一瓶矿泉水放过期了损失一瓶水。一片阿司匹林放过期了问题就没这么简单了。药品从入库到出库全程必须按批次管理每个批次有生产日期、有效期、厂家批号。系统里同一款药品可能同时存在三个不同批次的库存每一批的效期都不一样。出库的时候按什么顺序出老批次先出也就是先进先出FEFO效期近的先出。这不是业务偏好是行业硬性要求。第二是合规留痕。药房每天要做温湿度记录、养护记录、处方审核记录、特殊药品购销记录这些不是可以事后补的Excel表而是一个经营管理系统必须承载的业务数据。评标、飞检、质量管理体系审核看的就是你有没有完整的电子记录链。第三是权限和审计的分级。不是所有人都有权限卖处方药一个系统里要分店长、药师、营业员、采购员、验收员每个角色的操作边界完全不同。营业员可以销售开单但是没有权限改库存台账验收员只能做采购入库的验收看不到销售毛利。所以你做这个系统首先在需求分析阶段就要把这几个业务域拆出来基础资料域、采购入库域、库存管理域、销售出库域、GSP质量管理域、统计报表域、系统管理域。这个拆法直接决定了你后面数据库怎么建、权限怎么设计、模块怎么划分。我的建议是开题之后先画一张业务流程图把“采购计划→采购订单→到货验收→入库上架→日常养护→销售开单→处方审核→出库扣减→库存预警→近效期报损→供应商结算”这条完整链路走一遍。你会发现这张图画完系统的功能清单基本就自动浮出来了根本不需要去抄别人系统的功能列表。2. 技术架构与工程落地单体SpringBoot就够别为微服务而微服务技术选型是答辩必问的一环。现在很多同学动不动上来就是SpringCloud微服务、Redis哨兵、RabbitMQ消息队列恨不得把一个毕业设计搞成高并发秒杀系统。这恰恰是老师最反感的点因为场景不匹配。一个单药房的进销存系统日单量撑死几百单并发压力极小核心诉求是逻辑严谨、数据一致、开发量可控。一套Spring Boot单体应用配上合理的分层完全够用而且更好维护。推荐结构是这样后端Spring Boot MyBatis-Plus MySQL 8.0权限框架用Spring Security或Sa-Token都行个人更推荐Sa-Token上手成本低一点毕业设计时间本来就紧。前端Vue 3 Element Plus ECharts管理后台的标配组合页面组件直接抄Element的布局改业务字段就行ECharts拿来做库存周转率、销售趋势、效期分布这类图表很出效果。环境开发调试用H2或本地MySQL都可以但交付文档里建议统一写MySQL毕竟演示环境也是MySQL省得切换踩坑。为什么坚持单体而不是微服务核心原因有两条。一是业务域之间的事务一致性要求高采购入库要同时写主表、明细表、批次库存表、GSP验收记录表四张表跨服务分布式事务的成本远大于收益。二是单体架构的代码量对一个毕业设计来说刚刚好大约两万行左右分微服务的话光服务间调用、配置中心、网关这些基础设施都要花掉大半时间反而挤占了核心业务逻辑的实现时间。工程结构上建议按业务域分包而不是按技术层分包。很多教程里习惯建controller/service/mapper三层目录但药品系统业务复杂我更推荐这样com.pharmacy ├── common // 统一返回、异常、工具类 ├── config // 配置类 ├── sys // 登录、用户、角色、菜单权限 ├── base // 药品档案、供应商档案、仓库档案 ├── purchase // 采购订单、采购入库、供应商结算 ├── inventory // 批次库存、移库、盘点、报损报溢、效期预警 ├── sale // 销售开单、处方单、退货单 ├── gsp // 温湿度记录、养护记录、验收记录 └── report // 报表统计、BI图表接口按业务域分包的好处是你写采购模块的时候目光只需要聚焦在purchase包里改动不影响别的模块。答辩的时候老师问“你这个系统的模块怎么组织的”你把包结构给他看比讲一百句“高内聚低耦合”都管用。技术栈这块如果想加分可以在项目里加一个小模块用Redis缓存药品分类树和供应商列表然后主动告诉老师这个数据读多写少我用Redis做了缓存解决频繁查库的问题。这就够了。不要在毕设里搞消息队列、分布式锁这些属于为自己挖坑。3. 数据库设计批号效期库存表是全系统的心脏数据库设计是整个系统成败的关键。我见过太多药品系统建一张drug表、一张stock表stock表里放一个quantity字段没了。这种设计一查批次效期就完全无能为力。药品经营系统里最核心的表设计一定是“药品档案”和“批次库存”分离。药品是静态的主数据批次库存是动态数据两者用drug_id关联多维度的业务信息挂在不同表上。药品档案表drug的核心字段建议这些drug_id、drug_name、规格、厂家、批准文号、剂型、分类处方药/OTC/特殊药品、存储条件常温/阴凉/冷藏、默认供应商、自定义编码、零售价、会员价、拆零标志是否允许拆零销售、状态启用/停用。注意药品的通用名和商品名是两回事数据库里最好都建字段展示的时候两个名字都显示因为药房盘点时工作人员更习惯用通用名检索。批次库存表我单独建一张stock_batch这是整个系统里逻辑最密集的表CREATE TABLE stock_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT, drug_id BIGINT NOT NULL COMMENT 药品ID, batch_no VARCHAR(64) NOT NULL COMMENT 厂家批号, supplier_id BIGINT COMMENT 供应商ID, production_date DATE COMMENT 生产日期, expire_date DATE NOT NULL COMMENT 有效期至, stock_qty INT NOT NULL DEFAULT 0 COMMENT 当前库存数量, frozen_qty INT NOT NULL DEFAULT 0 COMMENT 冻结数量, purchase_price DECIMAL(10,2) COMMENT 采购单价, sale_price DECIMAL(10,2) COMMENT 销售单价, shelf_location VARCHAR(32) COMMENT 货位号, gsp_status TINYINT COMMENT 验收状态, created_time DATETIME, updated_time DATETIME, KEY idx_drug_id (drug_id), KEY idx_expire_date (expire_date), KEY idx_batch_no (batch_no) );为什么单独搞一张批号表而不是直接在库存表里加字段因为同一款药今天入库一批789号效期2026年3月的下个月又入库一批123号效期2027年1月的它们两个批次的价格、位置、验收状态都不同如果合并成一条库存记录要么丢失批次信息要么数据都没法查。分开之后每批货都是独立生命周期这才符合药品GSP“按批可追溯”的基本逻辑。除了批号表药品经营管理系统里还有两张容易踩坑的表。第一张是库存流水表stock_flow所有入出库动作必须记流水。采购入库记正数流水销售出库记负数流水报损记负数流水的报损类型盘点差异记盘盈亏流水。每一条流水绑定batch_id和业务单据号这样任何时候出问题都能从当前库存一路追到最初的入库单形成闭环审计。第二张是采购入库单和验收记录采购订单审批之后到货时需要录入实收数量、批号、效期、生产日期并且单独生成一份验收记录不合格品要能进入拒收或退货流程。库存表上的效期预警是整个系统最有视觉冲击力的功能。一个库存批次表放在那里按有效期筛选出三个月内到期的批次配上彩色状态标记就是很好的答辩演示素材。这个后面我会专门展开讲。数据库设计这一层我还要强调一件事药品金额字段别用浮点数所有金额一律DECIMAL(10,2)计算用BigDecimal。浮点数算单价和小计到最后可能导致账面金额差几分钱药房财务对不上账会怀疑自己是不是少收钱了。这不是小概率问题是工程上反复出现的坑。4. 三大核心业务链路的实现采购入库、销售出库、效期预警4.1 采购入库链路验收和批号录入一个都不能少采购入库这块药房系统和普通进销存最大的不同在于多了一个“验收”概念。采购订单转收货单时系统要能按订单明细逐行录入实收数量并且对每一个实收数量大于0的行强制录入批号、生产日期、有效期。如果验收人员没有填批号系统必须不允许保存这是药品可追溯的基石。我在实际开发里入库的Service层是这样处理的Override Transactional(rollbackFor Exception.class) public PurchaseInResult createPurchaseIn(PurchaseInRequest request) { // 1. 幂等校验防止重复提交同样的采购入库单 if (purchaseInService.existsByOrderNo(request.getOrderNo())) { throw new BusinessException(该采购单已入库请勿重复操作); } // 2. 保存入库主单 PurchaseIn purchaseIn new PurchaseIn(); purchaseIn.setPurchaseOrderNo(request.getOrderNo()); ... // 主单字段拷贝 // 3. 逐行入库并生成批次库存 for (PurchaseInItem item : request.getItems()) { // 效期合法性校验 if (item.getExpireDate().isBefore(LocalDate.now())) { throw new BusinessException(批次 item.getBatchNo() 已过期不能入库); } // 生成新的批次库存 StockBatch batch new StockBatch(); batch.setDrugId(item.getDrugId()); batch.setBatchNo(item.getBatchNo()); batch.setExpireDate(item.getExpireDate()); batch.setStockQty(item.getQty()); batch.setPurchasePrice(item.getPrice()); stockBatchMapper.insert(batch); // 4. 写库存流水 stockFlowMapper.insert(StockFlow.buildFlow(batch.getId(), FlowType.IN, item.getQty(), 采购入库单号: request.getOrderNo())); } return new PurchaseInResult(purchaseIn.getId()); }注意我加了Transactional这很关键。入库操作涉及主单、明细、批次库存、流水四张表任何一步失败都要整体回滚否则就会出现“订单显示已入库但是库存没变”这种致命的不一致。4.2 销售出库链路FEFO效期优先出库与事务扣减销售出库是所有链路里业务逻辑最重的一环因为它不是一个简单的“库存减1”。顾客买两盒阿莫西林系统得去库存里找出效期最近的批次优先扣这个批次的库存同时还需要判断这个药品是不是处方药、如果是特殊管制药品还要校验单次购买量上限。扣减库存的核心逻辑先查有效批次按效期升序排列近效期先出public void deductStock(Long drugId, int qty) { ListStockBatch batches stockBatchMapper.selectValidBatchesByDrugId(drugId); int remaining qty; for (StockBatch batch : batches) { if (remaining 0) break; int available batch.getStockQty() - batch.getFrozenQty(); if (available 0) continue; int deductQty Math.min(available, remaining); batch.setFrozenQty(batch.getFrozenQty() deductQty); stockBatchMapper.updateById(batch); stockFlowMapper.insert(StockFlow.buildFlow(batch.getId(), FlowType.OUT_FROZEN, deductQty, 销售单号: saleNo)); remaining - deductQty; } if (remaining 0) { throw new BusinessException(库存不足当前可用库存为 (qty - remaining) 还差 remaining); } }这里我用了“先冻结后扣减”的两阶段方式。销售下单时先把批次库存冻结确认付款后再真正扣减冻结数。好处是如果顾客下单后没付款冻结库存还能释放不会出现“系统里显示没货其实顾客的订单还没支付”的问题。这个机制和电商的库存预占是同一个思路。4.3 效期预警让近效期药品无处藏身效期预警功能做得好系统拿出来整个演示效果都不一样。思路很简单跑一个定时任务每天扫描stock_batch表把每个批次的到期日期算一下距离当前还有多少天按照阈值分成几个等级public ListDrugDeadlineWarning getWarnings() { return stockBatchMapper.selectList( new LambdaQueryWrapperStockBatch() .lt(StockBatch::getExpireDate, LocalDate.now().plusDays(90)) .gt(StockBatch::getStockQty, 0) .orderByAsc(StockBatch::getExpireDate) ).stream().map(batch - { long days ChronoUnit.DAYS.between(LocalDate.now(), batch.getExpireDate()); WarningLevel level; if (days 0) level WarningLevel.EXPIRED; else if (days 30) level WarningLevel.URGENT; else if (days 90) level WarningLevel.WARNING; else level WarningLevel.NORMAL; ... }).collect(Collectors.toList()); }报表页面上用ECharts画一张“效期分布漏斗图”把已过期、30天内到期、30-90天到期、90天以上正常的批次数量按药品分类统计视觉冲击力非常强。再点进去能看到每一批药品的名字、厂家、批号、剩余数量、到期时间。这一屏内容配合一句解释——“系统每天自动扫描效期到期前90天开始预警店里就可以提前安排促销、退换或者报损”答辩老师立马知道你的系统是真正懂医药业务的。5. 药品合规与供应链协同这是把系统从“能跑”拉到“能用”的关键设计5.1 处方药管控与特殊药品限量不是所有药品都能直接卖处方药管控是药品经营系统的标志性需求。不做这个模块系统的业务完整度直接掉一个档次。实现思路是这样药品档案表里有药品分类字段分为处方药、OTC甲类、OTC乙类。销售开单时如果明细里包含处方药系统必须弹出处方登记表单处方编号、开具医院、开方医生、患者姓名、身份证号可选、诊断信息。处方单和销售单要关联保存形成电子处方记录支持后续按时间范围查询。特殊药品管制药品比如含麻黄碱类复方制剂在药品档案里有一个“限购数量”字段。销售时逐单校验如果单品销量超过限购直接拦截提示“该药品单次限购X盒请遵守相关规定”。同时记录购买人身份信息。这个功能虽然代码量不大但是非常体现系统对医药行业规则的理解答辩时主动提这个点老师会觉得你的需求分析很扎实。5.2 GSP质量管理温湿度记录、养护记录和验收记录GSP是药品经营质量管理规范的简称药房每天要做的温湿度记录就是这个模块的现实来源。我们可以做一个专门的GSP管理页面按仓库/药房维度配置温湿度监控点每天可以手动录入或者对接设备自动上报温湿度数据。页面展示一个记录列表按日期筛选并显示是否有超标记录超标时需要录入处理措施。这个模块做起来不难无非是增删改查加一个超标的判断逻辑但它独特性强普通商品管理系统里你是找不到这个功能的。答辩的时候你把这个模块展示一遍基本就能立住“我做的不是CRUD是行业应用的CRUD”这个印象。养护记录也是类似。每一批药品上架后按效期进行周期性养护检查检查合格在系统里记录一下“检查日期、检查结果、处理意见”。养护记录的列表能按批次反查形成批次的完整质量档案。5.3 供应商协同从采购计划到结算对账说到供应链协同标题里打了“医药供应链协同管理系统”这个点这一块值得深耕一下。供应商管理模块拥有的不只是简单的供应商信息CRUD而应该是一套资质管理机制。首次建档时录入供应商名称、营业执照注册号、药品经营许可证号、授权区域等上传资质图片。然后做一套“资质到期提醒”营业执照、经营许可证这类资质都有有效期系统按到期前30/7天生成预警列表超期未更新的供应商自动停用不能再发起采购。采购协同链路是这样的库存不足或库存低于安全库存时系统生成补货建议采购员对补货建议进行确认后生成采购订单订单提交审批审批通过后发给供应商打印/导出PDF到货后进行入库验收生成验收单验收完成形成供应商应付账款月末对账结算。这一整套流程做下来才称得上“供应链协同”而不是一张供应商列表加一个采购订单。代码层面采购计划这块很有意思可以做得聪明一点。有一个简单又实用的算法每个药品档案设置一个低库存补货阈值比如某种药库存低于50盒就触发补货建议。补货数量按近30天平均日销量乘以一个备货天数系数去估计例如日均销量8盒备货10天建议补货80盒同时减去当前库存和已订购未到货数量。这套逻辑虽然不复杂但展示出来很唬人因为它是“会思考的进销存”而不是傻记录数据的系统。public ListSuggestedOrderItem generateSuggestions() { return drugMapper.selectAll() .stream() .filter(drug - drug.getStockQty() drug.getReorderPoint()) .map(drug - { BigDecimal avgDaySales saleMapper.avgDaySales(drug.getDrugId(), 30); int suggestQty avgDaySales.multiply( new BigDecimal(drug.getDaysToReplenish()) ).intValue() - drug.getStockQty() - drug.getOnOrderQty(); return new SuggestedOrderItem(drug, suggestQty); }) .filter(item - item.getSuggestQty() 0) .collect(Collectors.toList()); }这一块代码一点不难但业务价值非常实。药房店主不用每天自己算该补多少药系统直接给建议量采购员只需要做确认和微调。6. 权限模型、数据审计和统计报表系统能不能“用”就看这三板斧6.1 按岗位划分的RBAC权限模型药房的岗位分工非常明确店长管全面业务和报表药师管处方审核和处方药销售店员管普通收银和销售采购员管采购和供应商验收员管验收和入库仓库管理员管库存和盘点。这套岗位模型天然适合RBAC权限设计。我推荐权限数据模型采用经典的五表设计用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。前端路由菜单从后端动态加载按钮级别的权限也用权限标识符控制比如purchase:order:approve只有店长角色有。A同学如果时间紧按钮级权限可以适当简化但菜单级权限一定要做因为药品系统的岗位隔离本身就是业务需求不是单纯的安全需求。Spring Security或者Sa-Token在Controller层用注解PreAuthorize(hasAuthority(sale:rx:audit))来控制处方审核接口只有药师角色能调这个就是核心的权限落点。6.2 操作留痕药房系统里“谁在什么时间做了什么”必须可查医药行业的审计要求高于普通零售。谁卖了一盒处方药给哪个顾客谁批准了这个采购订单谁做了这份报损单这些操作全都要留痕。实现方式很简单但很有效在核心业务表上记录create_by、create_time字段并且对敏感的审核、报损、盘点动作单独建操作日志表。还可以更进一步在重要单据上增加“审核链路”展示某采购单由谁创建、几月几日提交、谁审批的、审批意见是什么。这个设计在答辩时非常好讲因为它直接关联到“合规审计”这个行业核心关注点。另外建议用AOP做一个全局操作日志切面注解标注需要记录日志的方法自动记录操作人、操作方法、入参摘要、耗时、结果状态。别小看这个设计能让你的系统一下子从学生项目变成有工程气质的项目。6.3 报表与BI展示用数据把权限和业务都串起来最后一个出彩点就是报表。一个药品经营管理系统最少也要做这几张报表进销存汇总表按药品分类汇总期内期初库存、入库量、出库量、期末库存。销售日报/月报按日期/药品维度汇总销售额、销售数量、毛利下钻到具体单号。库存周转率报表某个周期内销售数量除以平均库存数字越高说明周转越快库存越健康。效期结构分析近效期药品占库存金额的比例资金占用分析。供应商采购汇总各供应商累计采购金额、退货率、到货及时率。报表一定要配图表。ECharts画柱状图、饼图、折线图放一个“经营看板”页面顶部是今日销售额、今日订单数、库存预警数量几张大卡片中间是近30天销售趋势折线图下面是各分类销售占比饼图和效期预警表格。这一页是整个系统最能让评委眼前一亮的地方一定要做得精致一点配合一个合理的假数据集演示效果直接拉满。要注意填充演示数据的时候让数据有“故事感”。比如3月销售数据比2月高是因为3月有一个感冒小高峰感冒类药品销量上扬效期预警里有一批健胃消食片临近效期可以在演示时顺便说一句“这批药如果月底前卖不掉系统会生成报损建议同时提醒采购员暂停采购同类药品。”这种带着业务逻辑的演示比干巴巴点页面有说服力得多。7. 毕业设计落地过程中的五个实操提醒做了这么多年的项目也带过不少毕设在这套系统上踩过的坑、见过的同学翻车现场挑五个最典型的提醒一下。第一不要忘了做数据字典。药品分类、剂型、存储条件、订单状态、审核状态这些字段谨慎直接写死枚举。建议建一张sys_dict表统一管理前端下拉框动态加载字典项。改一个状态名字不用动代码只需要改数据库这在答辩演示时调整字段很灵活而且是工程规范的一部分。第二假数据一定要真实。药品名称、厂家、批准文号尽量用真实存在的格式做模拟数据但不要用真实品牌名可以用“某厂家A”代替。批号用常见的日期加序号格式比如20251102B。如果假数据一看就是乱写的比如批号是123456有效期是2030年评委大概率会觉得你没认真调研行业数据。注意一下格式规范整套系统的观感会明显不一样。第三演示环境永远要准备一份干净的数据。答辩前重置数据库让所有统计数据从可靠的起点开始。演示过一次脏数据后那个页面截图会被反复问体验很差。在项目里放一个db/init_data.sql脚本一键初始化别用Navicat手动导做到可复现。第四别在答辩演示的时候现场敲代码。提前录好一段两分钟的核心功能演示视频万一现场环境出问题直接放视频救场。这个备用方案属于老经验了关键是关键时刻真的能救命。第五README和设计文档要跟上。系统架构图、数据ER图、接口文档、核心流程说明哪怕写得不完美也比没有强。评审老师看文档的速度远比看代码快一个结构清楚、字段设计合理的数据库说明文档胜过你代码注释再怎么写。最后想说的是药品经营管理系统这样的题目技术含量本身不高真正拉开差距的永远是你对行业的理解。批号效期、处方药管制、GSP留痕、供应商资质管理这些才是评委期待的“非通用系统”的标识。把这一层想透了代码量是一回事但整个系统的高度和说服力完全不同。做一个药房系统不难难的是让它像一个真正能拿去药店里用的系统——而这恰好是毕业设计里最值钱的部分。