企业官网建设流程全解析

如果你在高校实验室待过，大概率见过这样的场景：管理员从抽屉里翻出厚厚一沓纸质台账，一页页比对某瓶化学试剂还剩多少、什么时候过期；学生填写领取单要跑三个办公室找签字；月底盘点把几百种试剂一瓶瓶从柜子里搬出来数。这些看起来是小事，可一旦涉及危化品，就上升到了安全管理层面。我这次完成的基于SpringBoot+Vue的高校危化试剂仓储管理系统，就是冲着这套手工流程去的，用Java做后端服务、MySQL存业务数据、MyBatis处理数据库操作、Vue做管理界面，把危化品的入库、库存、领用、出库、预警整个链路管起来。

这篇文章会把这个项目从需求拆解、数据库设计、后端接口实现、前端页面开发到部署上线的完整思路写出来，也会把我实测过程中踩过的坑一并交代。适合正在做毕设、课设，或者想拿一个完整前后端分离项目练手的人参考，哪怕你之前只是学过框架基础，照着这套逻辑也能把项目搭起来。

1. 为什么我把“高校危化品仓储管理”当成实战项目来做

1.1 高校实验室里的危化品管理，痛点远比想象中多

我在做这个项目之前，专门去了解过几个高校实验室的管理现状。大多数实验室不是没有制度，而是制度挂在墙上，实操靠人肉。危化品的采购信息、入库信息、存放位置、领用记录，往往散落在不同的Excel表甚至纸质本子上。管理员想查某一种试剂什么时候到期的，得先翻半天台账；想统计这个月哪些实验室领用量最大，只能手动汇总；更麻烦的是，一旦出现账实不符，根本说不清楚是入库漏记、出库没销还是中途损耗。

这类问题放到普通耗材上可能只是对不上账，放到危化品上就是实打实的安全隐患。所以高校普遍要求这类试剂实行闭环管理：从采购计划开始，到入库验收、库存保管、领用审批、出库登记，每一步都要留下可追溯的记录。可手工做闭环管理实在太累，这正是软件系统能发挥价值的地方。

1.2 这套系统真正要管住的三件事

拆解需求的时候，我没急着画页面，先想清楚了系统到底要管什么。核心就三件事。

第一件事是“账实相符”。系统里的库存数量必须能对上仓库里实际摆放的数量，这决定了出入库不能只做简单的增删改，还要有批次、有流水、有冲销机制，任何一次数量变化都要能追溯到单据。

第二件事是“过程留痕”。谁在什么时间申请了哪种试剂，哪个老师审批的，管理员什么时候发的货，试剂放到几号柜哪个位置，这些信息要完整可查。所以系统的数据模型一定是围绕“流水”设计的，而不是围绕“当前库存”设计的。

第三件事是“风险预警”。危化品里有很多试剂对存量有上限要求，也有不少试剂有保质期和失效期，还有的使用频率很低但必须常备。系统需要能提前提示管理人员：哪些试剂快低于库存下限了，哪些快过期了，哪些长期不用需要处理了。

把这三点想清楚，后面所有表结构和接口设计都有了依据。做管理系统最容易犯的错就是一上来就堆功能，结果页面一大堆，核心业务链路反而是断的。

1.3 什么样的读者适合拿这个项目练手

我觉得这个项目最值得学习的地方，是它覆盖了一条完整的前后端业务链路，但又没有复杂到让新手劝退。如果你刚学完JavaWeb和前端框架，想找一个能写进简历、能完整演示的项目，它是很合适的。相比纯电商系统，危化品仓储的领域模型更清晰，业务规则更明确，后期答辩或者讲项目的时候，很容易把“为什么这么设计”讲透。

当然，如果你是零基础刚看完语法，我建议你先去把SpringBoot的自动配置、MyBatis的Mapper原理、Vue的生命周期这些基础补一补，再来啃这个项目。否则遇到报错容易分不清是框架问题还是业务问题。

