1. 项目概览与需求背景药店管理系统这个题目我前后接触过不下三套类似的。无论是小规模单体药房还是连锁门店的初步信息化核心诉求其实出奇一致管住药、管住效期、管住销售和库存。很多初次上手开发这类系统的同学容易一上来就堆功能把系统做成了“带界面的Excel”而真正面对效期过期、批次混卖、库存不准、收银对不上账这些问题时系统反而帮不上忙。这个基于Spring Boot Vue的药店管理系统算是当前小型项目里比较典型且均衡的一套方案。后端走Spring Boot前端用VueSQL文件里的表结构基本覆盖了药店日常经营的几个关键场景药品信息、分类管理、供应商、采购入库、销售出库、库存调整、会员信息。再加上配套的文档无论你是拿来作为课程设计、毕业设计还是想快速搭一套给熟人药房用都具备可落地的基础。下面我按自己的复盘习惯把整套系统的设计思路、核心模块、实操过程和避坑经验拆开讲。我不打算逐行念代码而是把它当成一个真实项目来聊选型怎么权衡数据库怎么建前后端怎么配合部署踩过哪些坑以及拿到这套源码之后应该怎么动刀。适合读这篇内容的人大概是这几种情况第一你准备做Java web方向的项目需要一个完整度够高的练手目标第二你已经拿到源码但对着数据库和接口文档不知道该从哪里开始改第三你在运维或二次开发这套系统需要一份不藏着掖着的实战笔记。如果只是为了看皮相那这篇可能有点啰嗦但如果你真想把它跑起来、用起来、改成自己想要的形态下面这些内容值得你看到最后。2. 技术选型与整体架构设计2.1 为什么是Spring Boot Vue而不是传统单体JSP或纯模板渲染在拆系统之前先把选型逻辑说清楚。药店管理系统这类业务后端无外乎要做增删改查、权限控制、事务处理前端要做表单、列表、统计展示。Spring Boot出现之前常见的做法是Spring MVC JSP或者直接用模板引擎渲染页面。那种方式的问题在于前端和后端代码耦合在同一个工程里每改一次页面样式后端都要跟着重新编译打包。对于需要频繁调整交互的小团队来说开发节奏会被拖得很慢。用Spring Boot Vue做前后端分离好处是彻底的解耦。后端只负责提供RESTful接口返回JSON数据前端负责页面渲染和用户交互通过HTTP调用接口。两边可以并行开发前端开着Node的代理服务器联调后端只要把接口契约定好就行。对药店这种业务而言界面其实不需要极致的动效但数据准确性、响应速度、并发下单的稳定性更重要所以Spring Boot的轻量封装和Vue的组件化开发刚好匹配这类管理系统的需求。从实践角度讲这套组合对新手也是最友好的。Spring Boot简化了配置内嵌Tomcat打完包就是一个可运行的Jar包Vue全家桶有成熟的中文文档组件化写法比直接操作DOM容易维护。哪怕你之前只写过一点Servlet或者Python Flask也能较快上手。2.2 系统整体分层结构我习惯把系统的架构分成三层来看前端展示层、后端服务层、数据存储层。前端展示层是Vue单页应用负责页面路由、表单校验、状态展示。典型页面包括登录页、药品管理页、库存查询页、销售收银页、采购入库页、报表统计页。前端不直接操作数据库所有数据都通过后端接口获取。后端服务层是Spring Boot应用按标准的三层架构继续拆Controller层负责接收前端请求、参数封装和简单校验Service层处理业务逻辑比如销售扣减库存、入库增加库存、效期更新Mapper或Dao层负责与数据库交互。如果拿到的源码用了MyBatis那么业务代码会集中体现在Mapper XML文件里。数据存储层是MySQL核心表一般会拆成药品表、分类表、供应商表、采购表主从表、销售表主从表、库存表、会员表、用户表。这套表结构直接决定了系统能不能支撑真实经营场景。值得一提的是很多同学拿到项目后第一件事是看前端页面漂亮不漂亮这其实颠倒了优先级。对于管理系统数据模型才是灵魂。后面的章节我会倒过来先从数据库结构讲起再去看代码怎么写。2.3 为什么这份源码包含数据库和文档很重要有些开源项目只给代码不给数据库脚本或者给了脚本但没文档导致搭建成本很高。这套系统既然包含了数据库和文档那就意味着你不需要自己反推表结构直接执行SQL脚本就能把基础数据跑起来。在实际接手项目时建议先看文档里有没有数据库初始化说明再看SQL文件里包含哪些表。正常来说SQL文件会分两大部分建表语句和初始数据。初始数据尤其重要比如药品分类、单位类型、基础用户账号等。如果没有初始数据前端登录页会因为没有账号而无法进入这会卡死一大部分人。所以拿到源码后的第一步不是解压放IDE里而是先花十分钟通读文档找到数据库脚本建库建表确认用户名密码然后再启动项目。这一篇文章的建议顺序就是我踩过多次坑之后总结出来的最优顺序。3. 数据库设计与核心表结构拆解3.1 基础表用户与药品分类数据库设计是这类系统最容易闪断腰的地方。我见过不少教学项目把用户表做成t_user里面就放username和password连角色都不分导致权限控制无从谈起。药店系统的用户至少分两种角色管理员和收银员。管理员能管库存、采购、供应商、用户配置收银员可能只能开单收银。如果表里没有角色字段或者没有独立的角色表功能权限就只能靠前端页面隐藏来实现后端接口等于裸奔。合理的做法是至少有一张用户表加一个角色字段或者按RBAC模型拆成用户表、角色表、权限表。小型系统用前者即可字段可以设计为id、username、password、real_name、role、status、create_time。password加密存储至少用BCrypt而不是明文。药品分类表比较简单主要字段就是分类名称、上级分类、备注。虽然药店分类并不复杂但建议保留父级字段这样将来想做二级分类比如“感冒用药”→“风寒感冒”时不用改表结构。3.2 药品信息与库存表的设计要点药品表是整个系统的中枢。常见字段有药品编码、药品名称、通用名称、规格、生产厂家、批准文号、分类ID、单位、销售价格、采购价格、库存数量、预警下限、有效期、生产日期和批次号。这里面最容易被新手忽略的是批次和效期管理。真实的药店进销存里同一种药可能来自不同批次生产日期、有效期都不相同。如果把有效期直接挂在药品基础信息表上一旦来了一新批次老批次还没卖完就会出现数据覆盖。正确做法是把效期放到库存表或者独立的批次表里跟药品表分开。假设你有两张表药品表和批次库存表。药品表存商品固定属性比如名称、规格、厂家批次库存表存每一次入库的批次号、生产日期、有效期、入库数量、剩余数量。销售出库时按批次先进先出的原则扣减库存。这种设计初看增加了复杂度但真实药店场景里是必需品。如果项目SQL里没做批次表建议二次开发时优先补上。库存表则负责记录当前各药品的总库存量。不少简化项目会直接把当前数量放在药品表里这样增删改查方便但容易出现并发问题两个人同时下单后写的覆盖先写的。如果没有乐观锁或者事务处理库存数就漂移了。比较好的做法是用独立库存表存当前数量并配合乐观锁字段version更新时检查version是否被改过。3.3 采购与销售主从表设计采购和销售都属于“一单多品”的业务所以数据库需要设计主从表。以采购单为例主表t_purchase记录采购单号、供应商ID、采购日期、操作人、总金额、状态从表t_purchase_item记录该采购单下的每一种药品、采购数量、采购单价、批号、效期。这样设计的好处是查单头容易明细也完整而且不用在单头里塞一堆冗余字段。销售单同理t_sale_order存订单号、收银员、实收金额、支付方式、会员ID、销售时间t_sale_order_item存每种药品的销售数量、当时的销售价、成本价、批次号。拆开主从表之后日结统计就会很简单按销售订单表聚合金额按订单明细表聚合商品销量。如果不拆所有的商品列表都塞在一个字段里查询统计会很痛苦。3.4 初始化脚本里的外键与索引执行SQL脚本时要注意看建表语句里有没有外键约束。理论上外键可以保证数据一致性但高并发写入时外键会带来性能开销和维护成本。在这个体量下建议保留外键或不加都行关键是索引不能少。查询频繁的字段比如药品名称、药品编码、销售时间、商品分类都建议建索引。否则数据量到了5万条之后查询速度会肉眼可见地变慢。我建议拿到SQL文件后先整体看一遍把外键关系画出来再对照着前端页面理清哪个页面用到哪几张表。这个过程花不了半小时但对后续二次开发帮助极大。4. 后端核心业务实现与代码细节4.1 药品入库与库存增长的事务控制采购入库是药店系统最需要严谨对待的场景。用户提交一张采购单包含多个商品系统要做两件事一是写采购主表和明细表二是增加对应药品的库存数量。这两步必须在一个事务内完成要么都成功要么都失败。如果采购单写了库存没加上盘点时就会平白无故多出一堆纸面库存。Spring Boot里用Transactional就能解决但要小心事务失效的几种情况——比如同一个类内部方法调用或者方法不是public或者异常被catch掉了没往外抛。我自己在开发时习惯在入口Controller的方法上直接加Transactional并把Service层的事务注解也配上。虽然有点冗余但双保险能避免很多隐患。事务内尽量不要做耗时的外部调用比如发短信、调用第三方接口这些操作放到事务提交后再去做否则长时间占用数据库连接并发一大系统就挂。4.2 销售扣库存与并发防超卖销售模块的逻辑看起来简单前端传来商品ID和数量后端校验库存大于等于购买数生成订单扣减库存。但高并发场景下这段逻辑很容易出问题。假设库存只剩1盒两个收银员同时下单各买1盒代码都读到了库存为1然后都判断可以扣减最后都更新库存库存变成0或负数这就是典型的超卖。解决思路有两个一是在数据库层面加条件更新比如UPDATE stock SET quantity quantity - #{num} WHERE drug_id #{drugId} AND quantity #{num}这样数据库会锁行只有第一个更新成功第二个影响行数为0再校验影响行数就能判断是否库存不足。二是使用乐观锁在库存表加version字段更新时带上version更新成功则version加1。我推荐优先用条件更新最简单也最可靠。扣库存前不要先查库存再判断而是直接把扣减动作和判断条件写在一条SQL里性能和数据一致性都好。另外生成订单号和扣库存要放在同一个事务里这样即使订单写失败库存也不会被无辜扣掉。4.3 药品模糊搜索与多条件筛选药店的药品搜索是每次点到页面必用的功能。收银员通常直接扫码输入药品编码或者手打药名的一部分。后端接口应该设计成支持多条件组合查询药品名称模糊、药品编码精确、分类、厂家、是否下架。这里要注意模糊查询用LIKE %关键词%时如果关键词包含百分号或下划线需要转义不然会查出预期外的数据。在Spring Boot的Mapper层我习惯于用动态SQL标签配合条件判断。如果数据库量级不大单表LIKE查询完全够快。不要上来就说要接Elasticsearch那就是杀鸡用牛刀。真到数据量大了再考虑加搜索中间件也不迟。4.4 接口返回体统一与异常处理一个让开发体验明显提升的小细节是把接口返回格式统一掉。比如全局返回Result对象包含code、message、data三个字段。成功返回code200失败返回code500或业务码。前端拿到后统一判断code再决定是弹出错误提示还是正常渲染数据。要做到这一点后端需要配一个全局异常处理器把业务异常、参数校验异常、未知异常都转成统一的Result。如果项目源码里没做统一返回体强烈建议自己补上。别觉得这是形式主义真接前端的时候没有统一格式会让你无所适从有时候接口返回字符串有时候返回Map有时候直接返回null前端怎么判断我经历过一段没有统一返回结构的时期后端接口十几个返回格式五花八门前端每个请求都要单独处理异常情况改一个接口就牵连一片。后来花了一晚上统一后面的开发效率提升非常明显。5. Vue前端实现与前后端联调5.1 前端页面结构与路由组织Vue的前端页面一般用vue-router做路由。典型的页面划分如下登录页首页仪表盘统计卡片今日销售额、订单数、库存预警数量、会员数药品管理药品列表、新增药品、编辑药品、删除/下架库存管理库存列表、入库出库记录、效期预警采购管理采购单列表、创建采购单、审核销售管理收银台、订单列表、退换货供应商管理会员管理系统管理用户管理、角色权限这个划分基本就是一套药店管理系统的骨架。拿到源码后先对照路由表看看页面是否齐全再检查每个页面里到底调用了哪些接口。如果发现有前端页面没有对应的后端接口或者后端接口没有前端页面使用这部分很可能就是未完成的半成品。这也是很多网传项目源码的通病页面看起来全接口也全但前后端没有真正串联起来。5.2 状态管理与登录鉴权药店系统的状态管理不需要太重一般用Vuex或Pinia存一下用户信息、菜单权限、购物车数据就够了。登录后拿到token存到localStorage每次请求在axios拦截器里带上Authorization请求头。后端用拦截器统一验证token验证失败返回401前端收到401后跳回登录页。token推荐使用JWT格式后端生成时不往服务端存session天然适合前后端分离。但JWT过期是个问题如果有效时间太短用户操作到一半被踢下线太长又有安全风险。折中方案是有效时间去到6小时或者8小时企业内部小系统足够用。更高级的用双token刷新机制但那个对药店系统属于过度设计。登录鉴权这块很多新手容易踩的一个坑是后端接口没有做鉴权导致任何人只要知道接口地址就能绕过前端直接拉数据。比如你把销售明细数据接口暴露在/admin/sale/list下但没有写拦截器那这个系统就等同于裸奔。所以要确认后端是否在WebConfig里注册了登录拦截器并且给swagger或login接口加白名单。5.3 axios封装与跨域处理前后端分离必然遭遇跨域问题。开发阶段前端在Vue工程里配置vue.config.js的devServer代理把/api开头的请求代理到后端地址http://localhost:8080这样浏览器里看着是同源请求。后端也要配置CORS允许前端的来源地址。两边的配置缺一个都会导致接口报跨域错误。有些同学在后端配了CrossOrigin在网关或者Filter又配了一次结果重复跨域预检请求被挡。这种问题排查起来很烦建议统一用一个全局CorsFilter不要一处处加注解。线上部署时如果前端打包后的静态文件直接丢在Nginx里Nginx配置反向代理到后端服务同样能解决跨域问题而且更规范。5.4 前端常用组件与列表页优化药店管理系统的列表页非常多药品列表、供应商列表、订单列表几乎都是表格加搜索栏。用Element UI或Element Plus的话表格组件本身就很成熟而且支持分页。前端要注意两点一是分页参数要和后端约定好比如pageNum、pageSize、total不要一个接口用currentIndex另一个接口用page。二是表格加载时要有loading状态不然网络慢时用户看着空白列表以为系统卡死了。新增编辑表单建议做成对话框或者独立页面提交时要做前后端双重校验。比如药品销售价格不能为负数前端用规则校验一下后端Controller里再用注解校验。有人觉得前端校验就够了其实后端的校验才是最终防线因为接口可以被直接调用不能指望前端真的过滤所有脏数据。6. 项目部署实战与常见问题排查6.1 本地开发环境准备清单如果你要亲自把项目跑起来先在电脑上装好以下工具JDK 8或11具体看pom文件里的版本Maven 3.6及以上Node.js 14到16太新的Node版本编译老项目偶尔会报错MySQL 5.7或8.0IDE后端推荐用IDEA前端用VSCode或IDEA都行这里有一个老生常谈却必踩的坑JDK版本。很多网上的Spring Boot项目用的是2.x版本基于JDK 8编译。如果你电脑装了JDK 17直接开跑大概率会因为依赖不兼容报一堆错。先看pom.xml里的java.version字段把本机JDK切到对应版本。同时Maven的settings.xml要配好国内镜像不然下载依赖能等到天荒地老。6.2 数据库初始化与账号配置数据库初始化不要直接用root账号去跑建议专门建一个用户授权所有权限避免后面权限问题。执行SQL脚本的方法有两种一种是命令行source另一种是Navicat直接运行SQL文件。跑脚本前先检查有没有重复建库的语句如果有默认drop database再create database别在别人机器上误操作。脚本跑完后重点检查用户表里的初始密码是什么。如果文档没写到代码里找数据源配置文件比如application.yml里面通常会有初始数据的insert语句或者密码是固定的。有些项目密码经过MD5加密比如初始为e10adc3949ba59abbe56e057f20f883e这是123456的MD5值。你要知道初始账号能正常登录后续才能往下调。6.3 后端启动步骤与常见报错启动Spring Boot项目直接在IDEA里运行主类就行。常见报错和排查方向我列一下端口被占用改application.yml里的server.port或者命令查占用进程。数据库连接失败检查URL、用户名、密码确认MySQL服务已启动。时区报错在连接串后面加serverTimezoneAsia/Shanghai。Maven依赖下载不完整把本地仓库里对应目录删掉重新reimport。如果项目集成了Swagger启动后访问http://localhost:8080/swagger-ui.html能看接口文档这个对调试接口很有帮助。6.4 前端启动与代理配置文件前端工程启动前先npm install装依赖。如果node_modules已经存在但运行报错建议删掉node_modules和package-lock.json重新安装依赖版本冲突的问题基本都能解决。启动命令一般是npm run serve。打开页面后如果接口请求404先看代理配了没有。vue.config.js里通常会这样写module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }注意后端接口的context-path如果带了/api或者Controller的Mapping前缀带了/api代理层就别再给接口加上第二个/api否则会导致404。这个报错很隐蔽我第一次联调时排查了整整一天。7. 常见问题实录与避坑速查表7.1 药品库存对不上账的经典原因库存不准的根源十有八九出在流程断点上。比如销售退款时只退了钱没有把库存加回去或者采购入库时采购单审核通过加库存但采购单保存时也加了一次。做系统检查时先去代码里搜inventory相关的更新语句看每个操作是否都有对应的增减动作。另外一个经典问题是没有处理“赠送”或者“报损”场景。药店偶尔会有破损药、过期药需要报废如果系统里没有报损单只能通过做一笔负数采购单或者负数销售单来调节库存长此以往单据类型就会混乱。建议二次开发时至少加一个简单的“其它出入库”类型把非采购非销售导致的库存变动记录统一管理。7.2 效期预警模块的实现思路与缺口药品效期预警是药店系统的刚需。简单的实现是查询批次库存表里有效期距今剩余天数低于阈值的记录在后台首页做成列表展示。相对完整的方案是把预警分为两级比如剩余9个月提醒“临期”剩余3个月提醒“停售”。这需要在后端写个定时任务每天扫一次库存批次把临期药状态更新。很多网上项目的效期预警只是写了个静态页面根本没有定时任务。你拿到源码后要确认这一点。如果只是静态页面就需要自己补一个Job比如用Spring的Scheduled注解每天零点执行。7.3 报表统计中的时间处理坑日报、月报是药店管理者最常看的内容。统计今日销售金额很多人下意识用where date(create_time) curdate()这在数据量小的时候没问题但表大了之后这个查询没法走索引。更好的做法是把时间范围当条件传入比如where create_time 2024-01-01 00:00:00 and create_time 2024-01-02 00:00:00。还要注意统计口径退换货金额要不要冲减销售额会员折扣算不算在销售额里这些口径在代码里必须统一。前后端显示不一致会让用户直呼系统是坏的其实只是口径定义不明确。7.4 几个冷门但实用的排查技巧我用过最顺手的一招是看SQL日志。Spring Boot项目在application.yml里开启mybatis的SQL日志能看到每条接口执行的真实SQL。前端报错、数据不对的时候不要急着猜先看SQL执行了什么。很多时候问题一眼就能发现比如多表字段名写错了或者少了一个关联条件。另一个技巧是给前端页面加一个“接口调试模式”。在Vue的请求拦截器里如果传了debug参数就在console里打印完整请求和返回。平时没人看出了问题方便远程指导别人排查。8. 二次开发扩展建议与经验总结8.1 从“能用”到“好用”的四个改造方向如果你已经把这套系统跑通了想让它真正在日常经营里发挥价值我建议按这个顺序做二次开发。第一升级批次效期管理。前面说过补上批次表让入库的时候录入生产日期、有效期出库时自动按先进先出原则匹配批次。这一步做完近效期预警才能落脚到真实数据上。第二补全库存盘点功能。真实药店每个月都要盘点设计一张盘点表记录盘点时间、差异数量、盈亏原因并自动生成库存调整记录。这套功能很容易被教学项目忽略但实际运营必不可少。第三加入药品过期禁售拦截。后台药品如果有效期少于某个天数销售接口直接拒绝出库收银端弹窗提示。这是药店合规化经营的硬需求不做的话系统只能算是个记账工具。第四增加经营统计报表。不只是销售总金额最好有ABC分类分析、滞销药排行榜、毛利统计、供应商采购金额统计。有数据支撑店主才能做采购决策而不是凭感觉进货。8.2 前后端分离项目上线的标准姿势本地跑通只是第一步。真正上线我推荐用Nginx部署前端静态文件用jar包跑后端服务。前端构建时执行npm run build生成的dist目录传到服务器Nginx里配置root指向dist目录并把/api反向代理到后端服务的8080端口。HTTPS证书建议加上药店系统涉及用户信息和订单记录明文HTTP传输不可取。部署完成后一定要检查后端日志里的启动时间确认接口能通过域名访问。数据库密码不要用默认admin生产环境要改掉。所有初始账号的第一件事是立即修改密码这是我每次交付项目都会反复叮嘱的。8.3 我对这套系统最想说的几句心里话这类管理系统技术难度本身不算高难在业务逻辑的严谨。Spring Boot和Vue都只是工具真正的门槛在于你是否理解药店“先入库、再销售、库存实时变动、单据有据可查”的完整链路。如果只是把CRUD页面拼起来那系统注定撑不住真实营业场景。我当年第一次做进销存在“库存扣减”这个业务上反复改了三版第一版只扣总库存第二版混了批次第三版才把批次库存和总库存分开。每一次踩坑其实都是对业务理解加深一次的过程。所以如果你现在对着这套系统的某段代码看不懂别急着骂作者逻辑混乱很可能只是没经营者的视角。找个开药房的熟人聊一聊听听他们每天怎么盘货、怎么对账再回头看代码很多东西瞬间就通了。最后再分享一个小经验而且是我逢人必讲的一条给任何管理系统做二次开发改动业务逻辑之前先备份数据库。一次不好的表结构修改可能让整个系统报废。哪怕只是加一个字段也尽量把脚本写到变更记录里别直接去生产环境手改。项目可以迭代数据不能丢。这是我见过太多翻车现场之后最想让你记住的一句话。
