高校里的危化试剂管理这么多年一直是实验室安全最让人头疼的一块。台账靠手工填、库存靠人脑记、领用靠一张纸签字真要查出某个试剂放在哪个柜子、还剩多少、谁领走的经常要翻半天。我之前给某高校实验室做了一套危化试剂仓储管理系统前后端分离架构后端SpringBoot、前端Vue、持久层MyBatis、数据库MySQL。整套东西从设计到部署跑通前后花了三周多的时间中间踩了不少坑。这篇文章就把这套系统的完整设计思路、核心实现、部署过程全部拆开讲一遍包括我实际遇到过的问题和排查方法想自己搭一套的可以直接照着做。这个系统本身解决的是高校实验室里危化试剂的账实相符和全程可追溯问题——谁申购的、谁审批的、谁入库的、存放在哪个位置、谁领用的、什么时候用完的每一步都留痕。适合实验室管理员、安全员、负责实验室信息化的老师参考也适合正在做毕业设计或者课程项目的同学技术栈是Java后端和Vue前端最常见的那一套学完可以直接复用。1. 项目到底做了什么高校危化品仓储系统的需求盘点先别急着写代码把需求盘清楚比什么都重要。我做这套系统之前专门跟某高校的实验室安全负责人聊了一个下午也翻了他们现有的纸质单据发现痛点非常集中。1.1 高校危化品管理的真实痛点高校实验室和企业的危险品仓库不太一样管理对象更分散往往一个学校有几十个实验室每个实验室又分属不同的学院试剂种类杂、数量小、流动性大。我梳理下来主要有这么几类问题。台账混乱是第一个。每个实验室都有纸质的试剂台账本记录试剂名称、规格、数量、存放位置、领用人。但实际上很多记录都是当时记了后面再也不更新月底盘点对不上数的情况非常普遍。第二个是领用流程形同虚设学生找老师签个字就去柜子里拿试剂没有记录谁拿的、拿多少、什么时候拿的。第三个是审批缺失高危试剂和普通试剂的领用流程没有区分低浓度试剂和高危剧毒试剂都走同一个流程甚至不走流程。还有一个隐蔽的问题是存量统计困难。实验室负责人想知道整个学院这个季度用了多少易制毒试剂根本说不出来因为没有统一的系统在跑。而高校实验室每学期都要接受学校和上级部门的检查检查核心就是账、物、卡是否一致没有信息化工具做支撑全靠临时抱佛脚补台账工作量巨大。1.2 功能清单与角色设计需求梳理完系统的功能边界就很清晰了。我做这套系统时设计了三个核心角色系统管理员、库管员、普通用户教师/学生。系统管理员负责基础数据如用户管理、角色权限分配、试剂分类维护、存放位置管理。库管员是业务流程的核心负责试剂入库登记、出库复核、库存盘点和预警处理。普通用户可以直接在系统里发起领用申请、查看试剂库存还可以查看自己的领用记录。功能模块我拆成了六个登录认证与权限控制、试剂信息管理、入库管理、出库管理、库存看板与预警、统计报表。登录模块负责角色识别试剂信息管理维护每瓶试剂的档案信息入库和出库是整个系统的业务核心库存看板实时展示各仓位的库存数量和状态统计报表则是给管理层看的。这里有一个设计原则我特别想强调做这类管理系统不要一上来就想着做多复杂的功能先把入库—存储—出库—追踪这条主线跑通其他功能优先级都往后放。很多刚开始做这类项目的同学一上来就加了一堆报表、图表、消息通知结果核心的业务流程反而不完整。2. 技术选型为什么是SpringBootVueMyBatisMySQL技术选型这块我得说句实话这套组合在高校信息化项目里几乎是标准答案。不是因为它们是最前沿的技术而是因为它们最适合这类业务体量和开发节奏。2.1 后端选型——SpringBootMyBatisSpringBoot在这个项目里的核心价值是约定大于配置省掉了大量XML配置内嵌Tomcat一个Jar包就能跑起来这对部署环境不固定的高校项目来说非常友好。Team里的同学不用花费精力去折腾外部容器的配置项目启动就是执行一条java -jar命令的事。MyBatis作为持久层框架核心优势是SQL可控。仓储管理系统的查询场景非常灵活库存台账要根据试剂名称模糊查询、分类筛选、时间范围过滤组合操作有时候还要做多表关联统计。用MyBatis直接写SQL可以针对具体业务做精细优化比全自动ORM框架更直接。我在项目里大量使用了动态SQL比如查询库存时根据前端传来的条件自动拼装where子句这样的灵活性是其他框架给不了的。2.2 前端——VueElement UI前端选Vue的原因很实际组件化开发效率高生态成熟上手门槛低。配合Element UI组件库表格、表单、对话框、菜单这些后台管理系统的标配界面几乎都是现成的组件改改配置就能用。我在前端部分采用了Vue 2.6加上Element UI的组合。为什么不是Vue 3跟技术先进性没关系主要是Element UI对Vue 2的支持最成熟稳定网上资料也多遇到问题容易查到解决方案。如果是个全新项目用Vue 3加Element Plus也不是不行但对于这套系统来说稳定第一。说一下前后端交互方式统一使用RESTful API。后端只返回JSON数据前端通过Axios发起HTTP请求。接口设计遵循一个原则资源名用复数名词HTTP方法表达操作语义。比如GET /api/chemicals代表获取试剂列表POST /api/chemicals代表新增试剂DELETE /api/chemicals/{id}代表删除。这样的接口风格简单明了前后端联调的时候不容易产生理解偏差。2.3 前后端分离架构怎么拆分前后端分离的核心是关注点分离。后端专注业务逻辑、数据存储和安全性前端专注页面渲染、交互体验和数据展示。两边的开发可以并行推进只要提前约定好接口文档就行。实际开发中我用YApi管理接口文档先定义好每个接口的URL、请求参数、返回数据结构前端同学照着文档开发页面后端同学照着文档实现逻辑最后联调的时候问题就少很多。这种开发方式特别适合几个人一起协作的项目也可以帮助单人开发时理清思路。还有一点前后端分离以后部署时可以分开部署前端打包成静态文件交给Nginx托管后端打成Jar包独立运行。这样做的好处是前端的静态资源加载快后端服务可以独立维护和重启不会影响前端页面的访问。3. 数据库设计几张关键表撑起整个业务数据库设计是这类管理系统的地基表结构设计得合理后面写代码会非常顺畅设计得不好后面每个查询都要打补丁。我的做法是先画ER图明确实体关系再动手建表。这套系统核心就围绕几张表展开。3.1 用户与角色表设计用户表是系统的基础我设计了字段user_id、username、password、real_name、role_id、college、phone、created_at。其中password字段存的是BCrypt加密后的哈希值绝对不存明文密码这是底线。角色表字段很简单role_id、role_name、role_code。role_code分别对应ADMIN、KEEPER、USER三种角色。用户表通过role_id关联角色表登录后根据角色决定前端显示哪些菜单、后端接口是否放行。这里有一个设计的取舍为什么不用Spring Security加PreAuthorize做细粒度权限控制其实用是用了但做了一个简化。因为这套系统的角色只有三种权限模型非常清晰用拦截器加注解就足够了没有必要引入复杂的权限框架。权限设计要匹配业务复杂度不要为了架构而架构。3.2 化学品信息表化学品信息表保存所有试剂的静态档案信息不是实时库存可以理解为每一个试剂的基础信息卡片。核心字段包括chemical_id、cas_no、name、specification、category、danger_level、storage_conditions、supplier、expiry_date。cas_no是CAS编号是化学物质的唯一标识类似人的身份证号。这个字段在信息录入时建议强制校验格式因为后续查询、分类统计都依赖它一旦录错数据清洗会非常痛苦。danger_level用来标识试剂危险等级比如易燃、易爆、有毒、腐蚀性对应不同的存储和审批策略。3.3 库存表与出入库单据表库存表记录当前实际存储情况字段包括inventory_id、chemical_id、storage_location、quantity、unit、stock_warning_threshold、updated_at。一个chemical可以对应多个库存记录因为同一个试剂可能存放在不同的柜子或房间。库存数量只跟出入库单据联动任何对库存的修改都必须通过单据流转不允许直接改数量这是保证账实相符的关键设计。出入库单据表是整个系统的核心业务表字段包括doc_id、doc_type、chemical_id、quantity、operator_id、applicant_id、approver_id、status、create_time、approve_time、remark。doc_type区分入库单和出库单status区分待审批、已通过、已驳回。每一条单据都记录了发起人、审批人、操作时间形成完整的审计链路。审批记录单独建了一张表因为一条单据可能在审批环节被多次驳回重提每次审批的意见、时间都要留痕。字段包括approval_id、doc_id、approver_id、action、comment、approve_time。数据库表结构设计好之后我还做了一件事用Navicat的模型功能画了一张ER图给每个表标注了主外键关系打印出来贴在工位上。后面写代码的时候查表关系非常方便建议你也这样做。4. 后端核心模块实现细节后端是整个系统的大脑业务逻辑都在这里。我按照业务模块拆分了Controller、Service、Mapper三层Controller负责参数接收和结果返回Service负责业务逻辑Mapper负责数据库操作。下面挑几个核心模块详细讲。4.1 登录认证与权限控制登录接口接收用户名和密码校验通过后生成一个JWT令牌返回给前端。前端把令牌存在localStorage里之后每次请求都在请求头里携带Authorization字段。后端通过拦截器统一解析令牌解析成功就把用户信息放入ThreadLocal方便后续业务逻辑获取当前操作人。JWT工具类我用java-jwt这个库实现核心方法就是生成令牌和解析令牌两个。生成时把userId、username、roleCode放进去设置过期时间为24小时。解析时校验签名和过期时间校验失败直接返回401。接口权限控制用了Spring MVC的拦截器加自定义注解。我定义了一个RequireRole注解标注在需要特定角色才能访问的接口上拦截器里判断当前用户的角色是否满足要求不满足就返回403。比如入库单确认操作只有库管员才能执行就在对应的接口方法上标注RequireRole(KEEPER)。这里分享一个实际踩过的坑JWT令牌过期后前端拿过期令牌请求接口后端返回401但前端没有统一处理401的逻辑导致用户明明登录过期了页面还在正常显示点了按钮才发现报错。后来我在Axios的响应拦截器里统一判断HTTP状态码遇到401就清除localStorage并跳转登录页这个问题才算解决。4.2 入库管理的业务逻辑入库流程分两种新试剂首次入库和已有试剂的补充入库。新试剂入库需要先维护化学品信息表再创建入库单补充入库则直接创建入库单关联已有的chemical_id。入库单的创建接口接收一个JSON对象包含chemicalId、quantity、storageLocation、remark等字段。Service层的事务逻辑是这样的先插入入库单记录状态为已完成然后更新库存表。如果库存表中没有该试剂在该位置的记录就新增一条如果有就把数量累加。为什么入库不需要走审批因为入库的操作者是库管员库管员本身负责核实试剂信息和数量再走一层审批流程效率太低。我设计的规则是入库单由库管员直接确认生效出库单根据试剂危险等级决定是否审批。这个规则要跟用户确认清楚不同学校的管理制度不完全一样。事务处理上入库单插入和库存更新操作必须放在同一个事务里。我在Service方法上使用Transactional注解任何一个步骤失败都会整体回滚避免出现入库单已创建但库存没增加的脏数据。4.3 出库管理与审批流出库是整个系统里流程最复杂的环节。普通用户发起领用申请填写要领取的试剂、数量和用途说明。系统根据试剂的dangerLevel字段判断是否需要审批普通试剂由库管员直接确认出库高危试剂必须由安全负责人审批双人复核后才能出库。我用一张审批表记录了整个审批链路的每一步操作。创建出库单时状态为PENDING审批通过后状态变为APPROVED出库确认后状态变为COMPLETED驳回则变为REJECTED。高危试剂的出库逻辑上做了一个双人复核的设计。第一步申请提交后审批人通过此时库存还不会被扣减第二步由库管员在系统中执行出库确认操作扫码或录入出库数量系统才真正扣减库存并记录操作人。这样保证审批和实物出库是两个独立动作避免审批通过但实物没出库造成账实不符。再补充一个细节出库扣减库存时要做数量校验不能扣成负数。我在SQL层面用了条件更新UPDATE inventory SET quantity quantity - #{quantity} WHERE id #{inventoryId} AND quantity #{quantity}如果影响行数为0说明库存不足就抛出异常并回滚。这种写法可以避免并发情况下库存被超扣的风险。4.4 库存预警与统计报表库存预警是通过定时任务实现的。我用了Spring的Scheduled注解写了一个定时方法每天凌晨扫描库存表把当前数量低于预警阈值的记录筛选出来生成预警信息存入warning表同时给库管员发送站内通知。前端库存看板上有一个预警Tab显示所有低于阈值的试剂用红色标出。点进去可以看到预警时间、当前数量、阈值数量以及所在位置方便库管员快速定位。这里我特意做了一个已处理按钮库管员确认补货或调整阈值后标记处理状态否则预警会一直在列表里显示。统计报表模块主要是为管理层做决策用的。我写了几个聚合SQL包括按分类统计试剂库存金额占比、按领用数量排行Top10的试剂、按月统计出库数量趋势。这些数据展示在首页的大屏上管理层登录系统就能看到全院的危化品使用概况。写聚合统计SQL时有个心得如果数据量不大直接在业务SQL里用GROUP BY和子查询就够了不需要单独建汇总表。等数据量真的大了再考虑用定时任务把统计结果写入汇总表提升查询速度。过早优化是浪费时间的。5. 前端页面设计与接口对接前端这块我用Vue加Element UI搭了一个标准的后台管理界面。整体布局是左侧菜单栏、右侧内容区顶部是用户信息和退出按钮。不同的角色登录后显示不同的菜单。5.1 页面结构与核心视图整套系统一共七个主要页面登录页、首页看板、试剂档案列表、入库管理、出库管理、库存台账、审批中心。登录页是唯一不需要权限就能访问的页面其他页面都需要JWT令牌通过后才能加载。首页看板是整个系统的门面。我设计了一张库存总览卡片展示试剂种类总数、库存总量、预警数量、本月出入库次数四个指标。下面是一个出入库趋势的柱状图和一个分类占比的饼图图表用ECharts实现。试剂档案列表使用el-table组件展示数据支持按名称搜索、按分类筛选、按危险等级筛选。每行右侧有操作按钮查看详情、编辑、入库。详情弹窗里展示完整的化学品信息和库存列表。5.2 库存台账与出库表单库存台账页面展示的是实时库存数据表格列包括试剂名称、CAS号、存放位置、当前数量、单位、预警阈值、更新时间。低库存的记录会在表格行背景色上标红。表格下方是分页器每页十条数据。出库申请表单是我花心思最多的地方。表单包含四个字段选择试剂、申请数量、用途说明、紧急程度。选择试剂是一个下拉选择框选项数据来自库存接口只展示当前有库存的试剂。选择了试剂之后会自动显示该试剂当前库存数量和危险等级方便申请人判断是否够用。前端校验部分我用了Element UI的form rules试剂必选、数量必填且必须大于0、用途必填。这些前端校验能拦掉大部分无效请求但后端也做了同样的校验因为后端不能信任任何来自前端的数据。前后端双重校验是基本的安全意识。5.3 Axios接口对接与拦截器配置前端所有接口请求统一走Axios实例。我封装了一个request.js文件创建Axios实例时配置baseURL为后端接口地址然后在请求拦截器里从localStorage取出token塞进请求头在响应拦截器里统一处理HTTP异常。响应拦截器的逻辑大概是这样的如果返回的状态码是200直接返回data字段如果状态码是401清除本地token并跳转到登录页如果是403弹一条没有操作权限的消息提示其他状态码弹出后端返回的错误信息。接口对接时最容易出问题的就是字段命名不一致。后端Java习惯使用驼峰命名如storageLocation前端JavaScript也习惯驼峰命名这点是匹配的。但如果后端返回的JSON里使用了下划线命名前端要么用下划线要么在axios里做转换最稳妥的做法是提前约定前后端统一使用驼峰命名。6. 本地运行与部署教程部署这块我实际操作了两套环境本地开发环境通过IDEA加Vue CLI启动生产环境用云服务器加Nginx部署。下面把步骤写完整。6.1 环境准备与版本选择本地开发需要的软件清单JDK 1.8及以上、Maven 3.6、MySQL 5.7或8.0、Node.js 14以上、IDEA开发工具。版本上建议JDK直接装1.8因为SpringBoot 2.x系列对JDK 1.8的支持非常稳定。MySQL如果装8.0注意驱动依赖要对应。前端部分Vue CLI创建项目时选择Vue 2版本Node.js版本不要装太新16以上大版本问题不大npm安装依赖有时候会碰到node-sass编译失败的坑建议直接用sass的dart-sass版本替代。6.2 数据库初始化与配置我用Navicat创建了名为chemical_warehouse的数据库字符集选择utf8mb4排序规则utf8mb4_unicode_ci。然后把项目里的sql脚本导入脚本会创建所有表并插入初始数据包括默认的管理员账号。后端配置文件application.yml里需要修改三处数据库连接地址、数据库用户名、数据库密码。连接地址格式是jdbc:mysql://localhost:3306/chemical_warehouse?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。这里有个特别容易踩的坑MySQL 8.0以上的驱动需要显式设置serverTimezone否则连接会报时区异常必须在连接串里加上。6.3 后端启动用IDEA打开后端项目等待Maven下载依赖完成后修改application.yml配置。直接运行启动类的main方法控制台输出Started Application in xx seconds就代表启动成功默认端口是8080。如果本地8080端口被占用可以在application.yml里修改server.port配置。启动成功后用浏览器访问http://localhost:8080/api/health返回health: ok就表示后端服务已经正常跑起来了。6.4 前端启动前端项目用Vue CLI创建进入项目目录后先执行npm install安装依赖。如果网络环境不好可以配置npm镜像源执行npm config set registry https://registry.npm.taobao.org安装速度会快很多。依赖安装完成后在项目根目录下执行npm run serveVue CLI会启动开发服务器默认端口8080。但是后端也在8080所以前端开发服务器的端口会自动切换成8081开发时通过http://localhost:8081访问前端页面。开发环境需要配置前端代理解决跨域问题。在vue.config.js里配置devServer的proxyhttp://localhost:8080这样前端请求/api开头的接口都会自动转发到后端地址避免了跨域报错。6.5 生产环境部署要点生产环境我用的部署方案是一台Linux云服务器安装JDK和Nginx后端Jar包直接跑前端打包后的dist目录交给Nginx托管。后端打包执行mvn clean package -DskipTests在target目录下得到Jar包通过scp上传到服务器执行nohup java -jar chemical-warehouse.jar app.log 21 启动。这个命令的意思是把日志输出到app.log文件后台运行不占用终端。前端打包执行npm run build会在dist目录生成静态文件。把dist目录上传到服务器Nginx配置一个server块root指向dist目录location /api/则反代到127.0.0.1:8080后端服务。这个配置很关键否则前端页面能访问但接口请求会404。生产环境还有一个优化点同一个服务器上Nginx直接返回前端静态资源后端接口通过反向代理解析所有请求都走80端口不需要开放8080端口到外网安全性更好。我用ufw防火墙只放行22和80端口数据库3306端口根本不对公网开放最大程度减少攻击面。7. 踩坑实录与常见问题排查做这套系统的过程中踩过的坑不少记录几个典型的给后面做类似项目的朋友提个醒。排查思路比最终答案更重要理解了排查过程遇到类似问题才不会慌。7.1 数据库连接与编码问题最常见的坑是MySQL 8.0连接报Public Key Retrieval is not allowed错误这个是因为MySQL 8.0默认使用caching_sha2_password认证方式JDBC连接时需要配置allowPublicKeyRetrievaltrue来解决。还有中文乱码问题。有时候数据库表和数据文件都是utf8但连接串没带characterEncodingutf8参数导致中文写入数据库后是问号。解决办法很简单连接串加上utf8参数同时确保数据库表级别和字段级别的字符集都是utf8mb4。7.2 前后端联调跨域问题开发环境下前端8081端口请求后端8080端口浏览器会拦截跨域请求。解决方式就是我前面说的在vue.config.js里配置proxy代理。但有一个细节代理配置修改后必须重启npm run serve不是刷新页面就行否则新配置不生效。生产环境部署时Nginx反代配置不对的话也会出现类似问题。排查方法是打开浏览器开发者工具的Network面板看接口请求的返回状态码。如果是404通常是Nginx配置的location路径有问题如果是502通常是后端Jar包没启动或者端口不对。7.3 JWT登录状态失效问题JWT令牌过期后用户没感知点击操作时请求返回401。这个问题我在前面讲过解决方案是在Axios响应拦截器里统一处理401跳转。还有一个相关坑用户登录成功后刷新页面Vuex里存的用户信息清空了但localStorage里的token还在页面刷新后显示未登录。解决思路是刷新页面后在App.vue的created钩子里根据token调用一次获取用户信息的接口把用户信息重新加载进Vuex。这个方案叫做静默登录恢复体验比强制重新登录好很多。7.4 定时任务与线程安全问题库存预警的定时任务一开始我用的是简单线程ScheduledExecutorService部署后发现如果在多实例环境下跑每个实例都会执行一次预警扫描产生重复预警。后来改用Spring的Scheduled注解配合一个分布式锁基于数据库唯一约束实现解决多实例重复执行问题。库存扣减的并发问题我在前面提到用条件更新来避免超扣这里再补充一点即使条件更新保证了单个库存记录不超扣但如果有两笔出库同时操作同一库存后执行的那笔会因为影响行数为0而失败。这个失败是正常的我应该把这个失败转成明确的业务异常提示而不是让前端收到一个泛泛的数据库错误。7.5 日常使用的业务坑最后说一个非技术问题系统上线后库管员反映录入试剂信息太慢每瓶试剂都要填十几个字段。后来我给前端加了一个复制新增功能可以在已有试剂的基础上复制一份再修改局部信息录入效率提升了很多。这个需求不在最初设计里是用户真正用起来之后才提的。做这类管理系统一定要预留迭代的空间第一版不可能完美用户反馈才是最真实的需求来源。整套系统跑下来我的体会是这类仓储管理系统的技术难度其实不高真正的难点在业务流程的梳理和细节的打磨。出入库流程、审批链路、权限控制、数据一致性每一块都需要站在用户的角度想清楚。技术永远是解决业务问题的手段而不是目的。如果这篇文章能帮你少踩几个坑那这套系统的经验就没白分享。 
长河君 · 2026/10/15 19:03:27 · 阅读 1.2k 高校危化试剂仓储系统实战：SpringBoot+Vue前后端分离设计全解析
高校里的危化试剂管理这么多年一直是实验室安全最让人头疼的一块。台账靠手工填、库存靠人脑记、领用靠一张纸签字真要查出某个试剂放在哪个柜子、还剩多少、谁领走的经常要翻半天。我之前给某高校实验室做了一套危化试剂仓储管理系统前后端分离架构后端SpringBoot、前端Vue、持久层MyBatis、数据库MySQL。整套东西从设计到部署跑通前后花了三周多的时间中间踩了不少坑。这篇文章就把这套系统的完整设计思路、核心实现、部署过程全部拆开讲一遍包括我实际遇到过的问题和排查方法想自己搭一套的可以直接照着做。这个系统本身解决的是高校实验室里危化试剂的账实相符和全程可追溯问题——谁申购的、谁审批的、谁入库的、存放在哪个位置、谁领用的、什么时候用完的每一步都留痕。适合实验室管理员、安全员、负责实验室信息化的老师参考也适合正在做毕业设计或者课程项目的同学技术栈是Java后端和Vue前端最常见的那一套学完可以直接复用。1. 项目到底做了什么高校危化品仓储系统的需求盘点先别急着写代码把需求盘清楚比什么都重要。我做这套系统之前专门跟某高校的实验室安全负责人聊了一个下午也翻了他们现有的纸质单据发现痛点非常集中。1.1 高校危化品管理的真实痛点高校实验室和企业的危险品仓库不太一样管理对象更分散往往一个学校有几十个实验室每个实验室又分属不同的学院试剂种类杂、数量小、流动性大。我梳理下来主要有这么几类问题。台账混乱是第一个。每个实验室都有纸质的试剂台账本记录试剂名称、规格、数量、存放位置、领用人。但实际上很多记录都是当时记了后面再也不更新月底盘点对不上数的情况非常普遍。第二个是领用流程形同虚设学生找老师签个字就去柜子里拿试剂没有记录谁拿的、拿多少、什么时候拿的。第三个是审批缺失高危试剂和普通试剂的领用流程没有区分低浓度试剂和高危剧毒试剂都走同一个流程甚至不走流程。还有一个隐蔽的问题是存量统计困难。实验室负责人想知道整个学院这个季度用了多少易制毒试剂根本说不出来因为没有统一的系统在跑。而高校实验室每学期都要接受学校和上级部门的检查检查核心就是账、物、卡是否一致没有信息化工具做支撑全靠临时抱佛脚补台账工作量巨大。1.2 功能清单与角色设计需求梳理完系统的功能边界就很清晰了。我做这套系统时设计了三个核心角色系统管理员、库管员、普通用户教师/学生。系统管理员负责基础数据如用户管理、角色权限分配、试剂分类维护、存放位置管理。库管员是业务流程的核心负责试剂入库登记、出库复核、库存盘点和预警处理。普通用户可以直接在系统里发起领用申请、查看试剂库存还可以查看自己的领用记录。功能模块我拆成了六个登录认证与权限控制、试剂信息管理、入库管理、出库管理、库存看板与预警、统计报表。登录模块负责角色识别试剂信息管理维护每瓶试剂的档案信息入库和出库是整个系统的业务核心库存看板实时展示各仓位的库存数量和状态统计报表则是给管理层看的。这里有一个设计原则我特别想强调做这类管理系统不要一上来就想着做多复杂的功能先把入库—存储—出库—追踪这条主线跑通其他功能优先级都往后放。很多刚开始做这类项目的同学一上来就加了一堆报表、图表、消息通知结果核心的业务流程反而不完整。2. 技术选型为什么是SpringBootVueMyBatisMySQL技术选型这块我得说句实话这套组合在高校信息化项目里几乎是标准答案。不是因为它们是最前沿的技术而是因为它们最适合这类业务体量和开发节奏。2.1 后端选型——SpringBootMyBatisSpringBoot在这个项目里的核心价值是约定大于配置省掉了大量XML配置内嵌Tomcat一个Jar包就能跑起来这对部署环境不固定的高校项目来说非常友好。Team里的同学不用花费精力去折腾外部容器的配置项目启动就是执行一条java -jar命令的事。MyBatis作为持久层框架核心优势是SQL可控。仓储管理系统的查询场景非常灵活库存台账要根据试剂名称模糊查询、分类筛选、时间范围过滤组合操作有时候还要做多表关联统计。用MyBatis直接写SQL可以针对具体业务做精细优化比全自动ORM框架更直接。我在项目里大量使用了动态SQL比如查询库存时根据前端传来的条件自动拼装where子句这样的灵活性是其他框架给不了的。2.2 前端——VueElement UI前端选Vue的原因很实际组件化开发效率高生态成熟上手门槛低。配合Element UI组件库表格、表单、对话框、菜单这些后台管理系统的标配界面几乎都是现成的组件改改配置就能用。我在前端部分采用了Vue 2.6加上Element UI的组合。为什么不是Vue 3跟技术先进性没关系主要是Element UI对Vue 2的支持最成熟稳定网上资料也多遇到问题容易查到解决方案。如果是个全新项目用Vue 3加Element Plus也不是不行但对于这套系统来说稳定第一。说一下前后端交互方式统一使用RESTful API。后端只返回JSON数据前端通过Axios发起HTTP请求。接口设计遵循一个原则资源名用复数名词HTTP方法表达操作语义。比如GET /api/chemicals代表获取试剂列表POST /api/chemicals代表新增试剂DELETE /api/chemicals/{id}代表删除。这样的接口风格简单明了前后端联调的时候不容易产生理解偏差。2.3 前后端分离架构怎么拆分前后端分离的核心是关注点分离。后端专注业务逻辑、数据存储和安全性前端专注页面渲染、交互体验和数据展示。两边的开发可以并行推进只要提前约定好接口文档就行。实际开发中我用YApi管理接口文档先定义好每个接口的URL、请求参数、返回数据结构前端同学照着文档开发页面后端同学照着文档实现逻辑最后联调的时候问题就少很多。这种开发方式特别适合几个人一起协作的项目也可以帮助单人开发时理清思路。还有一点前后端分离以后部署时可以分开部署前端打包成静态文件交给Nginx托管后端打成Jar包独立运行。这样做的好处是前端的静态资源加载快后端服务可以独立维护和重启不会影响前端页面的访问。3. 数据库设计几张关键表撑起整个业务数据库设计是这类管理系统的地基表结构设计得合理后面写代码会非常顺畅设计得不好后面每个查询都要打补丁。我的做法是先画ER图明确实体关系再动手建表。这套系统核心就围绕几张表展开。3.1 用户与角色表设计用户表是系统的基础我设计了字段user_id、username、password、real_name、role_id、college、phone、created_at。其中password字段存的是BCrypt加密后的哈希值绝对不存明文密码这是底线。角色表字段很简单role_id、role_name、role_code。role_code分别对应ADMIN、KEEPER、USER三种角色。用户表通过role_id关联角色表登录后根据角色决定前端显示哪些菜单、后端接口是否放行。这里有一个设计的取舍为什么不用Spring Security加PreAuthorize做细粒度权限控制其实用是用了但做了一个简化。因为这套系统的角色只有三种权限模型非常清晰用拦截器加注解就足够了没有必要引入复杂的权限框架。权限设计要匹配业务复杂度不要为了架构而架构。3.2 化学品信息表化学品信息表保存所有试剂的静态档案信息不是实时库存可以理解为每一个试剂的基础信息卡片。核心字段包括chemical_id、cas_no、name、specification、category、danger_level、storage_conditions、supplier、expiry_date。cas_no是CAS编号是化学物质的唯一标识类似人的身份证号。这个字段在信息录入时建议强制校验格式因为后续查询、分类统计都依赖它一旦录错数据清洗会非常痛苦。danger_level用来标识试剂危险等级比如易燃、易爆、有毒、腐蚀性对应不同的存储和审批策略。3.3 库存表与出入库单据表库存表记录当前实际存储情况字段包括inventory_id、chemical_id、storage_location、quantity、unit、stock_warning_threshold、updated_at。一个chemical可以对应多个库存记录因为同一个试剂可能存放在不同的柜子或房间。库存数量只跟出入库单据联动任何对库存的修改都必须通过单据流转不允许直接改数量这是保证账实相符的关键设计。出入库单据表是整个系统的核心业务表字段包括doc_id、doc_type、chemical_id、quantity、operator_id、applicant_id、approver_id、status、create_time、approve_time、remark。doc_type区分入库单和出库单status区分待审批、已通过、已驳回。每一条单据都记录了发起人、审批人、操作时间形成完整的审计链路。审批记录单独建了一张表因为一条单据可能在审批环节被多次驳回重提每次审批的意见、时间都要留痕。字段包括approval_id、doc_id、approver_id、action、comment、approve_time。数据库表结构设计好之后我还做了一件事用Navicat的模型功能画了一张ER图给每个表标注了主外键关系打印出来贴在工位上。后面写代码的时候查表关系非常方便建议你也这样做。4. 后端核心模块实现细节后端是整个系统的大脑业务逻辑都在这里。我按照业务模块拆分了Controller、Service、Mapper三层Controller负责参数接收和结果返回Service负责业务逻辑Mapper负责数据库操作。下面挑几个核心模块详细讲。4.1 登录认证与权限控制登录接口接收用户名和密码校验通过后生成一个JWT令牌返回给前端。前端把令牌存在localStorage里之后每次请求都在请求头里携带Authorization字段。后端通过拦截器统一解析令牌解析成功就把用户信息放入ThreadLocal方便后续业务逻辑获取当前操作人。JWT工具类我用java-jwt这个库实现核心方法就是生成令牌和解析令牌两个。生成时把userId、username、roleCode放进去设置过期时间为24小时。解析时校验签名和过期时间校验失败直接返回401。接口权限控制用了Spring MVC的拦截器加自定义注解。我定义了一个RequireRole注解标注在需要特定角色才能访问的接口上拦截器里判断当前用户的角色是否满足要求不满足就返回403。比如入库单确认操作只有库管员才能执行就在对应的接口方法上标注RequireRole(KEEPER)。这里分享一个实际踩过的坑JWT令牌过期后前端拿过期令牌请求接口后端返回401但前端没有统一处理401的逻辑导致用户明明登录过期了页面还在正常显示点了按钮才发现报错。后来我在Axios的响应拦截器里统一判断HTTP状态码遇到401就清除localStorage并跳转登录页这个问题才算解决。4.2 入库管理的业务逻辑入库流程分两种新试剂首次入库和已有试剂的补充入库。新试剂入库需要先维护化学品信息表再创建入库单补充入库则直接创建入库单关联已有的chemical_id。入库单的创建接口接收一个JSON对象包含chemicalId、quantity、storageLocation、remark等字段。Service层的事务逻辑是这样的先插入入库单记录状态为已完成然后更新库存表。如果库存表中没有该试剂在该位置的记录就新增一条如果有就把数量累加。为什么入库不需要走审批因为入库的操作者是库管员库管员本身负责核实试剂信息和数量再走一层审批流程效率太低。我设计的规则是入库单由库管员直接确认生效出库单根据试剂危险等级决定是否审批。这个规则要跟用户确认清楚不同学校的管理制度不完全一样。事务处理上入库单插入和库存更新操作必须放在同一个事务里。我在Service方法上使用Transactional注解任何一个步骤失败都会整体回滚避免出现入库单已创建但库存没增加的脏数据。4.3 出库管理与审批流出库是整个系统里流程最复杂的环节。普通用户发起领用申请填写要领取的试剂、数量和用途说明。系统根据试剂的dangerLevel字段判断是否需要审批普通试剂由库管员直接确认出库高危试剂必须由安全负责人审批双人复核后才能出库。我用一张审批表记录了整个审批链路的每一步操作。创建出库单时状态为PENDING审批通过后状态变为APPROVED出库确认后状态变为COMPLETED驳回则变为REJECTED。高危试剂的出库逻辑上做了一个双人复核的设计。第一步申请提交后审批人通过此时库存还不会被扣减第二步由库管员在系统中执行出库确认操作扫码或录入出库数量系统才真正扣减库存并记录操作人。这样保证审批和实物出库是两个独立动作避免审批通过但实物没出库造成账实不符。再补充一个细节出库扣减库存时要做数量校验不能扣成负数。我在SQL层面用了条件更新UPDATE inventory SET quantity quantity - #{quantity} WHERE id #{inventoryId} AND quantity #{quantity}如果影响行数为0说明库存不足就抛出异常并回滚。这种写法可以避免并发情况下库存被超扣的风险。4.4 库存预警与统计报表库存预警是通过定时任务实现的。我用了Spring的Scheduled注解写了一个定时方法每天凌晨扫描库存表把当前数量低于预警阈值的记录筛选出来生成预警信息存入warning表同时给库管员发送站内通知。前端库存看板上有一个预警Tab显示所有低于阈值的试剂用红色标出。点进去可以看到预警时间、当前数量、阈值数量以及所在位置方便库管员快速定位。这里我特意做了一个已处理按钮库管员确认补货或调整阈值后标记处理状态否则预警会一直在列表里显示。统计报表模块主要是为管理层做决策用的。我写了几个聚合SQL包括按分类统计试剂库存金额占比、按领用数量排行Top10的试剂、按月统计出库数量趋势。这些数据展示在首页的大屏上管理层登录系统就能看到全院的危化品使用概况。写聚合统计SQL时有个心得如果数据量不大直接在业务SQL里用GROUP BY和子查询就够了不需要单独建汇总表。等数据量真的大了再考虑用定时任务把统计结果写入汇总表提升查询速度。过早优化是浪费时间的。5. 前端页面设计与接口对接前端这块我用Vue加Element UI搭了一个标准的后台管理界面。整体布局是左侧菜单栏、右侧内容区顶部是用户信息和退出按钮。不同的角色登录后显示不同的菜单。5.1 页面结构与核心视图整套系统一共七个主要页面登录页、首页看板、试剂档案列表、入库管理、出库管理、库存台账、审批中心。登录页是唯一不需要权限就能访问的页面其他页面都需要JWT令牌通过后才能加载。首页看板是整个系统的门面。我设计了一张库存总览卡片展示试剂种类总数、库存总量、预警数量、本月出入库次数四个指标。下面是一个出入库趋势的柱状图和一个分类占比的饼图图表用ECharts实现。试剂档案列表使用el-table组件展示数据支持按名称搜索、按分类筛选、按危险等级筛选。每行右侧有操作按钮查看详情、编辑、入库。详情弹窗里展示完整的化学品信息和库存列表。5.2 库存台账与出库表单库存台账页面展示的是实时库存数据表格列包括试剂名称、CAS号、存放位置、当前数量、单位、预警阈值、更新时间。低库存的记录会在表格行背景色上标红。表格下方是分页器每页十条数据。出库申请表单是我花心思最多的地方。表单包含四个字段选择试剂、申请数量、用途说明、紧急程度。选择试剂是一个下拉选择框选项数据来自库存接口只展示当前有库存的试剂。选择了试剂之后会自动显示该试剂当前库存数量和危险等级方便申请人判断是否够用。前端校验部分我用了Element UI的form rules试剂必选、数量必填且必须大于0、用途必填。这些前端校验能拦掉大部分无效请求但后端也做了同样的校验因为后端不能信任任何来自前端的数据。前后端双重校验是基本的安全意识。5.3 Axios接口对接与拦截器配置前端所有接口请求统一走Axios实例。我封装了一个request.js文件创建Axios实例时配置baseURL为后端接口地址然后在请求拦截器里从localStorage取出token塞进请求头在响应拦截器里统一处理HTTP异常。响应拦截器的逻辑大概是这样的如果返回的状态码是200直接返回data字段如果状态码是401清除本地token并跳转到登录页如果是403弹一条没有操作权限的消息提示其他状态码弹出后端返回的错误信息。接口对接时最容易出问题的就是字段命名不一致。后端Java习惯使用驼峰命名如storageLocation前端JavaScript也习惯驼峰命名这点是匹配的。但如果后端返回的JSON里使用了下划线命名前端要么用下划线要么在axios里做转换最稳妥的做法是提前约定前后端统一使用驼峰命名。6. 本地运行与部署教程部署这块我实际操作了两套环境本地开发环境通过IDEA加Vue CLI启动生产环境用云服务器加Nginx部署。下面把步骤写完整。6.1 环境准备与版本选择本地开发需要的软件清单JDK 1.8及以上、Maven 3.6、MySQL 5.7或8.0、Node.js 14以上、IDEA开发工具。版本上建议JDK直接装1.8因为SpringBoot 2.x系列对JDK 1.8的支持非常稳定。MySQL如果装8.0注意驱动依赖要对应。前端部分Vue CLI创建项目时选择Vue 2版本Node.js版本不要装太新16以上大版本问题不大npm安装依赖有时候会碰到node-sass编译失败的坑建议直接用sass的dart-sass版本替代。6.2 数据库初始化与配置我用Navicat创建了名为chemical_warehouse的数据库字符集选择utf8mb4排序规则utf8mb4_unicode_ci。然后把项目里的sql脚本导入脚本会创建所有表并插入初始数据包括默认的管理员账号。后端配置文件application.yml里需要修改三处数据库连接地址、数据库用户名、数据库密码。连接地址格式是jdbc:mysql://localhost:3306/chemical_warehouse?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai。这里有个特别容易踩的坑MySQL 8.0以上的驱动需要显式设置serverTimezone否则连接会报时区异常必须在连接串里加上。6.3 后端启动用IDEA打开后端项目等待Maven下载依赖完成后修改application.yml配置。直接运行启动类的main方法控制台输出Started Application in xx seconds就代表启动成功默认端口是8080。如果本地8080端口被占用可以在application.yml里修改server.port配置。启动成功后用浏览器访问http://localhost:8080/api/health返回health: ok就表示后端服务已经正常跑起来了。6.4 前端启动前端项目用Vue CLI创建进入项目目录后先执行npm install安装依赖。如果网络环境不好可以配置npm镜像源执行npm config set registry https://registry.npm.taobao.org安装速度会快很多。依赖安装完成后在项目根目录下执行npm run serveVue CLI会启动开发服务器默认端口8080。但是后端也在8080所以前端开发服务器的端口会自动切换成8081开发时通过http://localhost:8081访问前端页面。开发环境需要配置前端代理解决跨域问题。在vue.config.js里配置devServer的proxyhttp://localhost:8080这样前端请求/api开头的接口都会自动转发到后端地址避免了跨域报错。6.5 生产环境部署要点生产环境我用的部署方案是一台Linux云服务器安装JDK和Nginx后端Jar包直接跑前端打包后的dist目录交给Nginx托管。后端打包执行mvn clean package -DskipTests在target目录下得到Jar包通过scp上传到服务器执行nohup java -jar chemical-warehouse.jar app.log 21 启动。这个命令的意思是把日志输出到app.log文件后台运行不占用终端。前端打包执行npm run build会在dist目录生成静态文件。把dist目录上传到服务器Nginx配置一个server块root指向dist目录location /api/则反代到127.0.0.1:8080后端服务。这个配置很关键否则前端页面能访问但接口请求会404。生产环境还有一个优化点同一个服务器上Nginx直接返回前端静态资源后端接口通过反向代理解析所有请求都走80端口不需要开放8080端口到外网安全性更好。我用ufw防火墙只放行22和80端口数据库3306端口根本不对公网开放最大程度减少攻击面。7. 踩坑实录与常见问题排查做这套系统的过程中踩过的坑不少记录几个典型的给后面做类似项目的朋友提个醒。排查思路比最终答案更重要理解了排查过程遇到类似问题才不会慌。7.1 数据库连接与编码问题最常见的坑是MySQL 8.0连接报Public Key Retrieval is not allowed错误这个是因为MySQL 8.0默认使用caching_sha2_password认证方式JDBC连接时需要配置allowPublicKeyRetrievaltrue来解决。还有中文乱码问题。有时候数据库表和数据文件都是utf8但连接串没带characterEncodingutf8参数导致中文写入数据库后是问号。解决办法很简单连接串加上utf8参数同时确保数据库表级别和字段级别的字符集都是utf8mb4。7.2 前后端联调跨域问题开发环境下前端8081端口请求后端8080端口浏览器会拦截跨域请求。解决方式就是我前面说的在vue.config.js里配置proxy代理。但有一个细节代理配置修改后必须重启npm run serve不是刷新页面就行否则新配置不生效。生产环境部署时Nginx反代配置不对的话也会出现类似问题。排查方法是打开浏览器开发者工具的Network面板看接口请求的返回状态码。如果是404通常是Nginx配置的location路径有问题如果是502通常是后端Jar包没启动或者端口不对。7.3 JWT登录状态失效问题JWT令牌过期后用户没感知点击操作时请求返回401。这个问题我在前面讲过解决方案是在Axios响应拦截器里统一处理401跳转。还有一个相关坑用户登录成功后刷新页面Vuex里存的用户信息清空了但localStorage里的token还在页面刷新后显示未登录。解决思路是刷新页面后在App.vue的created钩子里根据token调用一次获取用户信息的接口把用户信息重新加载进Vuex。这个方案叫做静默登录恢复体验比强制重新登录好很多。7.4 定时任务与线程安全问题库存预警的定时任务一开始我用的是简单线程ScheduledExecutorService部署后发现如果在多实例环境下跑每个实例都会执行一次预警扫描产生重复预警。后来改用Spring的Scheduled注解配合一个分布式锁基于数据库唯一约束实现解决多实例重复执行问题。库存扣减的并发问题我在前面提到用条件更新来避免超扣这里再补充一点即使条件更新保证了单个库存记录不超扣但如果有两笔出库同时操作同一库存后执行的那笔会因为影响行数为0而失败。这个失败是正常的我应该把这个失败转成明确的业务异常提示而不是让前端收到一个泛泛的数据库错误。7.5 日常使用的业务坑最后说一个非技术问题系统上线后库管员反映录入试剂信息太慢每瓶试剂都要填十几个字段。后来我给前端加了一个复制新增功能可以在已有试剂的基础上复制一份再修改局部信息录入效率提升了很多。这个需求不在最初设计里是用户真正用起来之后才提的。做这类管理系统一定要预留迭代的空间第一版不可能完美用户反馈才是最真实的需求来源。整套系统跑下来我的体会是这类仓储管理系统的技术难度其实不高真正的难点在业务流程的梳理和细节的打磨。出入库流程、审批链路、权限控制、数据一致性每一块都需要站在用户的角度想清楚。技术永远是解决业务问题的手段而不是目的。如果这篇文章能帮你少踩几个坑那这套系统的经验就没白分享。