2. 技术选型的分工逻辑：SpringBoot、Vue、MyBatis、MySQL各管哪一段

2.1 后端为什么锁定SpringBoot

现在做Java后端起项目，SpringBoot基本是默认选项，但我还是想说说它在这个项目里到底带来了什么。

最直观的是简化了配置。传统的SSM要写一堆XML配置文件，数据源、事务、扫描包都要手动配，SpringBoot用自动配置把这层体力活消化掉了，我只需要在application.yml里写上数据源连接信息和MyBatis的mapper扫描路径，项目就能跑起来。这对于单机部署的管理系统来说，省掉的配置成本非常可观。

第二点是它内置了Tomcat。开发的时候直接跑main方法，不用单独装容器；部署的时候打成一个jar包，扔到服务器上一条java -jar命令就能启动。对高校实验室这种环境来说，服务器资源有限、运维水平参差不齐，这种“一个jar包搞定”的部署方式非常友好。

还有一点，SpringBoot生态对MyBatis的整合做得比较顺。mybatis-spring-boot-starter引入之后，SqlSessionFactory自动创建，Mapper接口自动扫描，开发者只需要关注SQL本身。在快速迭代业务逻辑的阶段，这种顺畅度很重要。

2.2 MyBatis在库存多条件查询里的价值

这个项目的查询场景很典型：库存列表要根据化学品名称、CAS号、分类、存放仓库、库存状态等多个条件组合筛选，而且这些条件可能任意为空。用JDBC手写的话，SQL拼接要写大量if判断；用JPA的话，复杂查询反而不太直观。MyBatis的XML动态SQL正好卡在这个需求点上。

比如库存查询，我用一个<where>标签配合<if>标签，就能把所有可选条件拼成一句安全的SQL。这样做的好处是SQL完全可控，遇到性能问题可以直接优化SQL本身，而不是去调框架的抽象层。另外一个重要原因是，MyBatis对结果集的映射更直白，数据库字段是下划线风格，Java属性是驼峰风格，开启map-underscore-to-camel-case之后，查询结果自动对应到实体类上，省去了一大堆手动set的代码。

2.3 Vue侧负责什么，以及前后端分离怎么组织

前端我用Vue搭建，配合Vue Router做页面路由、Vuex或Pinia存登录状态、Axios请求后端接口。页面分为登录页、工作台、化学品档案管理、库存管理、出入库管理、领用审批、统计报表、系统管理等模块。

前后端分离之后，开发阶段的协作方式很简单：后端只提供JSON接口，前端只负责渲染和交互。本地开发时前端用Vite或WebpackDevServer起一个8081端口，通过代理把/api前缀的请求转发到后端8080，这样就不会有跨域问题。生产环境则是把前端build出来的dist目录交给Nginx托管，Nginx再把/api反向代理到后端服务。

这套组织方式现在已经是主流，但它对这个项目还有一个额外价值：危化品管理涉及多个角色，比如学生、教师、实验室管理员、系统管理员，他们的操作界面差异比较大。前后端分离后，前端可以根据角色动态生成菜单和路由，后端只需要校验接口权限，不用关心页面怎么渲染。

3. 数据库设计是这类系统的命根子：从台账反推表结构

3.1 核心业务表怎么拆分

我设计数据库的时候，脑子里先放了一本“手工台账”，然后想：如果要让这套台账电子化、可查询、可统计，需要哪些表。最终核心表分成六张。

第一张是用户表，存登录账号、密码、姓名、角色类型。第二张是化学品档案表，记录化学品的名称、别名、CAS号、分子式、危化品分类、储存条件、MSDS附件路径、默认库存上下限。第三张是库存批次表，因为同一化学试剂可能分多批入库，每一批的生产日期、失效日期、入库日期、当前剩余量很可能不一样，不能用一张总库存表糊弄过去。第四张是出入库流水表，所有数量变动都记录在这张表里，包括入库、出库、盘盈盘亏冲销。第五张是领用申请表，记录谁申请、申请什么、申请多少、指导教师是否审批、管理员是否发放。第六张是存放位置表，也就是仓库里的柜子、货架、冷藏位等。

