农机这行有个特别拧巴的现象农机主花几十万买的收割机一年真正下地的实际可能不到三个月而急需用机的农户到了抢收这几天求爷爷告奶奶都约不到机器。我最初接触“基于Spring Boot的农机租赁服务平台”这个题目时第一反应不是技术选型而是先弄明白这个平台到底要解决什么——它本质上解决的是农机闲置率与农户用机难之间的信息错配。后来做完整套系统我越发觉得这类“行业垂直通用技术”的项目非常适合拿来练手。它不像纯电商那样全是无脑增删改查也不至于像流式计算那么烧脑既有用户、农机、订单、评价这些标准 CRUD又有档期冲突校验、并发防重复预约、订单状态机、定时任务等真正考验设计能力的东西。这篇文章就把我从需求分析到落地的完整思路、核心实现和踩坑记录都摊开来讲适合准备拿它当毕业设计的同学也适合想系统走一遍 Spring Boot 项目开发的初级工程师。1. 项目背景与核心需求拆解1.1 农机租赁到底在租什么先讲业务。农机租赁这东西租的不是“一台机器”这么简单租的是“一段确定的时间窗口”。一台拖拉机在春耕期间比如4月20日到5月5日这半个月每一天都可能被不同的农户预约。所以数据库设计上不能只存农机表还要存一张“档期表”记录这台机器每一天的占用状态这是这个项目和其他租赁系统最不一样的地方。有人觉得这和酒店订房差不多。确实像但农机比酒店房间复杂的地方在于农机是可移动资产农机主得考虑接单后运到什么地方作业距离远不远、路况好不好农机价格贵押金和损坏责任划分很敏感农忙时节的时效性特别强农户错过三五天一季收成就受影响。所以系统里除了基础档案还要有清晰的地址信息、押金规则、违约条款这些字段。再往深一层想这个平台还要解决“信任”问题。农机主怕农机被农户开出问题、不按时归还农户怕付了押金、机器却带病作业耽误农时。所以评价体系和保证金规则不只是电商标配更是这个业务能不能跑起来的前提。我在设计时给评价模块单独留了扩展位后面对接信用分、纠纷仲裁都比较方便。1.2 角色与核心流程这个平台有三类用户农户是承租方农机主也可能是农机合作社是供给方平台管理员负责审核和运营。农户走的是“搜索农机→查看档期→下单→支付→取机使用→归还→评价”的链路农机主走的是“发布农机→等待审核→管理档期→确认归还→结算收入”的链路管理员则是审核农机上架、处理纠纷、查看统计报表、做日常运营。主体链路中最容易出问题的是两个环节一是下单时的档期冲突同一台机器同一天被两个人占用这在业务上属于严重事故二是订单状态的流转什么状态下能取消、什么状态下能退款、超时未归还怎么计费这些规则一定要在代码里固化下来不能靠人工判断。我在做细化设计时会把“谁在什么状态下能做什么操作”列成矩阵图然后照着矩阵把校验代码写进去这样不会漏。1.3 功能模块划分模块面向角色核心功能用户模块全部注册登录、实名认证、角色区分、个人信息农机模块农机主/管理员农机发布、图片上传、档期管理、上下架、审核检索模块农户按品类/价格/地区筛选、档期日历展示订单模块农户/农机主下单、支付、取消、确认完成、超时处理评价模块双方双向评价、评分统计后台管理管理员用户管理、农机审核、订单监控、数据报表模块拆分的原则是单一职责订单只管订单状态和金额农机只管农机档案和档期这样后面做定时任务、对账结算时不用到处打补丁。实际开发时我一般会先画一遍模块图把每个模块的输入输出列出来再写代码宁可前期多花一天也不要在最后返工。2. 技术选型与架构设计2.1 为什么选 Spring Boot而不是别的这个项目用 Spring Boot 几乎是顺理成章的选择。核心原因是它的“自动装配”机制把繁琐的框架配置变成了开箱即用的能力。原理其实不复杂Spring Boot 在启动时会通过EnableAutoConfiguration去加载META-INF/spring.factories或AutoConfiguration.imports里声明的配置类再配合ConditionalOnClass、ConditionalOnProperty之类的条件注解决定哪些 Bean 要创建。简单说就是框架先帮你把主食配好你只需要告诉它“今天吃面条还是米饭”。相比十年前的主流 SSM 手动拼 XMLSpring Boot 最大的好处是把“约定优于配置”落到了实处内嵌 Tomcat 让你不用额外部署 WAR 包起步依赖帮你锁好依赖版本配置文件一个application.yml搞定绝大部分设置。对于农机租赁这种业务逻辑为主、架构上不需要微服务的项目单体 Spring Boot 项目就是投入产出比最高的选择别为了凑技术栈硬上 Spring Cloud那样只会增加部署和调试成本。2.2 技术栈清单与版本选择我用的技术栈和版本直接列在下面组件选型说明Spring Boot2.7.18成熟稳定JDK 8 即可运行持久层MyBatis-Plus 3.5.x省去大量手写 SQL数据库MySQL 8.0InnoDB 引擎缓存/分布式锁Redis Redisson档期并发控制、热点农机缓存认证JWT Spring Security前后端分离场景下的标准方案前端Vue 3 Element Plus管理后台和农户端同一套代码构建Maven 3.8用 Gradle 还是 Maven 纯看团队习惯部署Docker Compose一键拉起 MySQL Redis 应用这里必须多说一句版本问题。很多人都被“Spring Boot 版本太高”坑过Spring Boot 3.x 要求 JDK 17包名从javax换成了jakarta很多老教程的代码直接编译不过MyBatis-Plus 也得换适配版本。说实话对于这种以业务实现为主的单体项目用 Spring Boot 2.7.x JDK 8/11 是最稳的组合依赖生态成熟、网上遇到的坑基本都被别人踩过、面试官也不会因为你没上最新版就扣分。我的原则是生产求稳学习求懂原理。2.3 分层架构与工程结构项目的包结构我按“控制器→服务→Mapper→实体”的分层来组织这也是 Spring Boot 单体项目最主流的目录规划方式com.agri.rental ├── controller // 接口层 ├── service // 业务层接口实现 ├── mapper // MyBatis-Plus Mapper ├── entity // 数据库实体 ├── dto // 入参出参对象 ├── config // 配置类安全、跨域、上传映射 ├── common // 公共返回结果、异常处理、常量 ├── task // 定时任务 └── utils // 工具类controller 只负责接收参数、做最基础的校验、调用 service、包一层统一的 Result 返回具体的业务逻辑都收拢在 service 里。为什么不在 controller 里写逻辑因为农机租赁的下单流程牵扯订单创建、档期占用、库存检查、支付单生成好几个动作放到一个 service 方法里才能保证事务边界清晰也方便写单元测试。这个结构看起来普通但真到排查问题和扩展功能的时候你会感谢当初没有把所有代码堆在一个 controller 里。3. 数据库设计与核心表结构3.1 设计思路数据库设计是这个项目最关键的环节。农机租赁的实体关系并不复杂user与machine是一对多一个农机主有多台农机machine与rental_order是一对多rental_order与review是一对一。容易出错的是“档期”这个概念我单独建了一张machine_schedule表记录每台农机每一天的占用状态这比在订单表里做日期范围判断要靠谱得多。为什么单独建表而不是直接在订单表里查“日期区间是否存在重叠”因为档期表天然适合加数据库唯一索引做到强约束还能顺带支持农机主自助设置“今天不租”“机器维修中”这类特殊状态。订单表只记录起止日期档期表按天落数据查询哪些天被占了一条 SQL 就能解决。每天一把锁的思路比给一整段区间加锁简单得多。3.2 核心表结构这里给出最关键的两张表结构其余表比较简单就不全贴了。machine_schedule表字段类型说明idBIGINT主键machine_idBIGINT关联农机schedule_dateDATE档期日期statusTINYINT0可租 1占用 2停租lock_order_idBIGINT占用的订单id可空唯一索引(machine_id, schedule_date)一台机器同一天只能有一条记录唯一索引是并发防重的最底层防线。就算业务代码里 Redis 锁偶尔失效数据库这层也能兜住。rental_order表裁剪版字段类型说明order_noVARCHAR(32)订单号唯一machine_idBIGINT农机idrenter_idBIGINT农户idowner_idBIGINT农机主idmachine_nameVARCHAR农机名称快照unit_priceDECIMAL(10,2)下单时单价快照start_dateDATE开始日期end_dateDATE结束日期rent_amountDECIMAL(10,2)租金deposit_amountDECIMAL(10,2)押金overdue_feeDECIMAL(10,2)超时费用order_statusTINYINT状态枚举actual_return_timeDATETIME实际归还时间订单里的名称、单价这类字段为什么要“快照”因为农机主完全可能在上架后调整租金如果订单关联的是实时价格用户下单时看到的和结算时算出来的对不上纠纷就来了。快照的本质是“下单那一刻的业务事实”。这一点在报表统计时也很重要统计历史订单金额不能拿现价算。3.3 数据一致性与并发控制的底层设计防重复预约是这个项目的核心难点之一。两台农户同时盯上同一台收割机在9月20日这一天系统怎么保证只有一个能下单成功我做了三层防护第一层Redisson 分布式锁。以rent:order:{machineId}:{date}为 key下单前先加锁拿到锁后再检查档期、创建订单、占用档期完成后释放锁。第二层档期表唯一索引。就算锁在极端情况下失效数据库也会因为唯一索引报错代码捕获异常返回“该日期已被占用”。第三层订单状态约束。已支付的订单不能因为重复提交再次占用档期。这三层按性价比排序的话唯一索引是最便宜最可靠的分布式锁解决的是“并发下单时检查与写入之间的线程穿插问题”订单状态约束解决的是“重复请求打进来的幂等问题”。三层加起来才算把这个业务风险真正堵死。单靠任何一层都有漏洞这个我后面在第五章会展开讲。4. 核心业务功能实现4.1 订单状态机与流程控制订单状态我用枚举来定义推荐大家也这么干别用魔法数字散落在 if 里public enum OrderStatus { PENDING_PAY(0, 待支付), PAID(1, 已支付), IN_USE(2, 使用中), PENDING_RETURN(3, 待归还), COMPLETED(4, 已完成), CANCELLED(5, 已取消), REFUNDED(6, 已退款); }状态流转的核心是校验合法性。比如“待支付”能走“取消”能走“支付”但“已完成”绝对不能退回“待支付”。我写了一个集中式的方法transition(from, to, order)做校验所有业务入口都走它代码大致是public void cancelOrder(Long orderId) { RentalOrder order orderService.getById(orderId); orderService.transition(order.getOrderStatus(), OrderStatus.CANCELLED, order); // 释放档期、记录日志 }为什么非要集中校验而不是每个入口自己判断因为这个项目的订单状态特别多分散判断很容易漏掉某一对的转换关系集中校验之后任何状态变化都有统一入口可以加日志后期排查“这个单子怎么变成这个状态”时直接翻日志就行。4.2 计费与结算的逻辑实现租金计算按“天”为最小单位超时按“小时”计费。核心计算代码long days ChronoUnit.DAYS.between(order.getStartDate(), order.getEndDate()); BigDecimal rentAmount order.getUnitPrice().multiply(BigDecimal.valueOf(days)); // 超时实际归还晚于计划结束日期按小时计算 if (actualReturnTime ! null actualReturnTime.isAfter(endDateTime)) { long overdueHours ChronoUnit.HOURS.between(endDateTime, actualReturnTime); BigDecimal overdueFee order.getUnitPrice() .divide(BigDecimal.valueOf(24), 2, RoundingMode.HALF_UP) .multiply(BigDecimal.valueOf(overdueHours)); }注意这里用的是order.getUnitPrice()也就是订单快照里的单价不是农机当前的最新价。明细金额算出来后会汇总到结算单里应收总额 租金 超时费 押金其中押金在确认无损坏后原路退回。这个流程建议用独立的结算表存一次账别到时候只能从零散的订单字段里拼。计费这里最容易被忽略的是金额精度。租金、押金、超时费全部用BigDecimal禁止用double。涉及到钱的东西精度问题在测试阶段基本看不出来跑到生产就对不上账了。4.3 定时任务的正确姿势这个项目里有几个场景天然适合定时任务超时未支付订单自动取消、租赁到期未归还提醒、每日经营数据汇总。Spring Boot 里用Scheduled就能实现几秒钟就能搞定Component EnableScheduling public class OrderScheduleTask { Scheduled(cron 0 */5 * * * ?) public void cancelExpiredOrders() { ListRentalOrder list orderMapper.selectList(new LambdaQueryWrapperRentalOrder() .eq(RentalOrder::getOrderStatus, OrderStatus.PENDING_PAY.getCode()) .le(RentalOrder::getCreateTime, LocalDateTime.now().minusMinutes(30))); for (RentalOrder order : list) { // 1. 将订单状态改为取消 // 2. 释放 machine_schedule 中被占用的档期 // 3. 记一条操作日志 } } }你以为这就完了不是。这里最容易踩的坑是“忘记释放档期”。如果只把订单状态改成取消档期表里那些天还挂在占用状态农机主眼睁睁看着机器空着却租不出去。所以定时任务里一定要把“释放档期”当成和“改状态”同样重要的一步。另一个细节是记得在启动类或配置类上加EnableScheduling这个太容易被漏掉如果系统变成多实例部署Scheduled会在每台机器上都跑一遍还要做好幂等兜底。4.4 认证授权与安全设计前后端分离的项目认证我选 JWT Spring Security。基本思路是用户登录成功后端签发一个带过期时间的 JWT Token前端保存到本地每次请求放到 Authorization 头里Spring Security 的过滤器从 Token 里解析出用户身份和角色注入到上下文中。权限上分三种角色ROLE_FARMER、ROLE_OWNER、ROLE_ADMIN。接口上用注解控制PreAuthorize(hasAnyRole(ROLE_OWNER,ROLE_ADMIN)) PostMapping(/machine) public Result addMachine(RequestBody MachineDTO dto) { // 只有农机主和管理员能发布农机 }这里有个新手容易忽略的细节JWT 是无状态的签发之后在过期之前很难主动让它失效。如果做了“退出登录”功能前端把 Token 删掉就行但如果用户手机丢了、账号被盗那 Token 在过期前仍然有效。所以在做安全设计时要么把 Token 过期时间设得短一点比如 2 小时配合 Refresh Token 机制要么引入 Redis 黑名单把主动退出的 Token 拉黑。做毕设可以简单一点但如果想讲出亮点这个点值得好好准备。5. 开发过程中踩过的坑5.1 版本兼容性陷阱我开头提到过 Spring Boot 版本问题。实际开发中最经典的坑是项目搭建在 Spring Boot 2.x 上一切正常某天升级到 3.x代码里的javax.servlet全部报红因为 3.x 换成了jakarta.servlet如果再配上 Java 17很多旧版 Lombok、MyBatis-Plus 的插件还会闹脾气。所以真心建议这类单体业务项目就用 Spring Boot 2.7.x JDK 8 或 11你可以花时间去看 3.x 的新特性源码但项目本身没必要冒险追新。5.2 MyBatis-Plus 的几个必修点用 MyBatis-Plus 能省不少事但有四个点特别容易出错。第一是分页插件必须显式配置 PaginationInnerInterceptor不配置的话Page参数会被无视。第二是逻辑删除在实体字段上标TableLogic再配全局逻辑删除字段删除操作就变成更新操作防止农机主下架机器后订单记录跟着没了。第三是字段自动填充create_time、update_time用MetaObjectHandler统一维护不要在每个插入语句里手工 set。第四是条件构造器的使用多用LambdaQueryWrapper避免硬编码数据库字段名的魔法字符串重构时才不会处处踩雷。5.3 图片上传和部署问题农机照片上传是个典型的小模块但坑不少。本地存储就够用配置文件里指定upload.dir用MultipartFile.transferTo()落盘再写一个 WebMvcConfigurer 把/upload/**映射到本地磁盘路径。这里有两个坑一是上传目录如果用相对路径不同启动目录下会跑到不同位置最好用绝对路径或者通过配置项注入二是默认spring.servlet.multipart.max-file-size只有 1MB农机照片动辄几 MB必须调大。等到照片传上去打不开再回头查基本都是这两个原因。5.4 前端打包放不进 Spring Boot如果不想分开部署前后端可以让 Spring Boot “吃掉”Vue 的打包产物把 Vue 执行npm run build得到的 dist 目录里的内容复制到src/main/resources/static下。这样访问后端端口就能直接打开前端页面省了 Nginx 和跨域问题。但要注意前端路由如果是 history 模式刷新页面时 URL 直接落到后端路由上会 404需要在后端加一个转发到index.html的 Controller或者前端换成 hash 模式。我实际测试下来毕设场景直接用 hash 模式最省心。5.5 高频问题排查速查表问题现象可能原因解决办法页面显示 404但接口能通前端 history 路由未配置兜底加视图转发或改用 hash 模式并发下单出现重复预约分布式锁未生效或锁粒度太大检查锁 key 是否包含日期检查释放时机定时任务不执行忘记EnableScheduling启动类加注解上传图片后页面显示不了静态资源映射没配注册 WebMvcConfigurer 映射虚拟路径更新操作把字段改成 null实体全字段更新使用 updateById 或加字段更新策略注解写在最后如果让我重新做一遍这个项目我会在几个地方提前下功夫一是把支付模块抽象成独立的策略接口微信、支付宝、余额三种渠道一开始就留好扩展位而不是先写死一种再回头改二是给农机检索加上地理位置附近的筛选条件农机的运输成本很高距离往往是农户决策的第一要素三是日志体系从一开始就规范化每个状态变更都带 traceId不然线上查订单问题的时候会非常痛苦。我在实际做这个项目时最深的一个体会是这种业务系统真正的难点不在某个技术点的源码而在于把所有业务流程的边界条件都想清楚——谁能操作、什么状态能操作、失败了怎么办。把这些问题列出来逐个攻破Spring Boot 本身反而只是工具。希望这篇东西能帮你少踩几个坑更希望你顺着自己的业务场景把这套骨架改造成真正属于自己的作品。