做Java后端这几年我经手过不少“管理系统”类的项目但“基于Springboot物资捐赠和分配系统”这类题目几乎是每年毕业设计和技术社区私信里绕不开的高频需求。原因很简单它不是一个纯粹增删改查的CRUD堆砌而是包含了权限控制、库存联动、捐赠与分配双流程、事务处理和统计报表的一套完整业务闭环能很直观地体现开发者对Spring Boot的理解水平。我自己也在带学生和帮人评审毕设这套系统我前前后后拆过好几版。今天把这套系统从需求分析、数据库设计到核心代码实现、部署避坑完整梳理一遍内容整理成了一篇可以直接当参考文档用的文章。无论你是正在做毕业设计还是想在公司内部快速搭一套物资管理小程序都可以直接照着这套思路来。1. 系统需求拆解与技术选型1.1 物资捐赠和分配到底在管什么先把业务搞清楚。一套物资捐赠和分配系统维度的核心不是“登录注册”而是围绕物资的“进、存、出、查”四个环节。进捐赠方登记要捐的物资系统记录捐赠人、物资名称、数量、捐赠时间。存物资入库后进入库存库存要能实时反映当前可用量。出受助方提交申请管理员审核并分配物资系统生成分配出库记录。查所有捐赠明细、分配明细、库存余量、按类别和时间的统计报表。传统做法是什么一张Excel表打天下。但在真实场景里物资品类复杂有食品、有药品、有衣物它们的单位、保质期、存储条件都不一样。再加上捐赠方和受助方是两拨人信息全靠人工同步经常出现“账上显示有货、仓库里早空了”或者“物资堆在仓库没分配出去”的尴尬局面。这个系统解决的就是把“台账”变成“活账”每一笔物资流动都有时间戳、经手人和状态标记谁都能查到物资去向统计数据也实时更新。1.2 技术选型为什么Spring Boot是首选这部分是面试和答辩时最容易被追问的很多人只知道自己用了Spring Boot说不出为什么选它。我把选型逻辑拆开讲。首先是为什么用Spring Boot而不是传统SSH框架。Spring Boot的核心价值在于“约定大于配置”。做毕设或者企业内部快速落地时没人想花两周去配XML和web.xml。Spring Boot内嵌Tomcat、自动配置数据源和常用组件、自带健康检查项目秒级启动。持久层我推荐MyBatis-Plus而非JPA。原因很务实JPA对复杂查询的SQL控制力弱而物资管理必然涉及多表联查和统计SQLMyBatis-Plus既能写自定义SQL又有分页插件和条件构造器开发速度和SQL可控性兼顾。有的版本用原生MyBatis也可以但Plus能少写很多XML。数据库是MySQL理由不用多说开源、部署简单、市面资料多。真正要注意的是SQL文件要同时兼容MySQL 5.7和8.0这两个版本的驱动和连接配置有差异后面我会专门讲到这个坑。前端这块如果做分离项目可以用VueElementUI但如果是毕设或者给非技术部门用的内部工具我更推荐Thymeleaf服务端渲染。原因也很简单不涉及跨域、不用额外起Node服务、部署就是一个Jar包省掉了一大堆环境问题。模板引擎渲染表格和表单后台管理系统的体验完全够用。1.3 角色权限模型设计这个系统的用户不是单一角色至少有四类系统管理员全权限负责物资审核、分配审批、用户管理。捐赠方登记捐赠、查看自己的捐赠记录。受助方/申请方提交物资需求申请、查看分配结果。普通访客可选查看公开公示信息。权限控制我建议用RBAC模型不需要引入Spring Security这么重的框架自己写一个拦截器加上角色判断就够用。核心是一张用户表关联角色表角色表关联权限表。当然如果对方要求更强的安全性再换成Spring Security JWT也不迟。注意权限这块千万别写死在Controller里判断角色编码比如直接判断user.getRole()admin。项目规模小的时候没问题但万一角色种类增加比如加了“审计员”你就要改N个Controller。用拦截器统一处理URL规则比如/admin/**只能管理员访问这样扩展性才好。2. 数据库设计与核心表关系2.1 核心表全景数据库设计是整个系统的心脏。我见过太多人上来就写代码结果表结构设计不合理写到后面发现库存和捐赠记录对不上只能推倒重来。这套系统核心表至少有7张我列出表名和作用表名作用关键字段示例sys_user系统用户捐赠方/管理员/申请方id, username, password, real_name, role_idsys_role角色表id, role_code, role_namematerial物资档案表id, material_no, name, category, unit, shelf_lifedonation捐赠单主表id, donation_no, user_id, donation_time, statusdonation_item捐赠单明细表id, donation_id, material_id, quantitydistribution分配单主表id, distribution_no, applicant_id, apply_time, statusdistribution_item分配单明细表id, distribution_id, material_id, quantitystock库存表id, material_id, quantity, warehouse为什么要拆主表和明细表这是电商订单的标准设计思路。捐赠人可能一次性捐了10箱矿泉水、5箱方便面、3盒口罩如果只放一张表字段会冗余得没法看。主表记“谁在什么时候捐了”明细表记“具体捐了哪几样、各是多少”。2.2 库存表设计的关键点库存表的逻辑值得多说两句。最基础的做法是每种物资一条库存记录purchase_quantity记录入库总量allocate_quantity记录已分配量available_quantity是当前可用量。但真正做项目时要加一个version整型字段做乐观锁。有人会问一个毕设系统也需要考虑并发吗我告诉你真要考虑。在实际演练里两个管理员同时处理不同申请单都去分配同一批库存极少的物资时如果没有并发控制库存就会出现负数。乐观锁解决方式就是UPDATE stock SET quantity quantity - #{num}, version version 1 WHERE id #{id} AND version #{version}更新行数为0就提示“库存不足请刷新后重试”。还有一件事物资有效期。食品、药品这类物资必须有expire_date字段分配时优先分配临期物资这个逻辑叫FEFO先到期先出。如果系统里不想做这么复杂的策略至少要支持按有效期倒序排序让管理员一眼看到哪些物资快过期了。2.3 状态字段一套流程的灵魂很多初学者的表设计里只有一个状态字段这是不够的。捐赠流程、分配流程必须各自有独立的状态字段和状态机。捐赠单的状态大体是待审核 → 已入库 / 审核驳回 / 已撤销。分配单的状态大体是待审批 → 待出库 → 已出库 / 已驳回。在设计时我建议状态用tinyint存储0、1、2、3或者用varchar存储枚举值PENDING、APPROVED、REJECTED不要用没有注释的字符串。同时每张业务表都加上create_time、update_time、create_by、update_by四个通用字段后面写审计日志和排查问题时你就知道这几个字段有多重要了。3. 核心功能模块与关键代码实现3.1 登录认证与密码安全登录模块不要用简单的Session也不要裸存明文密码。我的做法是密码加盐后MD5加密。虽然MD5强度不如BCrypt但考虑到项目部署环境的依赖轻量性和熟悉度MD5加随机盐在毕设场景完全够用但你一定要在文档里写明“生产环境建议升级为BCrypt”。认证方式我建议用JWT。登录成功后签发一个Token前端每次请求在Header里携带后端用拦截器校验。JWT的好处是服务端无状态后面如果想拆分前后端项目登录逻辑一行都不用改。这里给出关键代码结构参考public class JwtUtil { private static final String SECRET your-secret-key; public static String generateToken(User user) { return Jwts.builder() .setSubject(user.getUsername()) .claim(userId, user.getId()) .claim(role, user.getRoleCode()) .setExpiration(new Date(System.currentTimeMillis() 1000L * 60 * 120)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } }拦截器里判断角色是重点。我平时这样设计URL规则/admin/**系统管理员专属/donor/**捐赠方专属/applicant/**受助方专属/public/**所有人可访问用于公示页面拦截器放行时需要解析Token把用户信息塞到ThreadLocal里方便后续Service层获取当前操作人。这里有个细节preHandle中解析完Token不要放回请求头里建议用request.setAttribute(userId, ...)传递避免污染业务参数。3.2 物资入库的事务处理物资捐赠入库的流程是用户提交捐赠单 → 管理员审核 → 审核通过后同时生成入库流水和增加库存。这个流程必须加Transactional否则会出现“捐赠单状态更新了但库存没增加”的惨剧。运行时事务生效有几个前提必须是public方法不能被同类内部调用this.xxx()不行因为代理失效异常必须继承RuntimeException像ClassNotFoundException这种受检异常不会触发回滚我在真实代码里会让方法抛出RuntimeException并在事务外层用try-catch捕获后转换为业务提示。Transactional(rollbackFor Exception.class) public void approveDonation(Long donationId) { // 1. 更新捐赠单状态为已入库 donationMapper.updateStatus(donationId, DonationStatus.APPROVED); // 2. 遍历捐赠明细逐条更新库存存在则增量不存在则新增 ListDonationItem items donationItemMapper.findByDonationId(donationId); for (DonationItem item : items) { stockService.increaseStock(item.getMaterialId(), item.getQuantity()); } // 3. 写入入库流水 inventoryLogService.logIn(donationId, items); }这里有个大的易错点事务里嵌套调用stockService.increaseStock时如果increaseStock方法自身也加了Transactional默认情况下会被合并到当前事务里这是正确的。但如果increaseStock里自己catch了异常没抛出来事务就不会回滚你要特别小心不要吞掉异常。3.3 库存扣减与乐观锁分配物资的核心逻辑是扣库存。这个过程要面对超卖风险。正确的步骤是查询当前库存校验可用量是否满足申请数量执行带乐观锁的UPDATE第3步如果update影响行数为0说明这个时间窗口里库存被其他人改过了直接抛业务异常让用户重试。public boolean deductStock(Long materialId, Integer quantity) { // 乐观锁更新利用version字段防止并发覆盖 int rows stockMapper.deductStockWithVersion(materialId, quantity); return rows 0; }对应的SQLUPDATE stock SET available_quantity available_quantity - #{quantity}, version version 1 WHERE material_id #{materialId} AND available_quantity #{quantity} AND version #{version}这一步能不能在Service层用synchronized锁解决可以但只对单节点生效而且锁粒度不好控制。用乐观锁是更通用也更简单的路子面试时你把这个讲清楚加分不少。3.4 统计报表怎么实现统计报表是这类系统文档里必定会提到的功能。常见统计维度有按日/周/月统计捐赠入库总量按物资类别统计库存分布按受助方统计分配量排行我的做法是实体类不做复杂查询直接在Mapper层写统计SQL用一个StatisticsVO接收查询结果。-- 按月统计捐赠入库总量 SELECT DATE_FORMAT(donation_time, %Y-%m) AS month, COUNT(*) AS donation_count, SUM(item.quantity) AS total_quantity FROM donation d JOIN donation_item item ON d.id item.donation_id WHERE d.status 2 -- 已入库 GROUP BY DATE_FORMAT(donation_time, %Y-%m) ORDER BY month DESC前端图表部分用ECharts或者Chart.js就行。Thymeleaf模板内嵌ECharts直接把Java查询出来的JSON数据塞进script标签里。这一步很多人不会做我告诉你一个诀窍在Controller里把数据用JSON.toJSONString()转成字符串通过Thymeleaf的[[${chartData}]]注入前端就能直接拿来初始化图表。4. 部署运行与文档编写全流程4.1 环境准备与配置修改这个项目的运行环境有三大件JDK 1.8、Maven 3.6、MySQL 5.7/8.0。IDE用IDEA就行现在新版本对Java和Maven生态的支持非常顺手。下载项目后不要急着启动先干三件事第一找到application.yml或者application.properties改数据库账号密码和URL。MySQL 8.0的用户名和连接驱动跟旧版本不一样MySQL 8.0需要在URL里加serverTimezoneAsia/ShanghaiuseSSLfalse驱动要用com.mysql.cj.jdbc.Driver。这些细节搞错项目启动必报错。第二用MySQL工具执行项目的SQL文件把库和表结构导进去。第三检查pom.xml里的依赖版本。说到底Spring Boot 2.x和3.x差异很大3.x要求JDK17很多老项目的代码是跑不起来的。这套系统如果是Spring Boot 2.3.7这种经典版本尽量别改版本号。配置示例server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/donation_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl4.2 启动过程与常见报错启动Spring Boot项目时最怕看到一片红色的报错。我把高频报错和排查清单整理出来报错现象大概率原因解决方案Table doesnt existSQL文件没导入或有大小写问题检查库名表名Linux下MySQL表名区分大小写Access denied for user数据库账号密码错误检查yml配置和MySQL用户权限Port 8080 was already in use端口被占用改端口或netstat -ano找占用进程Invalid bound statementMyBatis的Mapper XML路径不对检查mapper-locations配置和XML的namespaceFailed to configure a DataSource数据源配置缺失或位置不对确认application.yml在resources根目录Jackson序列化日期乱码日期格式没配置在yml配置jackson.date-format启动成功后访问http://localhost:8080/login应该能看到登录页。默认密码通常会在项目文档里写清楚比如admin/admin123。如果登录页白屏或者CSS样式丢失多半是Thymeleaf模板路径写错了控制器返回的视图名和templates目录下的文件名要对齐。4.3 项目文档怎么写得加分这部分的“文档”质量是很多答辩和评审的隐形分。不是让你写一篇流水账而是要有针对性。一份完整的项目文档必须包含五块内容概述部分项目背景、解决什么问题、面向什么人用。技术栈描述框架、版本、数据库、部署方式。数据库设计文档E-R图、表结构说明、关键字段含义用表格列清楚。核心功能说明每个模块的两三句话说明加一张截图。部署手册从拉取代码到跑起来的每一步附带截图最好。经验之谈很多人在文档里放了大段的“系统原理”却忘了写“默认账号是什么”“部署步骤是什么”这种文档评审老师看了很头疼。站在使用者的角度写文档会比你站在开发者角度写收获更多好评。5. 常见问题排查与避坑技巧5.1 连接数据库的三大坑第一个坑是时区问题。MySQL 8.0默认时区是UTC如果URL里不指定serverTimezoneAsia/Shanghai时间字段插入后所有时间都会差8小时日志和记录全都对不上。第二个坑是字符集。建库要指定utf8mb4不是utf8毕竟utf8mb4才完整支持表情符号和其他特殊字符。连接URL也要带上characterEncodingutf8保证前后端编码统一。第三个坑是驱动版本。MySQL 8.0的驱动默认路径变了有时候你明明装了MySQL却报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver这是因为你的依赖版本是5.x的而你连的是8.x的库。5.2 事务不生效的真正原因很多学生跑完项目发现一个灵异事件代码逻辑没错但异常后数据库没回滚。第一反应是查Transactional有没有加错位置加在private方法上是无效的。还有一种极其隐蔽的情况你在方法内部通过this调用另一个事务方法事务也不会生效。原因是Spring的事务基于AOP代理this调用走的是本类对象而非代理对象事务通通失效。解决方式是注入自己Autowired private XxxService service;或者把需要事务的方法单独抽到另一个Service类里让外部调用的入口走代理。我在代码里推荐后者逻辑会更清晰。5.3 MyBatis的XML映射文件检查Invalid bound statement是一个非常高频的报错。如果你用的Spring Boot 2.x一种典型原因是pom.xml里没有把src/main/java下的XML文件作为资源打包进去。解决方式是在pom.xml的build里加resources resource directorysrc/main/java/directory includes include**/*.xml/include /includes /resource /resources还有一个坑是Mapper接口与XML命名空间不匹配XML里的namespace必须指向Mapper接口的全限定名SQL的id必须对应接口方法名。这些地方错了IDE不报错运行期才炸。5.4 动态条件查询要用好条件构造器MyBatis-Plus的条件构造器很好用但需要注意在业务中做“按时间范围查询”这种操作时很多人传了空字符串进去导致SQL走了错误分支。我在封装查询条件时都会先做一层空值判断。public IPageDonation pageQuery(DonationQuery query) { PageDonation page new Page(query.getCurrent(), query.getSize()); LambdaQueryWrapperDonation wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getDonationNo()), Donation::getDonationNo, query.getDonationNo()) .eq(query.getStatus() ! null, Donation::getStatus, query.getStatus()) .ge(query.getStartTime() ! null, Donation::getDonationTime, query.getStartTime()) .le(query.getEndTime() ! null, Donation::getDonationTime, query.getEndTime()) .orderByDesc(Donation::getCreateTime); return donationMapper.selectPage(page, wrapper); }这里用的小技巧是.前面的StringUtils.hasText(...)或query.getStatus() ! null只有条件成立时后面的SQL片段才会拼接既能防止空值查询偏出也避免拼接字符串的注入风险。6. 核心代码模块与后续扩展建议6.1 配置文件与启动类这套系统的启动类非常简单SpringBootApplication注解即可注意开启Mapper扫描。SpringBootApplication MapperScan(com.example.donation.mapper) public class DonationApplication { public static void main(String[] args) { SpringApplication.run(DonationApplication.class, args); } }6.2 通用返回类与统一异常处理这种管理系统前端需要统一的响应格式我建议定义一个返回值类包装数据避免每个接口各搞各的格式。统一响应结果的类结构建议不低于5个字段。public class ResultT { private Integer code; // 状态码200成功400业务错误401未登录500系统错误 private String message; private T data; private long timestamp; public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }统一异常处理的类用RestControllerAdvice注解。在这个类里把自定义的业务异常、参数校验异常分开捕获日志记录放在这里做也行。这样Controller层就不需要到处写try-catch代码干净很多。6.3 系统扩展方向建议这套系统的架构完全具备扩展性如果你有精力可以在现有基础上做三件事第一引入Redis做缓存。库存查询和捐赠热榜这类高频读操作缓存能显著提升响应速度。但要注意缓存与数据库的一致性问题最简单的方式是更新数据库后主动删除缓存下次查询时重建。第二引入Spring Security OAuth2实现第三方登录和细粒度权限适合把系统开放给公众使用。第三前端换成Vue3 Element Plus把后端接口全部改造成纯REST API再用Nginx做反向代理解决跨域。这是目前主流前端项目的标准形态改造价值很高。6.4 给初学者的实操建议如果你是第一次接触这类整套项目我建议不要上来就埋头看代码。一个更好的学习路径是先跑起来再按模块读代码最后自己动手改功能。具体来说先启动项目用默认账号登录操作一遍完整的捐赠、审核、分配流程。这一步能帮你建立“数据流”的感觉。然后打开数据库表把刚才操作后每条记录的变化对照一遍搞懂哪一步改了哪张表。最后再开始断点调试跟着一次申请物资的请求从Controller走到Mapper观察整个调用链路。这样走完你对Spring Boot项目的理解深度会拉开很多同学一大截。7. 关于这套系统的个人总结项目本身不算深但涉及的点恰好都是Spring Boot开发的日常。权限设计、事务处理、乐观锁、报表统计每一个都是实际工作中会被反复问到的核心话题。从我带过的学生来看把这一套系统真正吃透去面中小厂的Java岗Spring Boot相关的问题基本都能聊上几句。最后分享一个我在资料整理上的小习惯源码里一定要保留SQL初始化脚本。不止是建表语句还要插入一条默认管理员账号。每次有同学让我远程帮看项目十次有八次都是卡在账号密码不对和没初始化数据上这两件事提前做好能帮你省下大量沟通成本。这套代码在实际部署中踩过的坑基本都在上面了。按这个思路去动手把环境跑通、把流程走顺、把文档补齐你会发现自己写出来的项目比那些连启动都报错的同学整体质量高出一大截。
Spring Boot物资捐赠与分配系统实战：从需求分析到部署避坑
做Java后端这几年我经手过不少“管理系统”类的项目但“基于Springboot物资捐赠和分配系统”这类题目几乎是每年毕业设计和技术社区私信里绕不开的高频需求。原因很简单它不是一个纯粹增删改查的CRUD堆砌而是包含了权限控制、库存联动、捐赠与分配双流程、事务处理和统计报表的一套完整业务闭环能很直观地体现开发者对Spring Boot的理解水平。我自己也在带学生和帮人评审毕设这套系统我前前后后拆过好几版。今天把这套系统从需求分析、数据库设计到核心代码实现、部署避坑完整梳理一遍内容整理成了一篇可以直接当参考文档用的文章。无论你是正在做毕业设计还是想在公司内部快速搭一套物资管理小程序都可以直接照着这套思路来。1. 系统需求拆解与技术选型1.1 物资捐赠和分配到底在管什么先把业务搞清楚。一套物资捐赠和分配系统维度的核心不是“登录注册”而是围绕物资的“进、存、出、查”四个环节。进捐赠方登记要捐的物资系统记录捐赠人、物资名称、数量、捐赠时间。存物资入库后进入库存库存要能实时反映当前可用量。出受助方提交申请管理员审核并分配物资系统生成分配出库记录。查所有捐赠明细、分配明细、库存余量、按类别和时间的统计报表。传统做法是什么一张Excel表打天下。但在真实场景里物资品类复杂有食品、有药品、有衣物它们的单位、保质期、存储条件都不一样。再加上捐赠方和受助方是两拨人信息全靠人工同步经常出现“账上显示有货、仓库里早空了”或者“物资堆在仓库没分配出去”的尴尬局面。这个系统解决的就是把“台账”变成“活账”每一笔物资流动都有时间戳、经手人和状态标记谁都能查到物资去向统计数据也实时更新。1.2 技术选型为什么Spring Boot是首选这部分是面试和答辩时最容易被追问的很多人只知道自己用了Spring Boot说不出为什么选它。我把选型逻辑拆开讲。首先是为什么用Spring Boot而不是传统SSH框架。Spring Boot的核心价值在于“约定大于配置”。做毕设或者企业内部快速落地时没人想花两周去配XML和web.xml。Spring Boot内嵌Tomcat、自动配置数据源和常用组件、自带健康检查项目秒级启动。持久层我推荐MyBatis-Plus而非JPA。原因很务实JPA对复杂查询的SQL控制力弱而物资管理必然涉及多表联查和统计SQLMyBatis-Plus既能写自定义SQL又有分页插件和条件构造器开发速度和SQL可控性兼顾。有的版本用原生MyBatis也可以但Plus能少写很多XML。数据库是MySQL理由不用多说开源、部署简单、市面资料多。真正要注意的是SQL文件要同时兼容MySQL 5.7和8.0这两个版本的驱动和连接配置有差异后面我会专门讲到这个坑。前端这块如果做分离项目可以用VueElementUI但如果是毕设或者给非技术部门用的内部工具我更推荐Thymeleaf服务端渲染。原因也很简单不涉及跨域、不用额外起Node服务、部署就是一个Jar包省掉了一大堆环境问题。模板引擎渲染表格和表单后台管理系统的体验完全够用。1.3 角色权限模型设计这个系统的用户不是单一角色至少有四类系统管理员全权限负责物资审核、分配审批、用户管理。捐赠方登记捐赠、查看自己的捐赠记录。受助方/申请方提交物资需求申请、查看分配结果。普通访客可选查看公开公示信息。权限控制我建议用RBAC模型不需要引入Spring Security这么重的框架自己写一个拦截器加上角色判断就够用。核心是一张用户表关联角色表角色表关联权限表。当然如果对方要求更强的安全性再换成Spring Security JWT也不迟。注意权限这块千万别写死在Controller里判断角色编码比如直接判断user.getRole()admin。项目规模小的时候没问题但万一角色种类增加比如加了“审计员”你就要改N个Controller。用拦截器统一处理URL规则比如/admin/**只能管理员访问这样扩展性才好。2. 数据库设计与核心表关系2.1 核心表全景数据库设计是整个系统的心脏。我见过太多人上来就写代码结果表结构设计不合理写到后面发现库存和捐赠记录对不上只能推倒重来。这套系统核心表至少有7张我列出表名和作用表名作用关键字段示例sys_user系统用户捐赠方/管理员/申请方id, username, password, real_name, role_idsys_role角色表id, role_code, role_namematerial物资档案表id, material_no, name, category, unit, shelf_lifedonation捐赠单主表id, donation_no, user_id, donation_time, statusdonation_item捐赠单明细表id, donation_id, material_id, quantitydistribution分配单主表id, distribution_no, applicant_id, apply_time, statusdistribution_item分配单明细表id, distribution_id, material_id, quantitystock库存表id, material_id, quantity, warehouse为什么要拆主表和明细表这是电商订单的标准设计思路。捐赠人可能一次性捐了10箱矿泉水、5箱方便面、3盒口罩如果只放一张表字段会冗余得没法看。主表记“谁在什么时候捐了”明细表记“具体捐了哪几样、各是多少”。2.2 库存表设计的关键点库存表的逻辑值得多说两句。最基础的做法是每种物资一条库存记录purchase_quantity记录入库总量allocate_quantity记录已分配量available_quantity是当前可用量。但真正做项目时要加一个version整型字段做乐观锁。有人会问一个毕设系统也需要考虑并发吗我告诉你真要考虑。在实际演练里两个管理员同时处理不同申请单都去分配同一批库存极少的物资时如果没有并发控制库存就会出现负数。乐观锁解决方式就是UPDATE stock SET quantity quantity - #{num}, version version 1 WHERE id #{id} AND version #{version}更新行数为0就提示“库存不足请刷新后重试”。还有一件事物资有效期。食品、药品这类物资必须有expire_date字段分配时优先分配临期物资这个逻辑叫FEFO先到期先出。如果系统里不想做这么复杂的策略至少要支持按有效期倒序排序让管理员一眼看到哪些物资快过期了。2.3 状态字段一套流程的灵魂很多初学者的表设计里只有一个状态字段这是不够的。捐赠流程、分配流程必须各自有独立的状态字段和状态机。捐赠单的状态大体是待审核 → 已入库 / 审核驳回 / 已撤销。分配单的状态大体是待审批 → 待出库 → 已出库 / 已驳回。在设计时我建议状态用tinyint存储0、1、2、3或者用varchar存储枚举值PENDING、APPROVED、REJECTED不要用没有注释的字符串。同时每张业务表都加上create_time、update_time、create_by、update_by四个通用字段后面写审计日志和排查问题时你就知道这几个字段有多重要了。3. 核心功能模块与关键代码实现3.1 登录认证与密码安全登录模块不要用简单的Session也不要裸存明文密码。我的做法是密码加盐后MD5加密。虽然MD5强度不如BCrypt但考虑到项目部署环境的依赖轻量性和熟悉度MD5加随机盐在毕设场景完全够用但你一定要在文档里写明“生产环境建议升级为BCrypt”。认证方式我建议用JWT。登录成功后签发一个Token前端每次请求在Header里携带后端用拦截器校验。JWT的好处是服务端无状态后面如果想拆分前后端项目登录逻辑一行都不用改。这里给出关键代码结构参考public class JwtUtil { private static final String SECRET your-secret-key; public static String generateToken(User user) { return Jwts.builder() .setSubject(user.getUsername()) .claim(userId, user.getId()) .claim(role, user.getRoleCode()) .setExpiration(new Date(System.currentTimeMillis() 1000L * 60 * 120)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } }拦截器里判断角色是重点。我平时这样设计URL规则/admin/**系统管理员专属/donor/**捐赠方专属/applicant/**受助方专属/public/**所有人可访问用于公示页面拦截器放行时需要解析Token把用户信息塞到ThreadLocal里方便后续Service层获取当前操作人。这里有个细节preHandle中解析完Token不要放回请求头里建议用request.setAttribute(userId, ...)传递避免污染业务参数。3.2 物资入库的事务处理物资捐赠入库的流程是用户提交捐赠单 → 管理员审核 → 审核通过后同时生成入库流水和增加库存。这个流程必须加Transactional否则会出现“捐赠单状态更新了但库存没增加”的惨剧。运行时事务生效有几个前提必须是public方法不能被同类内部调用this.xxx()不行因为代理失效异常必须继承RuntimeException像ClassNotFoundException这种受检异常不会触发回滚我在真实代码里会让方法抛出RuntimeException并在事务外层用try-catch捕获后转换为业务提示。Transactional(rollbackFor Exception.class) public void approveDonation(Long donationId) { // 1. 更新捐赠单状态为已入库 donationMapper.updateStatus(donationId, DonationStatus.APPROVED); // 2. 遍历捐赠明细逐条更新库存存在则增量不存在则新增 ListDonationItem items donationItemMapper.findByDonationId(donationId); for (DonationItem item : items) { stockService.increaseStock(item.getMaterialId(), item.getQuantity()); } // 3. 写入入库流水 inventoryLogService.logIn(donationId, items); }这里有个大的易错点事务里嵌套调用stockService.increaseStock时如果increaseStock方法自身也加了Transactional默认情况下会被合并到当前事务里这是正确的。但如果increaseStock里自己catch了异常没抛出来事务就不会回滚你要特别小心不要吞掉异常。3.3 库存扣减与乐观锁分配物资的核心逻辑是扣库存。这个过程要面对超卖风险。正确的步骤是查询当前库存校验可用量是否满足申请数量执行带乐观锁的UPDATE第3步如果update影响行数为0说明这个时间窗口里库存被其他人改过了直接抛业务异常让用户重试。public boolean deductStock(Long materialId, Integer quantity) { // 乐观锁更新利用version字段防止并发覆盖 int rows stockMapper.deductStockWithVersion(materialId, quantity); return rows 0; }对应的SQLUPDATE stock SET available_quantity available_quantity - #{quantity}, version version 1 WHERE material_id #{materialId} AND available_quantity #{quantity} AND version #{version}这一步能不能在Service层用synchronized锁解决可以但只对单节点生效而且锁粒度不好控制。用乐观锁是更通用也更简单的路子面试时你把这个讲清楚加分不少。3.4 统计报表怎么实现统计报表是这类系统文档里必定会提到的功能。常见统计维度有按日/周/月统计捐赠入库总量按物资类别统计库存分布按受助方统计分配量排行我的做法是实体类不做复杂查询直接在Mapper层写统计SQL用一个StatisticsVO接收查询结果。-- 按月统计捐赠入库总量 SELECT DATE_FORMAT(donation_time, %Y-%m) AS month, COUNT(*) AS donation_count, SUM(item.quantity) AS total_quantity FROM donation d JOIN donation_item item ON d.id item.donation_id WHERE d.status 2 -- 已入库 GROUP BY DATE_FORMAT(donation_time, %Y-%m) ORDER BY month DESC前端图表部分用ECharts或者Chart.js就行。Thymeleaf模板内嵌ECharts直接把Java查询出来的JSON数据塞进script标签里。这一步很多人不会做我告诉你一个诀窍在Controller里把数据用JSON.toJSONString()转成字符串通过Thymeleaf的[[${chartData}]]注入前端就能直接拿来初始化图表。4. 部署运行与文档编写全流程4.1 环境准备与配置修改这个项目的运行环境有三大件JDK 1.8、Maven 3.6、MySQL 5.7/8.0。IDE用IDEA就行现在新版本对Java和Maven生态的支持非常顺手。下载项目后不要急着启动先干三件事第一找到application.yml或者application.properties改数据库账号密码和URL。MySQL 8.0的用户名和连接驱动跟旧版本不一样MySQL 8.0需要在URL里加serverTimezoneAsia/ShanghaiuseSSLfalse驱动要用com.mysql.cj.jdbc.Driver。这些细节搞错项目启动必报错。第二用MySQL工具执行项目的SQL文件把库和表结构导进去。第三检查pom.xml里的依赖版本。说到底Spring Boot 2.x和3.x差异很大3.x要求JDK17很多老项目的代码是跑不起来的。这套系统如果是Spring Boot 2.3.7这种经典版本尽量别改版本号。配置示例server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/donation_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl4.2 启动过程与常见报错启动Spring Boot项目时最怕看到一片红色的报错。我把高频报错和排查清单整理出来报错现象大概率原因解决方案Table doesnt existSQL文件没导入或有大小写问题检查库名表名Linux下MySQL表名区分大小写Access denied for user数据库账号密码错误检查yml配置和MySQL用户权限Port 8080 was already in use端口被占用改端口或netstat -ano找占用进程Invalid bound statementMyBatis的Mapper XML路径不对检查mapper-locations配置和XML的namespaceFailed to configure a DataSource数据源配置缺失或位置不对确认application.yml在resources根目录Jackson序列化日期乱码日期格式没配置在yml配置jackson.date-format启动成功后访问http://localhost:8080/login应该能看到登录页。默认密码通常会在项目文档里写清楚比如admin/admin123。如果登录页白屏或者CSS样式丢失多半是Thymeleaf模板路径写错了控制器返回的视图名和templates目录下的文件名要对齐。4.3 项目文档怎么写得加分这部分的“文档”质量是很多答辩和评审的隐形分。不是让你写一篇流水账而是要有针对性。一份完整的项目文档必须包含五块内容概述部分项目背景、解决什么问题、面向什么人用。技术栈描述框架、版本、数据库、部署方式。数据库设计文档E-R图、表结构说明、关键字段含义用表格列清楚。核心功能说明每个模块的两三句话说明加一张截图。部署手册从拉取代码到跑起来的每一步附带截图最好。经验之谈很多人在文档里放了大段的“系统原理”却忘了写“默认账号是什么”“部署步骤是什么”这种文档评审老师看了很头疼。站在使用者的角度写文档会比你站在开发者角度写收获更多好评。5. 常见问题排查与避坑技巧5.1 连接数据库的三大坑第一个坑是时区问题。MySQL 8.0默认时区是UTC如果URL里不指定serverTimezoneAsia/Shanghai时间字段插入后所有时间都会差8小时日志和记录全都对不上。第二个坑是字符集。建库要指定utf8mb4不是utf8毕竟utf8mb4才完整支持表情符号和其他特殊字符。连接URL也要带上characterEncodingutf8保证前后端编码统一。第三个坑是驱动版本。MySQL 8.0的驱动默认路径变了有时候你明明装了MySQL却报java.lang.ClassNotFoundException: com.mysql.jdbc.Driver这是因为你的依赖版本是5.x的而你连的是8.x的库。5.2 事务不生效的真正原因很多学生跑完项目发现一个灵异事件代码逻辑没错但异常后数据库没回滚。第一反应是查Transactional有没有加错位置加在private方法上是无效的。还有一种极其隐蔽的情况你在方法内部通过this调用另一个事务方法事务也不会生效。原因是Spring的事务基于AOP代理this调用走的是本类对象而非代理对象事务通通失效。解决方式是注入自己Autowired private XxxService service;或者把需要事务的方法单独抽到另一个Service类里让外部调用的入口走代理。我在代码里推荐后者逻辑会更清晰。5.3 MyBatis的XML映射文件检查Invalid bound statement是一个非常高频的报错。如果你用的Spring Boot 2.x一种典型原因是pom.xml里没有把src/main/java下的XML文件作为资源打包进去。解决方式是在pom.xml的build里加resources resource directorysrc/main/java/directory includes include**/*.xml/include /includes /resource /resources还有一个坑是Mapper接口与XML命名空间不匹配XML里的namespace必须指向Mapper接口的全限定名SQL的id必须对应接口方法名。这些地方错了IDE不报错运行期才炸。5.4 动态条件查询要用好条件构造器MyBatis-Plus的条件构造器很好用但需要注意在业务中做“按时间范围查询”这种操作时很多人传了空字符串进去导致SQL走了错误分支。我在封装查询条件时都会先做一层空值判断。public IPageDonation pageQuery(DonationQuery query) { PageDonation page new Page(query.getCurrent(), query.getSize()); LambdaQueryWrapperDonation wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getDonationNo()), Donation::getDonationNo, query.getDonationNo()) .eq(query.getStatus() ! null, Donation::getStatus, query.getStatus()) .ge(query.getStartTime() ! null, Donation::getDonationTime, query.getStartTime()) .le(query.getEndTime() ! null, Donation::getDonationTime, query.getEndTime()) .orderByDesc(Donation::getCreateTime); return donationMapper.selectPage(page, wrapper); }这里用的小技巧是.前面的StringUtils.hasText(...)或query.getStatus() ! null只有条件成立时后面的SQL片段才会拼接既能防止空值查询偏出也避免拼接字符串的注入风险。6. 核心代码模块与后续扩展建议6.1 配置文件与启动类这套系统的启动类非常简单SpringBootApplication注解即可注意开启Mapper扫描。SpringBootApplication MapperScan(com.example.donation.mapper) public class DonationApplication { public static void main(String[] args) { SpringApplication.run(DonationApplication.class, args); } }6.2 通用返回类与统一异常处理这种管理系统前端需要统一的响应格式我建议定义一个返回值类包装数据避免每个接口各搞各的格式。统一响应结果的类结构建议不低于5个字段。public class ResultT { private Integer code; // 状态码200成功400业务错误401未登录500系统错误 private String message; private T data; private long timestamp; public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }统一异常处理的类用RestControllerAdvice注解。在这个类里把自定义的业务异常、参数校验异常分开捕获日志记录放在这里做也行。这样Controller层就不需要到处写try-catch代码干净很多。6.3 系统扩展方向建议这套系统的架构完全具备扩展性如果你有精力可以在现有基础上做三件事第一引入Redis做缓存。库存查询和捐赠热榜这类高频读操作缓存能显著提升响应速度。但要注意缓存与数据库的一致性问题最简单的方式是更新数据库后主动删除缓存下次查询时重建。第二引入Spring Security OAuth2实现第三方登录和细粒度权限适合把系统开放给公众使用。第三前端换成Vue3 Element Plus把后端接口全部改造成纯REST API再用Nginx做反向代理解决跨域。这是目前主流前端项目的标准形态改造价值很高。6.4 给初学者的实操建议如果你是第一次接触这类整套项目我建议不要上来就埋头看代码。一个更好的学习路径是先跑起来再按模块读代码最后自己动手改功能。具体来说先启动项目用默认账号登录操作一遍完整的捐赠、审核、分配流程。这一步能帮你建立“数据流”的感觉。然后打开数据库表把刚才操作后每条记录的变化对照一遍搞懂哪一步改了哪张表。最后再开始断点调试跟着一次申请物资的请求从Controller走到Mapper观察整个调用链路。这样走完你对Spring Boot项目的理解深度会拉开很多同学一大截。7. 关于这套系统的个人总结项目本身不算深但涉及的点恰好都是Spring Boot开发的日常。权限设计、事务处理、乐观锁、报表统计每一个都是实际工作中会被反复问到的核心话题。从我带过的学生来看把这一套系统真正吃透去面中小厂的Java岗Spring Boot相关的问题基本都能聊上几句。最后分享一个我在资料整理上的小习惯源码里一定要保留SQL初始化脚本。不止是建表语句还要插入一条默认管理员账号。每次有同学让我远程帮看项目十次有八次都是卡在账号密码不对和没初始化数据上这两件事提前做好能帮你省下大量沟通成本。这套代码在实际部署中踩过的坑基本都在上面了。按这个思路去动手把环境跑通、把流程走顺、把文档补齐你会发现自己写出来的项目比那些连启动都报错的同学整体质量高出一大截。