这里我最想强调的是“库存批次表”存在的必要性。如果只设计一张化学品的总量字段，入库时加数量、出库时减数量，表面上看很简单，但你无法回答“这批试剂还有多少没过期”“是哪批先入库的”这类问题。有了批次表，每次入库生成一个批次，出库时按批次先进先出扣减，才算真正符合危化品仓储的精细化管理要求。

3.2 “双人双锁”和台账追溯在数据模型里怎么落地

高校危化品仓库通常有“双人双锁”的管理要求，意思是一类危险试剂的柜门需要两个保管员同时在场才能打开，避免单人接触高风险试剂。这个制度反映到系统里，就是出库环节不能只有一个人操作。

我的做法是在领用申请和出库记录上增加两个字段：保管人确认人和审核人。学生提出领用申请后，指导教师先做审批，然后管理员在出库登记页面填写实发数量时，系统要求记录两位现场人员的工号或姓名，相当于把线下“双人双锁”动作数字化。这个设计不仅是形式上满足制度，更重要的是让每一次高风险试剂出库都有两个责任人背书。

台账追溯则依赖流水表的“不可删除”规则。我在业务代码里做了约定：所有出入库记录只能增加冲销记录，不能修改或物理删除原始记录。这样做的好处是，任何时刻打开系统，都能还原出某一种试剂从进场到出场的完整生命周期。数据库层的关联字段也很关键：流水表要同时存化学品ID、批次ID、单据号、操作人ID、操作时间，这样既能按化学品追溯，也能按时间范围筛选。

3.3 几个容易设计错的地方

我在数据库设计阶段踩过几个坑，在这里给后来人提个醒。

第一个坑是把“危化品分类”设计成字符串字段，直接填“易燃液体”“腐蚀品”这种文字。看起来直观，但后面做统计、做权限控制会很痛苦。比如管理员想按类别筛选所有“氧化剂”，如果分类字段是自由文本，就会遇到大小写不一致、别名混杂的问题。正确做法是单独建一张分类数据字典表，化学品表用分类ID关联。

第二个坑是库存数量用浮点数。化学品称量经常出现0.35克、1.2毫升这类数据，很多人习惯用double存。但浮点数经过多次加减之后会积累误差，可能导致库存对不上。应该用DECIMAL类型，并且统一单位精度，比如全部用“克”“毫升”做基本单位，入库时把单位换算清楚再存。

第三个坑是忽略“流水号”字段。有人觉得数据库主键自增就够了，但实际业务中，管理员打印单据、跟线下纸质单核对的时候，更习惯看到一条格式明确的单据号，比如RK20250601001表示入库、CK20250601001表示出库。建议在表里增加业务单号字段，用日期加序列生成，方便线上线下对账。

3.4 初始化数据字典很重要

数据库表建好之后，不要急着写接口，先把数据字典初始化做掉。我是把化学品分类、计量单位、存放仓库、柜位信息、初始化管理员账号都做成了SQL脚本，一次性导入。这一步看起来不起眼，但能让后面的开发省很多事，因为前端下拉框的数据都来自这些字典表，如果每写一个下拉框都去后端单独写一个接口，那会非常零散。

我还会往化学品档案表里预置一批常见的实验室试剂，比如无水乙醇、丙酮、盐酸、氢氧化钠等。这些数据不光方便测试，也方便演示系统。答辩或者汇报的时候，打开库存页面就能看到完整的示范数据，展示效果会好很多。

4. 后端核心链路拆解：从入库到出库的长链路实现

4.1 登录与RBAC权限控制

后端第一个模块是登录认证和权限控制。我用SpringSecurity配合JWT实现，用户登录成功后后端签发一个token，前端把它存在本地，每次请求带到Authorization头里，后端通过过滤器校验token有效性。

