★ FEATURED ARTICLE 去年接到一个疫情物资捐赠和分配管理系统的开发需求技术栈明确要求是SpringBootVueJava后端MySQL存数据MyBatis做持久层。第一反应就是这套组合太经典了搞过课程设计或者中小型业务系统的朋友应该都懂SpringBoot把后端配置降到最低Vue把页面拆成组件MySQL管事务MyBatis写动态SQL又灵活。但等我把需求梳理完才发现这个系统表面看就是“捐赠登记、物资入库、分配出库、数据统计”四件事真要做实务远比想象中要复杂。这篇文章就把我的设计思路、数据库建模、核心实现逻辑和踩坑记录一次性讲清楚适合正在做类似管理系统设计、准备毕业设计或者刚接触前后端分离项目的朋友直接参考。1. 项目整体设计与思路拆解1.1 业务需求这不是简单的出入库系统物资捐赠和分配系统和普通的进销存最大区别在于整个流程极强调“透明”和“可追溯”。捐赠方把一批物资捐过来系统要记录是哪个捐赠方、什么品名、什么规格、多少数量、什么批次、有效期到什么时候入库之后要能形成库存分配侧要根据受助对象的需求生成分配单审批通过后出库出库后还要能看到这批物资被分配到了哪里、有没有签收、还剩多少。所以系统核心角色至少要有三类管理员、仓库操作员、普通用户捐赠方/受助方都可以算进去。管理员负责分配审批、账号管理和整体数据查看仓库操作员负责入库、出库、盘点普通用户能提交捐赠登记、查看自己的捐赠记录和分配情况。这样一个流程下来才能做到每一件物资从哪儿来、到哪儿去都有据可查。还需要考虑一个很重要的使用场景突发公共卫生事件期间物资种类杂、有效期敏感、捐赠方多、分配需求变动快。如果系统只支持简单的“库存总数量增减”很快就会出现过期没人管、超发库存变负数、物资去向说不清的问题。因此设计上必须引入“批次”概念库存一定要按批次管理分配时优先分配临期物资这是整个系统最关键的点。1.2 技术选型为什么是这套组合技术栈上SpringBoot Vue MySQL MyBatis 放到今天依然是中小型管理系统的主力方案。SpringBoot 的好处不用多讲内嵌Tomcatjava -jar 就能跑省去了以前SSM那套繁琐的XML配置MyBatis 比 JPA 更透明复杂查询和动态条件筛选写SQL自己控制尤其适合这类多表关联、统计报表特别多的系统MySQL 的 InnoDB 引擎支持事务库存模块最怕数据错乱事务保证写入安全Vue 的优势在于表单多、状态多响应式数据绑定能省掉大量DOM操作Element UI / Element Plus 这类组件库又能快速搭出后台管理界面。有人可能会问为什么不用 Spring Cloud 微服务这个系统的体量根本没有到需要拆服务的程度拆了反而要处理服务通信、分布式事务、部署复杂度纯属给自己挖坑。为什么不用 JSP 老方案前后端不分离前端逻辑写起来很痛苦而且后来要扩展小程序端、对接第三方系统都不方便。核心判断标准就是一句话够用、稳定、可控。2. 核心功能拆解与数据库设计2.1 用户角色与权限设计权限这一块我推荐用“用户表 角色表 用户角色关联表”的方式而不是简单地在用户表里加一个 type 字段。虽然加 type 字段实现更快但后续如果要加“审核员”“调配专员”之类的角色改表结构就麻烦了。基础用户表字段大致是 id、username、password、real_name、phone、status、create_time。密码必须用 BCrypt 加密存储千万不能明文。角色表里预置 admin、operator、user 三种角色管理员账号在初始化SQL里插入。关联表负责把用户和角色绑定支持一个用户多角色。控制上要做两层第一层是前端路由守卫根据当前用户的角色控制能进入哪些菜单第二层是后端拦截器在访问敏感接口时校验角色。前端控制是为了体验后端控制才是真正保证安全的。这部分在实现里通过自定义注解 RequireRole 配合拦截器实现比在每个 Controller 里写角色判断干净得多。2.2 物资流转模型一切围绕批次我设计这个系统的数据库时最核心的思路是“所有库存变动都围绕批次展开”。一个批次对应一次捐赠入库有自己的批次号、生产日期、有效期、来源方。库存表里存的是批次级库存而不是物资大类库存。流程大概是捐赠方提交捐赠单仓库操作员核对后入库生成或更新一个库存批次管理员创建分配单选择接收单位、选择物资和数量系统自动按照“先到期先出”的规则从库存批次中扣减数量同时记录分配明细和批次出库记录接收方确认签收后分配单状态改为已完成。对应的核心表我最终确定为这些物资表 material捐赠单主表 donation_order、捐赠明细表 donation_item库存批次表 stock_batch分配单主表 allocation_order、分配明细表 allocation_item批次出库明细表 allocation_batch_detail物资流水日志表 stock_log。额外还有通知表、操作日志表就不展开细讲了。这样设计最大的好处是追溯能力强。比如某个接收单位反馈收到的方便面有质量问题我们可以从分配明细反查是哪个批次、哪笔捐赠单、哪个捐赠方捐赠的也能判断是否在保质期内。没有批次设计的话这类问题根本查不清楚。2.3 核心表结构细节说明库存批次表是整个系统的核心我贴一下关键字段设计CREATE TABLE stock_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT, batch_no VARCHAR(64) NOT NULL COMMENT 批次号, material_id BIGINT NOT NULL COMMENT 物资ID, total_quantity INT NOT NULL COMMENT 入库总数量, available_quantity INT NOT NULL COMMENT 当前可用数量, production_date DATE COMMENT 生产日期, expire_date DATE NOT NULL COMMENT 有效期, supplier VARCHAR(128) COMMENT 来源捐赠方, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_material_expire (material_id, expire_date) ) COMMENT 库存批次表;注意我特意建了 (material_id, expire_date) 联合索引因为库存列表最常用的两个操作就是按物资查和按到期日期排序。索引加上之后前端筛选“即将过期”的物资会快很多。分配明细表也很关键CREATE TABLE allocation_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, allocation_id BIGINT NOT NULL COMMENT 分配单ID, material_id BIGINT NOT NULL COMMENT 物资ID, apply_quantity INT NOT NULL COMMENT 申请数量, actual_quantity INT NOT NULL COMMENT 实际分配数量, stock_batch_id BIGINT COMMENT 来源批次ID, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT 分配明细表;这里把 stock_batch_id 直接放到分配明细里简化了查询。虽然批次出库明细单独存一张表也不是不行但考虑到系统规模不大把来源批次和数量合在一张表里查询分配单详情时一次 join 就能拿到所有数据效率更高。我实际测试下来这样设计在报表统计时确实省心。3. 后端核心实现SpringBoot MyBatis3.1 项目分层与工程结构后端工程结构我按这样的方式组织src/main/java ├── com.example.donation │ ├── controller 接口层 │ ├── service 业务层 │ │ └── impl │ ├── mapper MyBatis Mapper接口 │ ├── entity 实体类 │ ├── dto 前端交互参数对象 │ ├── common 统一返回结果、异常、常量 │ ├── config 拦截器、跨域等配置 │ └── task 定时任务库存预警Controller 只负责参数接收和返回业务逻辑全部放在 Service 层Mapper 只做数据库操作。很多初学者喜欢把业务写在 Controller 里面图省事但后面一旦要复用或者排查问题就会特别难受。我坚持一个原则Controller 里绝不写 if 判断业务逻辑一个方法只做一件事。3.2 捐赠入库多表写入必须同时成功捐赠入库这个动作后端涉及的不只是一张表保存捐赠单主表、保存捐赠明细表、更新库存批次表、写入流水日志。这四件事要么全部成功要么全部失败绝对不能出现“单子保存了但库存没加上”的情况。实现上就是在 Service 方法上加 TransactionalTransactional(rollbackFor Exception.class) public void receiveDonation(DonationOrderDTO dto) { // 1. 保存捐赠单主表 // 2. 保存捐赠明细列表 // 3. 逐个更新或新增库存批次 // 4. 写流水日志 }这里有个细节很多人不注意Transactional 默认只在 RuntimeException 时回滚如果方法抛的是 checked Exception事务不会回滚。所以我一般都会显式写成 rollbackFor Exception.class宁可把所有异常都纳入回滚范围也不要因为漏了 checked exception 导致库存数据不一致。3.3 分配出库如何彻底根治库存超发库存超发是这个系统遇到的最典型并发问题。场景是这样的两个分配单同时操作同一个批次库存A 单要扣 100B 单也要扣 100库存只有 150。如果都先查库存再更新就都会认为够扣最后扣成负数。正确的做法是直接在 SQL 层面做“条件更新”把这句更新作为原子操作UPDATE stock_batch SET available_quantity available_quantity - #{quantity} WHERE id #{batchId} AND available_quantity #{quantity}MyBatis 中执行这条 update通过返回的影响行数判断是否成功。如果影响行数为 0说明库存不够此时直接抛出业务异常让整个分配单事务回滚。这样做最核心的好处是数据库层面的行锁和条件判断保证了并发安全避免了“先查后改”很容易出现的竞态问题。我还做过一个额外的保障分配单主表加一个 status 字段所有更新操作都带条件 WHERE status 待确认防止用户重复点击提交导致同一个分配单被处理多次。前端按钮防抖是一回事后端状态判断才是真正的防线。3.4 MyBatis 动态 SQL 与报表查询技巧这个系统有大量的组合条件查询比如库存列表要支持按物资名称模糊查、按分类筛选、按是否临期筛选MyBatis 的whereif组合写起来非常舒服select idselectStockList resultTypemap SELECT m.name AS materialName, m.specification, s.batch_no, s.available_quantity, s.expire_date FROM stock_batch s JOIN material m ON s.material_id m.id where if testkeyword ! null and keyword ! AND m.name LIKE CONCAT(%, #{keyword}, %) /if if testexpireWarning AND s.expire_date gt; NOW() AND s.expire_date lt; DATE_ADD(NOW(), INTERVAL 30 DAY) /if /where ORDER BY s.expire_date ASC /select注意 XML 里写大于小于号一定要用转义字符gt;lt;不然 XML 解析直接报错。这个坑我见过太多人踩了。统计报表方面建议直接用 SQL 做聚合不要在前端遍历 JS 数组累加。比如月度捐赠量统计一条 GROUP BY 就能完成前端直接拿数据渲染 ECharts 图标。SQL 聚合数据更少、传输更快代码也更简单。4. 前端Vue实现与交互设计4.1 项目初始化和工具链踩坑前端我用的 Vue CLI 创建项目配合 Element UI 组件库如果 Vue3 就用 Element Plus。axios 封装一个 request.js统一设置 baseURL、请求头、超时时间、响应拦截器遇到 code ! 200 时自动弹出错误提示。最容易被卡住的是跨域问题。开发环境里前端跑在 localhost:8081后端跑在 localhost:8080ajax 直接请求后端会跨域。我推荐用开发代理去解决而不是在后端粗暴地加 CrossOrigin。比如 vue.config.js 里这样配module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }以后前端所有请求都走 /api 前缀浏览器看着是同源请求代理在中间转发到后端本地开发完全感觉不到跨域的存在。后端的 CrossOrigin 适合临时测试生产环境还是用 Nginx 反向代理更稳妥。4.2 核心页面拆解和流程状态整个系统前端页面不多但每个页面都有互动性。捐赠登记页用动态表格允许用户点击“添加一行”来填写多个物资项每一行包含物资名称、规格、数量、生产日期、有效期。动态表单实现时要注意 v-model 绑定数组里的对象字段删除行时下标会变化最好用唯一的行 id 而不是索引。分配单创建页稍微复杂一点。选择接收方之后添加物资明细时系统要根据物资 ID 请求后端查询可用批次和可分配数量。前端拿到批次列表后展示一个批次选择下拉框默认按有效期从早到晚排序用户也可以手动选择具体批次。这里的前端校验一定要做分配数量不能大于该批次的可用数量不然请求后端也会被拒白白浪费一次接口调用。库存管理页面就是典型的数据表格我加了三类状态标签正常、临期30天内到期、过期。过期物资不允许再分配列表里直接禁用分配按钮。统计页用 ECharts 展示柱状图和饼图柱状图看每月捐赠入库量和分配出库量的对比饼图看物资类别占比。数据全部来自后端聚合接口前端只负责渲染。4.3 路由守卫和权限控制的实现路由守卫这块我在 router/index.js 里给每个页面加了 meta.roles 配置然后在全局前置守卫里判断router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token) { next(/login) return } const roles JSON.parse(localStorage.getItem(roles) || []) if (to.meta.roles !to.meta.roles.some(r roles.includes(r))) { next(/403) return } next() })后端接口同样有权限拦截器所以前端守卫应付体验真正防止越权不能全靠它。因为 localStorage 里的 token 和 roles 本来就可以被修改如果需求严格的话后端接口要每次从 token 解析用户真实角色。5. 环境搭建与部署验证5.1 从零开始跑通这个系统如果你拿到项目源码想先在本地跑起来顺序很重要我建议按下面的步骤来。第一步装环境JDK 1.8 或 JDK 17看 SpringBoot 版本、Maven 3.x、Node.js 14、MySQL 5.7 或 8.0。这里要特别提醒一句SpringBoot 版本和 JDK 版本必须匹配。SpringBoot 2.7.x 用 JDK8 没问题SpringBoot 3.x 就必须 JDK17 以上如果你本地只装了 JDK8不建议硬上 SpringBoot 3版本太高会遇到一堆编译问题这就是很多人常说的“SpringBoot版本太高跑不起来”。第二步建数据库在 MySQL 里执行 init.sql脚本里包含库表创建和初始管理员账号然后修改后端 application.yml 里的数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/donation_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password第三步启动后端IDEA 里直接运行主类或者 mvn spring-boot:run看到 Tomcat initialized 和端口 8080 就说明启动成功。第四步启动前端在 frontend 目录下执行 npm install然后 npm run serve。如果 node_modules 安装时报错多半是 Node 版本太高导致 node-sass 不兼容换成 sass 或者降 Node 版本能解决。前端起来后访问 localhost:8081用管理员账号登录系统就能用了。5.2 MySQL 初始化脚本的几个细节初始化脚本里要包含建库语句指定 utf8mb4、建表语句、初始管理员账号插入语句。我踩过的一个坑是 MySQL 5.7 里如果表字段不指定字符集默认可能是 latin1中文乱码。解决方法是建库时执行CREATE DATABASE donation_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;另外一个常见怪问题数据库明明写对了启动后查询中文条件却查不到结果。检查一下 MySQL 连接 URL 后面有没有加 characterEncodingutf8mb4没加的话即使库表是 utf8mb4连接层也会用错编码。另外 MySQL 8.0 的驱动类名是 com.mysql.cj.jdbc.Driver5.7 用 com.mysql.jdbc.Driver别搞混。5.3 前端打包进后端还是 Nginx 单独部署部署方式有两种我都试过。第一种最简单前端执行 npm run build生成 dist 目录把里面的文件拷到后端的 src/main/resources/static 下然后后端打成 jar 包一个 java -jar 就把前后端都带起来了。这种模式适合内部测试、课程设计演示优点是省事。但有一个必须注意的点前端路由要用 hash 模式URL 带 #不能用 history 模式否则用户手动刷新某个子页面时后端没有对应的路由映射直接 404。第二种方式更正规Nginx 托管前端静态文件后端单独部署。Nginx 配置里做个反向代理把 /api 请求转发到后端服务server { listen 80; server_name your-domain; location / { root /opt/frontend/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; } }try_files 那行是为了解决 history 模式刷新 404 的问题。生产环境用 Nginx 的好处是不用把前端文件塞进 jar前端可以单独更新后端重启也不影响静态资源访问。6. 常见问题与排查技巧实录6.1 Transactional 失效的几种情况我见过太多人写事务方法发现不生效其实原因就那么几个。第一个是同一个类内部方法自调用比如 Service 里的 saveA 调用了本类方法 saveBsaveB 上的 Transactional 不会生效因为事务代理是通过外部调用才切入的内部 this 调用绕过了代理。解决办法是把事务方法拆到另一个 Service 类里或者注入自身代理对象。第二个是异常被 catch 吞掉。事务方法里有 try-catch捕获了异常但没有往外抛事务框架感知不到异常自然不会回滚。正确做法是 catch 到业务异常后继续抛出或者在 catch 里手动调用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。第三个是方法被 private 修饰。Spring 的声明式事务基于动态代理private 方法根本不会被代理拦截所以事务方法必须是 public。遇到奇怪的插入了一部分数据、后续报错但没回滚的情况优先排查这三点。6.2 MyBatis 映射和参数类型问题MyBatis 用多了你就会发现90%的报错都集中在映射文件和参数类型上。比如 XML 里写 resultType 写错了包路径启动时不容易发现但一调用接口就报 “Unknown column” 或 “could not set property”。我的排查习惯是先在 Navicat 或 MySQL 命令行执行一遍那条 SQL确认 SQL 本身没问题再去看映射关系。还有一个特别容易踩的细节UPDATE 语句中如果有动态参数参数顺序和数量要和 Param 指定的名称完全匹配否则 MyBatis 会报 “Parameter xxx not found”。建议小于三个参数直接用 Param 注解命名多于三个参数用一个 DTO 对象传进去别靠参数顺序硬扛不然重构时真的会疯。6.3 前后端联调时的接口字段规范问题前后端联调最难受的不是技术问题而是字段名对不上。后端返回 createdAt前端要 createTime结果页面表格每一列都是空白。我后来统一在商品详情和列表接口用驼峰命名后端实体开启 map-underscore-to-camel-case让数据库下划线字段自动映射到实体的驼峰属性同时在所有返回 DTO 里保持一致。前端拿到数据后不再做字段名转换省了大量调试时间。统一返回结构也很重要。我的所有接口返回都是{ code: 200, message: success, data: ... }异常由全局异常处理器统一捕获。前端 axios 响应拦截器里看到 code 不是 200 就直接弹错误提示业务代码里只需要关心 data非常干净。6.4 项目落地后的一些个人体会这个系统做完之后我的最大感受是库存类系统的难点根本不在 CRUD而在“并发正确性”和“流程状态一致性”。很多项目表面上表结构设计得挺漂亮但一遇到高并发或者操作频繁数据就乱了。这次真正把批次库存扣减的 SQL 条件更新方案落在项目里以后后面再遇到秒杀扣库存、预约名额占用这类场景我心里都有底了。另外建议大家给系统加一张操作日志表记录谁在什么时间做了什么操作特别是入出库、修改库存这些敏感动作。排查线上问题的时候操作日志比任何字段都管用。系统上线之后还可以继续扩展库存不足时自动通知管理员、接收方在小程序端自助确认签收、对接公众号推送捐赠回执这些都是围绕核心流程可以自然延伸的方向。这次我把需求拆解和实现过程完整记录下来既是项目复盘也是希望给各位一个可以直接借鉴的系统设计思路。
阅读完成 · 觉得有帮助？