权限模型采用的是RBAC，也就是用户、角色、权限三层。这个项目里我定义了四种角色：学生、指导教师、实验室管理员、系统管理员。他们看到的菜单和能调的接口各不一样，比如学生只能提交领用申请、查看自己的申请记录；指导教师只能审批自己名下的学生的申请；实验室管理员拥有库存管理、出入库登记的权限；系统管理员则负责用户维护、数据字典和系统设置。

实现上，我在每个接口上用@PreAuthorize注解标注需要的角色，比如出库登记接口限制为管理员角色，审批接口限制为教师角色。这样即使前端隐藏了按钮，后端也不会被绕过，安全性可控。

4.2 入库业务：批次、数量、存放位置一起锁定

入库接口的逻辑比想象中多一点。前端会提交一个入库单，内容包括化学品ID、数量、单位、生产日期、失效日期、存放仓库ID、柜位ID、供应商名称、入库经手人。后端接收后，在一个事务里完成三件事。

第一步，往库存批次表插入一条新记录，状态为“在库”。第二步，在出入库流水表里插入一条入库流水，流水类型为“入库”，操作人取当前登录用户的ID。第三步，更新化学品档案表的库存汇总字段，也就是把总可用数量加上本次入库量。这三步必须在同一个数据库事务里完成，否则可能出现批次表有了数据但流水缺失，或者库存汇总对不上批次明细的情况。

我在做扣减库存和增加库存这类操作时，还加了一层乐观锁处理。库存表上有一个version字段，更新时使用UPDATE stock SET quantity = quantity - #{num}, version = version + 1 WHERE id = #{id} AND quantity >= #{num}这种写法，从SQL层面保证不会并发扣成负数。这一点在高校仓库实操场景中尤其重要，因为出库可能集中在学期初和学期末，多个管理员同时操作很常见。

4.3 出库业务：申请、审批、核销、扣减四个动作

出库链路是这个项目里最核心的业务流程，我把整个流程拆成了四个动作：申请、审批、核销、扣减。

学生或教师发起领用申请时，填写要领取的化学品、数量、用途说明，系统会校验当前库存是否充足，并且拦下那些库存低于预警值的申请，提示先联系管理员补货。申请提交后进入待审批状态。

指导教师角色在待办列表里看到申请，可以同意或者驳回。同意只是流程通行，库存此时还没有变化，这一点很重要。很多初学者会把审批和出库混成一个接口，结果一审批库存就扣了，但实际货物还没发出去，账实就分叉了。

管理员在核销阶段填写实际发放数量。因为实际称量和申请数量一般会有少量出入，所以系统允许管理员填写本次实发数。点击确认后，后端才真正执行库存扣减，并且根据先进先出的原则，从最早批次开始扣减数量。同时流水表会生成一条出库记录，申请单状态变更为“已出库”。

这样拆分下来，每一步的职责都很清晰，出了问题也容易定位。比如学生说申请了但没拿到货，那肯定是卡在审批或核销环节，查状态就能知道。

4.4 库存预警与有效期提醒的实现方案

预警功能是这个项目里比较出彩的部分。我做了三类推送：库存低于下限预警、有效期临近预警、呆滞库存提醒。

库存预警的逻辑很简单，每次出入库操作后，对比化学品档案表里设置的库存下限，低于下限的化学品ID被标记，管理员登录后可以看到一个待办卡片。有效期预警用定时任务来实现，我用的Spring自带的@Scheduled注解，每天凌晨跑一次，查询所有批次中失效日期在30天内的记录，如果批次还有剩余数量，就生成一条预警信息。呆滞库存提醒则统计超过180天没有任何出入库流水的在库批次，提醒管理员这些试剂需要检查是否过期或者是否该调剂使用。

用定时任务的好处是简单可靠，不需要额外引入消息队列。对于高校实验室这种数据量，每天扫一次完全够用。需要注意的是，预警表的数据要设计成已读状态，管理员点击“已读”后不再重复提醒，避免每天被同样的消息刷屏。

5. 前端Vue侧的实现：让老师和管理员愿意天天用

5.1 页面结构与路由权限

前端页面的规划我按照角色使用频率来排：登录后，学生第一个看到的是“我的申请”，因为他的主要动作就是申请领用；教师看到的是“审批待办”，实验室管理员看到的是“库存总览”和“出入库登记”。

路由权限是用VueRouter的全局前置守卫实现的。用户在登录时后端返回角色信息，前端把角色和可访问路由的映射关系维护好。每次跳转前，守卫判断目标路由是否需要特定角色，如果当前用户角色不匹配，直接重定向到403页面。菜单也是根据角色动态渲染的，Element Plus的菜单组件配合一个根据角色过滤后的路由配置数组，就能做到每个角色只看到自己能用的功能。

这里我提一个经验：前端路由守卫只是体验层面的控制，真正的安全要靠后端接口鉴权。不要因为前端隐藏了按钮就觉得安全了，直接调接口一样能绕过。所以我在前后端两边都做了同样的权限控制，前端管展示，后端管数据。

5.2 高危试剂选择的联动表单

领用申请表单是这个项目交互上最需要打磨的地方。试剂的种类多、名称相近，如果让用户从几百条数据里手动找一个下拉项，体验很差。

我做了一个联动选择器：首先是危化品分类的下拉框，用户选了“易燃液体”之后，试剂名称的下拉框自动只显示该分类下的化学品。如果用户知道完整名称，也可以直接输入关键字远程搜索，后端提供一个按名称或CAS号模糊查询的接口，前端用el-select的远程搜索方法触发。选中试剂后，页面自动带出当前的可用库存总量、存放位置、危险特性标签，并显示单位选择。

数量输入框上我加了双重的校验：前端校验不能超过当前库存，后端事务里还会再次判断。表单提交前还会弹出一个确认提示框，展示本次领用的试剂名称、危险分类、数量，相当于线上版的“操作前确认”，让申请人对高危试剂的操作保持敬畏。

5.3 统计看板与图表展示

统计页面我用ECharts做了几个图表。第一个是每月出入库趋势图，横轴是月份，纵轴是出入库数量，用两条折线对比，管理员一眼就能看出来哪些月份是领用高峰，方便提前备货。第二个是库存分布饼图，按危化品分类统计当前在库试剂的数量占比，帮助管理人员了解库存结构是否合理。第三个是高频领用试剂排行榜，用柱状图展示相关数据。

ECharts在Vue里的用法很简单，组件挂载后初始化实例，然后setOption传入数据和配置，注意在组件销毁时调用dispose方法释放实例，避免内存泄漏。图表数据统一由后端统计接口返回聚合结果，不要在浏览器端做大量计算，因为数据量大了之后前端会卡顿。

这块内容不需要做得很复杂，但对项目的观感提升明显。之前做管理系统只关心表格能不能展示数据，其实一张好的统计图比几页明细表更能说明问题，汇报和答辩的时候也更有说服力。

5.4 容易被忽视的使用体验细节

有几个细节是实际用过之后才补上去的，新手开发时特别容易忽略。

第一个是列表页的刷新保留条件。管理员在库存页面筛选了分类、输入了名称，点进详情再返回，筛选条件如果没了，会非常恼火。我用Pinia把查询条件暂存起来，返回列表时恢复，这个小改动极大提升使用体感。

第二个是操作反馈要明确。所有提交类操作完成后，不仅弹成功提示，还要让列表自动刷新。比如出库完成后，当前化学品的剩余数量要立刻更新，不要让用户手动刷新页面才能看到结果。

第三个是危险品要有视觉标识。化学品列表里，危化品分类我做了Tag标签，易燃易爆类的用比较醒目的颜色，普通试剂用中性色。看起来只是样式问题，但对仓库管理员来说，颜色标签能帮助快速识别高风险物品，减少因为看错名称导致的操作失误。

6. 联调、打包部署与实测中踩过的坑

6.1 本地联调的流程与跨域处理

前后端各自开发完之后，联调阶段是最容易出问题的。我当时的流程是：先确保后端接口用Postman或Swagger全部跑通，再去调前端页面。

Swagger在这个项目里帮了大忙。SpringBoot集成springfox或springdoc之后，启动项目就能看到一个接口文档页面，每个接口的请求参数、返回结构一目了然。前端联调的时候对照Swagger，不用频繁问后端要文档，效率高很多。

跨域问题在联调中也出现过。我用的是Vite代理方案，在vite.config.js里配置server.proxy，把/api开头的请求转发到后端服务的地址，这样浏览器看到的请求是同源的，不存在跨域。如果你用Nginx部署测试环境，也可以把跨域问题交给Nginx处理，反向代理天然规避了跨域。

6.2 打包成jar后如何配合Nginx上线

部署环节是很多学生项目最薄弱的，我简单说一下我验证过的方案。

后端项目用Maven的package命令打成jar包，前提是application.yml里配置了生产环境的数据库地址。服务器上只需要安装JDK和MySQL，用nohup java -jar manage-system.jar > app.log 2>&1 &启动，日志输出到文件，方便排查问题。前端在项目目录执行npm run build，生成dist目录，上传到服务器的Nginx目录下。

Nginx的配置关键点在location匹配。我把前端页面托管到根路径，把/api路径代理到本机的8080端口：location /api { proxy_pass http://127.0.0.1:8080; }。这里要注意，带不带末尾斜杠会影响转发的URL拼接，我当时因为proxy_pass的路径写法和location的路径叠加关系搞混，导致接口全部404，排查了半天。

还有一点，前端路由使用history模式时，用户刷新某个子页面会报404，需要在Nginx配置里加上try_files $uri $uri/ /index.html;，让所有找不到的静态资源请求都回退到首页，由前端路由接管。

6.3 实测中遇到的典型问题与解决记录

我把开发过程中印象最深的几个问题列出来，按问题、原因、解决思路整理成一张表，方便对照排查。

这里特别说下时区那个坑。MySQL连接串如果不指定serverTimezone，默认可能取到服务器系统时间，而JDBC驱动解析的时候又会按JVM默认时区处理，两边不一致就会出现数据差了8小时。这个坑在部署到云服务器时更常见，因为服务器默认时区往往是UTC，本地开发可能没事，一部署就出问题。

6.4 上线之后我的一些维护建议

系统部署完成、能跑通业务之后，真正的工作才开始。我看到很多同学做完项目就把源码放一边，这其实很可惜。至少有几件事是值得坚持做的。

第一件是定期备份数据库。仓库管理系统的数据是资产，库存账本丢了对实验室来说是很严重的事故。我在服务器上写了一个简单的crontab脚本，每天凌晨用mysqldump导出数据库，保留最近30天的备份文件，顺便同步一份到远程存储。这个操作成本很低，但能救命。

第二件是给用户账号做年度盘点。高校人员流动大，学生毕业、老师调岗都很快。如果账号不清理，权限会越来越泛滥。建议管理员定期把学生账号冻结或删除，导师角色也要跟着人事变动调整。

第三件是关注预警表的推送效果。预警不是发出来就完事，要跟进处置结果。我在系统里加了一个“处置记录”字段，管理员可以填写某某批次的临期化学品已经调配到其他实验室使用了，或者已进入报废流程。这样预警信息就形成了闭环，而不是一条看完就删的通知。

做这个项目给我最大的体会是，管理系统看起来到处都有，但真要把一个领域的业务逻辑理清楚、做成能稳定运行的系统，并不像套模板那么简单。尤其是危化品这种涉及安全责任的场景，一个字段少设计、一个流程少判断，背后都可能对应着真实的账实不符风险。如果你也在做类似的项目，建议先下功夫理解业务流程和数据库设计，把基础层做好，再去填充那些锦上添花的功能。这样不管前端是Vue还是React，后端换了什么框架，核心思路都能复用。