有一个念头在我脑子里转了挺久同样是做毕业设计为什么有人交上去的东西能直接放进简历项目栏有人交上去的却一眼就是“课设管理系统”区别不在于用了多花哨的技术而在于选题本身承不承载真实业务逻辑。植物租赁服务系统这个题目就是我筛了很久之后确定下来的——它不冷门但绝对不烂大街技术上覆盖了 Java 后端开发几乎所有的核心知识点业务上又天然包含订单、库存、配送、养护、计费这些完整闭环。这篇文章我就用这个题目作为主线从选题思路、系统设计、数据库建模、核心代码实现到部署排坑完整拆一遍我是怎么做出来的给正在做毕业设计或者想找实战项目的同学一个可复现的参考。1. 项目整体定位与技术选型思路1.1 植物租赁这个业务到底在解决什么问题植物租赁不是“买个花放到办公室里”那么简单。企业客户的真实需求是我要让办公环境有绿植但我不想承担养护成本不想管植物死了怎么办不想为了换一批植物走繁琐的采购流程。所以植物租赁公司的盈利模式是收月租费然后把植物送到客户现场定期派人上门养护植物死了直接换一盆。这个模式对系统的核心诉求就是三件事租出去的植物要知道在哪个客户那里、状态是否健康养护人员要知道今天该去哪些地方干什么事月底结算的时候每笔订单该收多少钱必须自动算清楚不能靠人工翻Excel。我当初定这个题目的时候最看重的一点就是这个业务有“生命周期”。植物从入库、上架、被租赁、配送出库、现场养护、退租回收、再入库每个环节都有状态流转每个状态流转背后都有对应的业务动作。这种天然的状态机模型比“增删改查学生信息”不知道高到哪里去了既能把技术深度展示出来又不会像“秒杀系统”那样假大空。1.2 为什么选 Java 而不是其他语言做毕业设计选题定了之后技术栈的选择其实没有太多悬念。学校课程主线就是 Java数据库课程教的也是 MySQLJava 生态里 Spring Boot 的开发效率和社区成熟度都是最适合单兵作战做完整系统的。更重要的是Java 在面试环节的考察点非常密集比如 JVM 内存模型、集合源码、并发编程、Spring 容器生命周期、MyBatis 插件机制这些知识点在做毕业设计的过程中都会真实遇到而不是靠背八股文硬记。我用的是 Spring Boot 2.7.x MyBatis Plus MySQL 8.0 Redis Vue 3 这套组合。Spring Boot 负责业务接口和事务控制MyBatis Plus 减少单表 CRUD 的重复代码Redis 用来处理植物详情缓存和租赁热度的统计前端用 Vue 3 Element Plus 搭管理后台小程序端用 uni-app 做用户侧的租赁入口。这套组合的好处是每一层技术都有明确的应用场景不是为用而用。1.3 系统功能模块的整体划分整个系统按角色拆成三个端每个端的核心职责完全不同。用户端小程序解决的是“我想租什么、怎么付钱、什么时候送到”的问题企业管理端解决的是“我有哪些植物、谁在租、谁该养护、谁还没付款”的问题平台运营后台解决的是“整体运转得怎么样、哪些植物租得好、哪些地区送得慢”的问题。三个端加起来我梳理出六个核心业务模块植物档案与库存管理、租赁合同与订单管理、配送任务管理、养护工单管理、财务结算中心、数据统计看板。每个模块都不是独立的代码堆砌而是通过订单这条主线串在一起。比如一条完整的订单链路长这样用户在用户端浏览植物档案看到库存余量并下单系统生成租赁订单运营人员在后台审核并指派配送任务配送员接单出库到达客户现场扫码核销确认签收后订单进入租赁中状态养护工单开始按周期自动生成退租时生成回收任务最后财务系统根据订单的起止时间和套餐价格计算应收金额。功能列表我用一张表整理出来这样不管是写开题报告还是做项目答辩都能一眼讲清楚系统的边界模块功能点说明植物档案品种管理、植物档案、图片上传维护植物基础信息和养护参数库存管理仓库管理、入库单、出库单、库存盘点记录每株植物的当前位置和状态订单中心租赁下单、订单审核、合同管理、续租/退租订单是整条业务链路的核心配送管理配送任务、路线规划、司机接单、签收确认串联仓库和客户现场的环节养护管理养护计划、工单生成、养护打卡、死株替换周期性任务自动生成自动提醒财务结算套餐定价、账单生成、收款记录、应收报表月底一键生成应收账单数据看板租赁排行、库存周转、客户留存、收入趋势用图表展示运营关键指标实际开发的时候我是按“底层基础数据 - 核心交易链路 - 后续增值服务”的顺序推进的每天保持一个稳定节奏而不是因为系统太大而无从下手。2. 数据库设计与核心数据模型2.1 从业务反推表结构而不是从 CRUD 往业务上靠很多同学做毕设的时候习惯先建表然后看表上能做哪些操作。这种方式做出来的系统功能列表写得再全业务逻辑也是七零八落的。我的做法正好反过来先把核心业务流程捋清楚再去看这些流程的每一步需要哪些数据来支撑。比如“租赁订单”这个核心概念往下拆它需要关联客户数据谁租的、地址数据送到哪里、植物品种数据租了什么、库存数据从哪棵具体的植物出库、计费数据怎么算钱、合同数据权益和责任边界。所以订单表设计出来字段特别多但并不乱。植物库存表要精确到“每一株植物”而不是“某个品种有多少棵”这个细节很重要。因为植物是个性化的不同批次买进来的植物大小、状态、品相可能不一样客户在后台看的虽然是“富贵竹10元/月”但实际出库的时候必须知道发走的究竟是哪一棵。数据库表我总共设计了20张左右核心的几张稍微展开说。用户表存客户的基本信息同时用一个 customer_type 字段区分个人客户和企业客户因为企业客户往往有信用账期个人客户基本是预付制结算逻辑不一样。植物品种表存植物的养护属性比如光照需求、浇水周期、适宜温度这些数据除了在前端展示更重要的是生成养护工单的时候要用。租赁订单主表是整个系统的核心数据表字段设计上我做了几点权衡。订单状态用字符串存而不是用数字存虽然多占一点空间但可读性和可维护性高很多排查问题的时候直接看数据库就知道这单走到哪一步了。金额字段用 decimal(10,2) 而不是 float避免浮点运算误差——这在财务场景是不可接受的。订单创建时间、支付时间、发货时间、签收时间分别用独立字段记录而不是只留一个下单时间因为每个时间节点都可能作为计费依据。计费策略这块我把“首次配送费”和“每月养护费”拆开算前者在订单创建时一次性计入后者按月度结算这样月底对账的时候不容易出错。2.2 库存与订单之间的状态一致性保证库存问题和租赁问题耦合在一起是这个系统设计上的一个难点。普通电商系统的库存扣减是“购买后减少”但租赁系统里植物出库之后仍然归属于公司只是地理位置上跑到了客户现场退租之后还要回收重新入库。所以库存表里我专门设计了一个 location_status 字段取值范围包括“在库”、“在途”、“租赁中”、“养护中”四种状态。发货操作不是把库存记录删掉而是把它从一个仓库移到一个订单下面同时修改状态。这个设计的优势体现在很多细节里。比如客户退租的时候系统可以自动生成一条“待回收”的入库单植物运回仓库后管理员做一次质检健康的直接转入“在库可用”状态不佳的标记“待养护”。再比如财务算折旧的时候可以根据这个状态字段统计公司名下所有植物资产分布在哪些环节。为了处理并发下单的库存超卖问题我用了 Redis 做植物的可租库存预扣下单时先扣减 Redis 中的余量支付成功后回写数据库库存快照超时未支付则回补库存。这里有一个比较绕但很关键的点植物租赁的“库存”系统会分成两个维度一个维度是可租植物的总数量另一个维度是某一具体植物的在库状态两者通过 dispatcher 任务来协同实际上保证了客户看到的余量和仓库里的实际可调拨量保持同步。2.3 一张完整的核心表结构参考挑订单主表和库存明细表把 DDL 列出来这样能看到字段类型的设计思路后面写代码也才知道字段到底该怎么用。这里给的是精简版实际做答辩的时候展示局部设计重点把字段含义和设计理由讲清楚。CREATE TABLE biz_lease_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, customer_id BIGINT NOT NULL COMMENT 客户ID, contract_no VARCHAR(32) COMMENT 关联合同编号, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, delivery_fee DECIMAL(10,2) DEFAULT 0.00 COMMENT 首次配送费, monthly_rent DECIMAL(10,2) NOT NULL COMMENT 月租金, deposit_amount DECIMAL(10,2) DEFAULT 0.00 COMMENT 押金, lease_start_date DATE COMMENT 租期开始日, lease_end_date DATE COMMENT 租期结束日, order_status VARCHAR(20) NOT NULL COMMENT 订单状态, payment_status VARCHAR(20) NOT NULL COMMENT 支付状态, address_detail VARCHAR(255) COMMENT 配送地址, contact_name VARCHAR(50) COMMENT 联系人, contact_phone VARCHAR(20) COMMENT 联系电话, review_user_id BIGINT COMMENT 审核人ID, delivery_task_id BIGINT COMMENT 关联配送任务ID, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, updated_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_customer (customer_id), KEY idx_status (order_status), KEY idx_created_time (created_time) ) ENGINEInnoDB COMMENT租赁订单主表;CREATE TABLE biz_plant_inventory ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 库存记录ID, plant_code VARCHAR(32) NOT NULL UNIQUE COMMENT 植物唯一编码, variety_id BIGINT NOT NULL COMMENT 品种ID, warehouse_id BIGINT COMMENT 所在仓库ID, location_status VARCHAR(20) NOT NULL COMMENT 在库/在途/租赁中/养护中, current_order_id BIGINT COMMENT 当前所属订单ID, purchase_price DECIMAL(10,2) COMMENT 采购成本价, health_status VARCHAR(20) COMMENT 健康状态, purchase_date DATE COMMENT 入库日期, last_maintain_time DATETIME COMMENT 上次养护时间, remark VARCHAR(255), KEY idx_variety (variety_id), KEY idx_location_status (location_status) ) ENGINEInnoDB COMMENT植物库存明细表;两个表之间的关联关系是订单表和库存表通过 current_order_id 建立运行时关联不是通过外键强绑定因为植物在订单之间流转时顺序是“退租回收 - 重新质检 - 再上架”中间有状态跃迁外键反而不好管理。开发的时候我全程手动维护这个关系靠的是状态机引擎里对每一步前置状态的校验比如只有 location_status在库 的植物才能被分配到新订单上。3. 核心业务流程与关键代码实现解析3.1 订单状态机的设计与实现租赁订单的状态流转比普通电商订单复杂因为中间有审核环节、配送环节、租期中环节、续租/退租分支。我一开始用一堆 if/else 去判断状态能否流转改到第三次就发现每次新增一个状态都要动原来的代码特别容易被自己绕晕。后来重构成了状态机模式虽然代码量多了一点但每个状态的流转逻辑都收敛在各自的类里排查问题的时候按状态找代码非常舒服。订单状态我最终定义了七种待审核、待支付、待发货、租赁中、已退租、已完成、已取消。流转规则是这样的下单后进入待审核因为企业租赁需要后台人工确认资质和押金审核通过后进入待支付24小时内未支付系统自动关单支付成功进入待发货等待配送任务绑定签收后进入租赁中合同周期开始计算客户发起退租并归还植物后进入已退租财务确认无欠费、植物无破损后订单进入已完成任何环节取消则进入已取消。用策略模式处理状态流转核心代码是维护一张状态流转配置表校验合法流转然后执行动作Component public class LeaseOrderStateMachine { private static final MapOrderStatus, SetOrderStatus TRANSITION_MAP new HashMap(); static { TRANSITION_MAP.put(OrderStatus.PENDING_REVIEW, EnumSet.of(OrderStatus.PENDING_PAYMENT, OrderStatus.CANCELLED)); TRANSITION_MAP.put(OrderStatus.PENDING_PAYMENT, EnumSet.of(OrderStatus.PENDING_DELIVERY, OrderStatus.CANCELLED)); TRANSITION_MAP.put(OrderStatus.PENDING_DELIVERY, EnumSet.of(OrderStatus.LEASING)); TRANSITION_MAP.put(OrderStatus.LEASING, EnumSet.of(OrderStatus.RETURNED)); TRANSITION_MAP.put(OrderStatus.RETURNED, EnumSet.of(OrderStatus.COMPLETED, OrderStatus.LEASING)); } public void transition(LeaseOrder order, OrderStatus targetStatus) { OrderStatus currentStatus order.getOrderStatus(); SetOrderStatus allowedTargets TRANSITION_MAP.get(currentStatus); if (allowedTargets null || !allowedTargets.contains(targetStatus)) { throw new BizException(非法的订单状态流转: currentStatus - targetStatus); } // 执行流转前后的业务动作 order.setOrderStatus(targetStatus); } }这个写的还只是最基础的版本实际项目里我加了一个 StatusHandler 接口每个状态对应一个 Handler在流转时调用对应的前置校验方法。这样做的好处是以后如果想加“暂停租赁”或者“订单转赠”这类新状态不用改动已有的流转逻辑只要加一个新的枚举和 Handler 就行。答辩的时候能讲出这个设计思路比甩一堆 CRUD 代码有说服力得多。3.2 租赁价格计算不要小看这几行公式价格计算是这个系统我自认为设计得比较清楚的一部分。植物租赁的计费逻辑表面上很简单“月租金乘租期月数”但落到实际业务里会有很多细节首月如何计算、不满一个月的按日折算还是按整月收取、续租是否有折扣、提前退租是否要收违约金、配送费是首次收取还是每次更换植物都收取。我的方案是把计算规则全部收敛到一个 PriceCalculator 类里所有涉及金额的地方统一走这个类不在业务代码里散落加减乘除。金额计算统一用 BigDecimal避免 float 和 double 带来的精度问题。租期计价这块按自然月为单位不满一个月的按“月租金除以当月天数乘以实际天数”折算成日租金。折算公式虽然多一步除法但客户不会因为这点差异来扯皮反而觉得系统算得公平。Component public class PriceCalculator { /** * 计算一笔租赁订单的总金额 */ public BigDecimal calcTotalAmount(LeaseOrderDTO dto) { BigDecimal monthlyRent dto.getMonthlyRent(); // 计算租期月数不满一个月的按日折算 BigDecimal leaseMonths calcLeaseMonths(dto.getLeaseStartDate(), dto.getLeaseEndDate()); // 基础租金 月租 x 租期月数 BigDecimal totalRent monthlyRent.multiply(leaseMonths); // 打折规则租期达到3个月打95折6个月打9折12个月打85折 BigDecimal discount DiscountRule.match(leaseMonths.intValue()).getRate(); BigDecimal totalAmount totalRent.multiply(discount); // 加上首次配送费如果是续租订单则免配送费 if (!dto.getRenewalFlag()) { totalAmount totalAmount.add(dto.getDeliveryFee()); } // 加上押金 totalAmount totalAmount.add(dto.getDepositAmount()); return totalAmount.setScale(2, RoundingMode.HALF_UP); } }这里 DiscountRule 是一个枚举类用来匹配租期长短对应的折扣率。之所以把折扣率提取成枚举而不是写死 if 判断是因为后期运营一定会在后台配置不同的促销策略枚举形态比散落的 if 好维护。再说回实际开发中容易踩的坑BigDecimal 的 divide 运算必须指定精度和舍入模式否则除不尽的时候会抛 ArithmeticException这个坑我初学的时候踩过代码里用了保留四位小数后四舍五入把精度误差控制在货币体系的合理范围内。3.3 配送任务与路径规划的实现配送是整个系统里最容易出 bug 的模块因为它的数据模型跨了订单、库存、配送员、仓库好几个对象。我的实现思路是后台管理员把一批同区域的待发货订单打包成一个配送任务任务创建后系统按照仓库位置和客户位置的经纬度用贪心最近邻算法对客户点做排序然后把排序结果返回给小程序端展示司机可以按顺序跑。路径规划这块我本来想引入第三方地图 API但毕设项目不要求那么重而且把 API 申请流程写进文档反而增加了答辩负担。所以我用了一个数学上足够简单的方案从仓库点出发每次在未访问客户点里找离当前点最近的一个依次串联成路线。代码本身不复杂核心约 30 行但配合 Google 的 S2 库把经纬度转成球面距离计算量小效果也不错。public ListLong planDeliveryRoute(Long warehouseId, ListLong orderIds) { ListDeliveryPoint points buildPoints(warehouseId, orderIds); // 起点是仓库 DeliveryPoint current getWarehousePoint(points); ListLong route new ArrayList(); SetLong visited new HashSet(); while (visited.size() orderIds.size()) { DeliveryPoint nearest null; double minDist Double.MAX_VALUE; for (DeliveryPoint point : points) { if (visited.contains(point.getOrderId())) { continue; } double dist distance(current.getLatitude(), current.getLongitude(), point.getLatitude(), point.getLongitude()); if (dist minDist) { minDist dist; nearest point; } } visited.add(nearest.getOrderId()); route.add(nearest.getOrderId()); current nearest; } return route; }真实跑下来这个算法在 10 个客户点以内的效果已经很理想了计算时间几乎是瞬时完成路线合理性也在可接受范围。如果是 30 个点以上贪心算法可能会出现局部绕路的情况但毕设的场景根本触达不到那个量级商业系统才会需要真正的车辆路径规划求解器。3.4 养护工单自动生成定时任务怎么设计养护是植物租赁系统区别于其他租赁系统的核心差异点。植物不是死物它需要定期浇水、修剪、施肥、查看病虫害。不同品种的养护周期不一样有的三天一次有的一周一次。另外还有一个隐性业务规则客户可以额外购买“深度养护”服务加了这项服务的植物在基础养护频率上翻倍。我用 xxl-job 的调度框架实现了一个定时任务每天凌晨两点扫描所有处于‘租赁中’状态的植物库存记录根据植物品种的养护周期计算出下一次养护日期如果该日期落在未来三天内且当前日期还不存在未完成养护工单就自动生成一条新工单。工单生成后通过 WebSocket 推送给对应的养护师傅。核心是在查询这一层用了联表 SQL 加日期条件筛选避免一次性把全部数据加载到内存里遍历SELECT i.id, i.plant_code, i.current_order_id, v.maintain_cycle_days, o.address_detail, o.contact_name, o.contact_phone FROM biz_plant_inventory i JOIN biz_plant_variety v ON i.variety_id v.id JOIN biz_lease_order o ON i.current_order_id o.id WHERE i.location_status 租赁中 AND o.order_status 租赁中 AND ( SELECT COUNT(*) FROM biz_maintenance_record m WHERE m.inventory_id i.id AND m.is_completed 1 AND m.planned_date CURDATE() ) 0 AND DATE_ADD( (SELECT MAX(planned_date) FROM biz_maintenance_record r WHERE r.inventory_id i.id AND r.is_completed 1), INTERVAL v.maintain_cycle_days DAY ) DATE_ADD(CURDATE(), INTERVAL 3 DAY);这个 SQL 里最关键的子查询是“找出每个植物距离上次已完成养护的间隔是否达到标准周期”。一开始我写的版本效率很差因为每天扫描一次全量数据索引也用不上。后来改成在养护记录表上加联合索引 (inventory_id, is_completed, planned_date)查询时间降了一个数量级。这种优化经验写在文档里是实打实的加分项。3.5 前端页面与技术集成要点前端我用 Vue 3 的 Composition API 写了管理后台页面不算复杂但有几个点值得说。一是整个后台的菜单权限按角色动态渲染从后端接口拉取当前用户的权限列表前端用 v-if 控制路由和按钮的显隐。二是图表统计用的是 Apache ECharts直接从后端返回统计维度数据前端做一次维度映射就可以渲染不额外引入重型的数据处理框架。三是上传植物图片阶段用了分片上传的思维不是真实的分片而是先把图片压缩到 500KB 以内再传避免服务器负载压力。用户端小程序用 uni-app 开发一套代码能同时编译到微信小程序和 H5。下单流程比较顺滑首页展示植物列表点击进入详情选择租期确认地址预览价格明细拉起微信支付。支付回调这里有个关键细节微信支付成功回调可能重复发送系统必须在回调处理接口里做幂等控制。我的做法是回调处理逻辑的首行先按支付流水号查数据库如果这条流水已经更新过状态直接返回成功不再执行后续业务动作。这个细节非常考验工程意识面试官大概率会问。4. Redis 缓存、并发控制与性能优化实战4.1 热点数据缓存策略植物详情页是整个系统访问量最大的接口因为用户打开小程序第一眼看到的就是植物列表点进去是详情。如果每个请求都直接查数据库数据库压力会非常大。我的方案是分两级缓存植物列表页用 Redis 缓存热门品种数据过期时间设置为五分钟五分钟内的请求直接打缓存植物详情页缓存单条数据过期时间按品种的更新频率来定。核心思想是根据数据更新频率和使用热度平衡缓存时间和数据库一致性。public ListPlantVarietyVO getHotVarietyList() { String cacheKey RedisKey.HOT_VARIETY_LIST; String cachedJson redisTemplate.opsForValue().get(cacheKey); if (StringUtils.isNotBlank(cachedJson)) { return JSON.parseArray(cachedJson, PlantVarietyVO.class); } ListPlantVarietyVO list plantVarietyMapper.selectHotList(); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(list), 5, TimeUnit.MINUTES); return list; }缓存更新策略我用的是旁路缓存模式读操作先读缓存读不到再读数据库并回填写操作先更新数据库再主动删除缓存而不是更新缓存。这样实现简单并发环境下不容易出现数据不一致。库存余量这种数据变化频繁且实时性要求高不走 Redis 缓存直接查数据库并配合乐观锁控制。4.2 超卖问题的乐观锁解决方案库存超卖是并发控制里的经典问题。植物租赁虽然不像秒杀那样瞬间爆发但高峰期同时有几个客户抢同一品种的植物时如果没有并发控制就会出现两个订单扣减了同一棵植物的库存。我的解决思路是乐观锁加唯一索引双保险。数据库层面对植物库存表的 current_order_id 字段加了唯一索引同一时间一棵植物只能被绑定到一个订单代码层面通过版本号控制更新条件更新时检查当前版本号是否和查询时一致Update(UPDATE biz_plant_inventory SET location_status在途, current_order_id#{orderId}, versionversion1 WHERE id#{inventoryId} AND version#{version} AND location_status在库) int tryOccupyInventory(Param(inventoryId) Long inventoryId, Param(orderId) Long orderId, Param(version) Integer version);返回结果大于 0 表示抢占成功等于 0 说明这棵植物的状态已经发生变化需要换一棵或者提示客户库存不足。这个方案在并发度不高的情况下体验很好用户感知不到锁的存在。如果未来并发量上去了再改成 Redis 分布式锁也不难只是毕设阶段没必要把系统搞重。4.3 索引优化与慢查询排查数据库性能优化这块我踩了不少坑也总结出了一些实际经验。页面上有一个“客户租赁历史”查询输入客户手机号查订单列表结果数据量一涨就变得很慢。我 explain 一看发现订单表上的 customer_id 索引已经建了但因为查询条件里还带了 order_status 的过滤MySQL 在数据量大时选择了全表扫描而不是索引下推。最后通过把 (customer_id, order_status, created_time) 建成联合索引解决。这个优化思路比较典型单列索引在 and 条件多的时候往往失效或者效率低联合索引能匹配更精确的查询路径。另外我还养成了一个习惯所有列表查询接口都必须做分页坚决不允许一次把全部数据返回给前端植物库存列表、订单列表、养护记录列表都是如此。分页本身不复杂用 MyBatis Plus 的 Page 对象一行代码就能搞定但能把这件事坚持做到所有列表接口体现的是工程意识。5. 常见问题排查与避坑指南5.1 状态不对账财务结算数据对不上我第一次把财务模块写完之后找同事帮忙测试。同事模拟了一个客户租了三个月植物中途提前退租结果财务模块算出来的应收金额和手工算的对不上。排查到最后发现是状态机里少了一条流转链订单从“租赁中”可以直接跳到“已退租”但退租逻辑里没去算违约金导致应退金额和实际退款之间差了半天的罚款。这类问题已经超出单纯编程的范畴本质是业务规则没有完全数字化。我的解决方案一个是把状态机和业务动作绑定任何流程流转必须走 Service 层的方法不允许直接把状态字段 set 后调 update 更新这样每个状态变更的前置和后置动作都不容易漏另一个是在财务模块增加了手工调账单功能运营遇到数据不一致时可以在后台做校正既保证了数据的最终一致也保留了运营的灵活性。5.2 微信支付回调重复导致重复发券支付的幂等性问题再展开一次因为太典型了。微信支付回调是异步的可能因为网络原因间隔几秒重试多次如果回调处理函数不是幂等的就会造成同一笔订单被处理两次。我一开始没写幂等判断测试时发现客户支付成功后账户里多了两条充值记录一下子就慌了。后面在回调入口处加了一个基于唯一业务号的防重判断具体做法是独立一张支付流水表表里对 transaction_id 加了唯一索引插入成功才继续更新订单状态插入失败就说明这条回调已经处理过了直接返回成功。这个方法能彻底避免并发场景下同时收到两次回调的竞态问题。另外凡是涉及金额变动的地方都加上了审计日志保留完整的操作痕迹万一出问题可以回溯操作记录。5.3 MyBatis Plus 的坑与解决MyBatis Plus 用起来确实省时间但有几个隐藏地对新手不友好的地方。字段映射驼峰转下划线默认是开启的但如果你在实体类里用了 resultMap 自己配置映射驼峰转换可能会失效这就导致查询出来的某些字段是 null。排查方式是打开 MyBatis 的 SQL 日志输出先确认 SQL 语句本身有没有查这些字段再确认映射关系。另一个常见的坑是 MyBatis Plus 的 update 方法默认只更新非空字段也就是说如果你想把某个字段更新成 null直接调默认 updateById 是不生效的。解决办法是在实体字段上加上 TableField(updateStrategy FieldStrategy.IGNORED) 注解或者手写一个 UpdateWrapper 手动 set 对应字段。这个细节如果不知道排查起来会非常浪费时间。5.4 Lombok 与编译环境的兼容性问题Lombok 在本地编译正常但打包部署到服务器上报 java.lang.ExceptionInInitializerError这个现象遇到过的人不在少数。原因一般是 JDK 版本与 Lombok 版本不兼容Lombok 旧版本对 JDK 9 的支持有 bug。解决方法是把 Lombok 升级到适配当前 JDK 版本的版本比如 JDK 17 对应 Lombok 1.18.30 以上。另外一个野路子是检查项目里是否引入了多个 Lombok 版本依赖冲突也会导致类似的编译异常。开发工具这块我建议用 IDEA 并装好 Lombok 插件Eclipse 环境对 Lombok 的支持比较麻烦配置不到位很容易出现开了注解但 getter/setter 生成不了的问题。新手如果不想在这一步卡太久也可以先不用 Lombok老老实实手动生成 getter/setter这是最稳的方式。6. 部署上线从本地开发到服务器运行6.1 环境准备与打包构建部署这块其实是很多同学容易忽略但实际面试高频考察的部分。我的部署架构是单台服务器Nginx 做反向代理和静态资源服务后端 Jar 包通过 systemd 守护进程托管MySQL 和 Redis 分别用 Docker 容器部署方便管理。服务器配置选了 2核4G 的入门级云主机这个配置跑这套系统绰绰有余。打包之前有几件事必须确认。数据库连接配置要改成服务器的内网地址如果是通过公网访问要注意安全组放行相应端口MySQL 密码不要硬编码写在 application.yml 里优先用环境变量注入Redis 要配置访问密码不能裸奔在公网环境下。这些都是最基本的线上安全意识。# 前端构建 npm run build # 后端打包跳过测试 mvn clean package -DskipTests # 上传到服务器后启动 nohup java -Xms512m -Xmx512m -jar plant-lease-server.jar \ --spring.profiles.activeprod \ --DB_HOST127.0.0.1 \ --DB_PORT3306 \ --REDIS_HOST127.0.0.1 /app/logs/app.log 21 6.2 systemd 配置服务守护用 nohup 启动进程有一个问题服务器重启或者进程意外退出应用不会自动拉起来。我用 systemd 写了一个服务配置文件实现开机自启和崩溃自动重启[Unit] DescriptionPlant Lease Server Afternetwork.target mysql.service redis.service [Service] Typesimple Userapp WorkingDirectory/app/plant-lease EnvironmentFile/app/plant-lease/.env ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /app/plant-lease/plant-lease-server.jar Restartalways RestartSec5 StandardOutputappend:/app/logs/app.log StandardErrorappend:/app/logs/app-error.log [Install] WantedBymulti-user.target配置亮点在于使用 EnvironmentFile 管理数据库密码等敏感信息服务重启不会暴露在进程列表里。再用 Nginx 把 80 端口的 HTTP 流量反向代理到 Spring Boot 的 8080 端口同时托管前端静态页面。这样整套系统就完成了一个生产环境的最小闭环。6.3 线上问题定位的三个实用工具线上环境和本地开发最大的区别是排查问题的手段受限。我常用的三个工具组合是看日志、看线程、看数据库。日志这块logback 配置里给不同包设置了不同的日志级别关键业务包用 DEBUG框架包用 INFO避免线上日志量过大。线程排查主要用 jstack 导出线程快照看是否有死锁或者长时间的阻塞特别是各 Service 层加锁的地方容易出问题。数据库这块就是定位慢 SQL开启 MySQL 的慢查询日志把执行时间超过1秒的 SQL 记录下来再逐一优化。这三个工具组合虽然传统但确实能解决 95% 以上的线上问题。毕设答辩谈到部署运维经验时能说出清楚这三个工具的用途和适用场景就已经超过绝大多数同龄人了。7. 写在最后的几点经验心得整套系统从设计到上线前后花了六周左右。前两周在梳理业务和搭建框架中间三周在写核心业务代码最后一周在做性能优化和部署。最大的体会是毕业设计不是把技术名词堆上去就完事真正重要的是系统能不能跑通一条完整的业务链路。植物租赁这个题目让我每个模块都不是空中楼阁。比如状态机、乐观锁、定时任务、消息推送、支付回调防重这些知识点全部都有对应的真实场景而不是为了写而写。另外还有一点比较实用的小经验开发过程中不管时间多紧都要保持编写接口文档的习惯哪怕只是简单地记录请求参数和返回结构。因为后期调试、联调、答辩、扩展功能都会频繁用到这份文档它对整个项目的推进和展示都有很大帮助。如果时间充裕建议提前为每个接口准备好测试用例能极大提升联调和演示环节的流畅程度。这个系统后续如果想继续做得更深入方向其实很多。比如加入 IoT 传感器的植物状态监控、基于历史订单数据的客户流失预警、更精准的车辆路径规划算法等等。但那些都是后话先把基础打扎实这套完整项目经验足够支撑一段高质量的面试自我介绍了。 Java后端实战：植物租赁服务系统设计与实现全解析
有一个念头在我脑子里转了挺久同样是做毕业设计为什么有人交上去的东西能直接放进简历项目栏有人交上去的却一眼就是“课设管理系统”区别不在于用了多花哨的技术而在于选题本身承不承载真实业务逻辑。植物租赁服务系统这个题目就是我筛了很久之后确定下来的——它不冷门但绝对不烂大街技术上覆盖了 Java 后端开发几乎所有的核心知识点业务上又天然包含订单、库存、配送、养护、计费这些完整闭环。这篇文章我就用这个题目作为主线从选题思路、系统设计、数据库建模、核心代码实现到部署排坑完整拆一遍我是怎么做出来的给正在做毕业设计或者想找实战项目的同学一个可复现的参考。1. 项目整体定位与技术选型思路1.1 植物租赁这个业务到底在解决什么问题植物租赁不是“买个花放到办公室里”那么简单。企业客户的真实需求是我要让办公环境有绿植但我不想承担养护成本不想管植物死了怎么办不想为了换一批植物走繁琐的采购流程。所以植物租赁公司的盈利模式是收月租费然后把植物送到客户现场定期派人上门养护植物死了直接换一盆。这个模式对系统的核心诉求就是三件事租出去的植物要知道在哪个客户那里、状态是否健康养护人员要知道今天该去哪些地方干什么事月底结算的时候每笔订单该收多少钱必须自动算清楚不能靠人工翻Excel。我当初定这个题目的时候最看重的一点就是这个业务有“生命周期”。植物从入库、上架、被租赁、配送出库、现场养护、退租回收、再入库每个环节都有状态流转每个状态流转背后都有对应的业务动作。这种天然的状态机模型比“增删改查学生信息”不知道高到哪里去了既能把技术深度展示出来又不会像“秒杀系统”那样假大空。1.2 为什么选 Java 而不是其他语言做毕业设计选题定了之后技术栈的选择其实没有太多悬念。学校课程主线就是 Java数据库课程教的也是 MySQLJava 生态里 Spring Boot 的开发效率和社区成熟度都是最适合单兵作战做完整系统的。更重要的是Java 在面试环节的考察点非常密集比如 JVM 内存模型、集合源码、并发编程、Spring 容器生命周期、MyBatis 插件机制这些知识点在做毕业设计的过程中都会真实遇到而不是靠背八股文硬记。我用的是 Spring Boot 2.7.x MyBatis Plus MySQL 8.0 Redis Vue 3 这套组合。Spring Boot 负责业务接口和事务控制MyBatis Plus 减少单表 CRUD 的重复代码Redis 用来处理植物详情缓存和租赁热度的统计前端用 Vue 3 Element Plus 搭管理后台小程序端用 uni-app 做用户侧的租赁入口。这套组合的好处是每一层技术都有明确的应用场景不是为用而用。1.3 系统功能模块的整体划分整个系统按角色拆成三个端每个端的核心职责完全不同。用户端小程序解决的是“我想租什么、怎么付钱、什么时候送到”的问题企业管理端解决的是“我有哪些植物、谁在租、谁该养护、谁还没付款”的问题平台运营后台解决的是“整体运转得怎么样、哪些植物租得好、哪些地区送得慢”的问题。三个端加起来我梳理出六个核心业务模块植物档案与库存管理、租赁合同与订单管理、配送任务管理、养护工单管理、财务结算中心、数据统计看板。每个模块都不是独立的代码堆砌而是通过订单这条主线串在一起。比如一条完整的订单链路长这样用户在用户端浏览植物档案看到库存余量并下单系统生成租赁订单运营人员在后台审核并指派配送任务配送员接单出库到达客户现场扫码核销确认签收后订单进入租赁中状态养护工单开始按周期自动生成退租时生成回收任务最后财务系统根据订单的起止时间和套餐价格计算应收金额。功能列表我用一张表整理出来这样不管是写开题报告还是做项目答辩都能一眼讲清楚系统的边界模块功能点说明植物档案品种管理、植物档案、图片上传维护植物基础信息和养护参数库存管理仓库管理、入库单、出库单、库存盘点记录每株植物的当前位置和状态订单中心租赁下单、订单审核、合同管理、续租/退租订单是整条业务链路的核心配送管理配送任务、路线规划、司机接单、签收确认串联仓库和客户现场的环节养护管理养护计划、工单生成、养护打卡、死株替换周期性任务自动生成自动提醒财务结算套餐定价、账单生成、收款记录、应收报表月底一键生成应收账单数据看板租赁排行、库存周转、客户留存、收入趋势用图表展示运营关键指标实际开发的时候我是按“底层基础数据 - 核心交易链路 - 后续增值服务”的顺序推进的每天保持一个稳定节奏而不是因为系统太大而无从下手。2. 数据库设计与核心数据模型2.1 从业务反推表结构而不是从 CRUD 往业务上靠很多同学做毕设的时候习惯先建表然后看表上能做哪些操作。这种方式做出来的系统功能列表写得再全业务逻辑也是七零八落的。我的做法正好反过来先把核心业务流程捋清楚再去看这些流程的每一步需要哪些数据来支撑。比如“租赁订单”这个核心概念往下拆它需要关联客户数据谁租的、地址数据送到哪里、植物品种数据租了什么、库存数据从哪棵具体的植物出库、计费数据怎么算钱、合同数据权益和责任边界。所以订单表设计出来字段特别多但并不乱。植物库存表要精确到“每一株植物”而不是“某个品种有多少棵”这个细节很重要。因为植物是个性化的不同批次买进来的植物大小、状态、品相可能不一样客户在后台看的虽然是“富贵竹10元/月”但实际出库的时候必须知道发走的究竟是哪一棵。数据库表我总共设计了20张左右核心的几张稍微展开说。用户表存客户的基本信息同时用一个 customer_type 字段区分个人客户和企业客户因为企业客户往往有信用账期个人客户基本是预付制结算逻辑不一样。植物品种表存植物的养护属性比如光照需求、浇水周期、适宜温度这些数据除了在前端展示更重要的是生成养护工单的时候要用。租赁订单主表是整个系统的核心数据表字段设计上我做了几点权衡。订单状态用字符串存而不是用数字存虽然多占一点空间但可读性和可维护性高很多排查问题的时候直接看数据库就知道这单走到哪一步了。金额字段用 decimal(10,2) 而不是 float避免浮点运算误差——这在财务场景是不可接受的。订单创建时间、支付时间、发货时间、签收时间分别用独立字段记录而不是只留一个下单时间因为每个时间节点都可能作为计费依据。计费策略这块我把“首次配送费”和“每月养护费”拆开算前者在订单创建时一次性计入后者按月度结算这样月底对账的时候不容易出错。2.2 库存与订单之间的状态一致性保证库存问题和租赁问题耦合在一起是这个系统设计上的一个难点。普通电商系统的库存扣减是“购买后减少”但租赁系统里植物出库之后仍然归属于公司只是地理位置上跑到了客户现场退租之后还要回收重新入库。所以库存表里我专门设计了一个 location_status 字段取值范围包括“在库”、“在途”、“租赁中”、“养护中”四种状态。发货操作不是把库存记录删掉而是把它从一个仓库移到一个订单下面同时修改状态。这个设计的优势体现在很多细节里。比如客户退租的时候系统可以自动生成一条“待回收”的入库单植物运回仓库后管理员做一次质检健康的直接转入“在库可用”状态不佳的标记“待养护”。再比如财务算折旧的时候可以根据这个状态字段统计公司名下所有植物资产分布在哪些环节。为了处理并发下单的库存超卖问题我用了 Redis 做植物的可租库存预扣下单时先扣减 Redis 中的余量支付成功后回写数据库库存快照超时未支付则回补库存。这里有一个比较绕但很关键的点植物租赁的“库存”系统会分成两个维度一个维度是可租植物的总数量另一个维度是某一具体植物的在库状态两者通过 dispatcher 任务来协同实际上保证了客户看到的余量和仓库里的实际可调拨量保持同步。2.3 一张完整的核心表结构参考挑订单主表和库存明细表把 DDL 列出来这样能看到字段类型的设计思路后面写代码也才知道字段到底该怎么用。这里给的是精简版实际做答辩的时候展示局部设计重点把字段含义和设计理由讲清楚。CREATE TABLE biz_lease_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 订单ID, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, customer_id BIGINT NOT NULL COMMENT 客户ID, contract_no VARCHAR(32) COMMENT 关联合同编号, total_amount DECIMAL(10,2) NOT NULL COMMENT 订单总金额, delivery_fee DECIMAL(10,2) DEFAULT 0.00 COMMENT 首次配送费, monthly_rent DECIMAL(10,2) NOT NULL COMMENT 月租金, deposit_amount DECIMAL(10,2) DEFAULT 0.00 COMMENT 押金, lease_start_date DATE COMMENT 租期开始日, lease_end_date DATE COMMENT 租期结束日, order_status VARCHAR(20) NOT NULL COMMENT 订单状态, payment_status VARCHAR(20) NOT NULL COMMENT 支付状态, address_detail VARCHAR(255) COMMENT 配送地址, contact_name VARCHAR(50) COMMENT 联系人, contact_phone VARCHAR(20) COMMENT 联系电话, review_user_id BIGINT COMMENT 审核人ID, delivery_task_id BIGINT COMMENT 关联配送任务ID, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, updated_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_customer (customer_id), KEY idx_status (order_status), KEY idx_created_time (created_time) ) ENGINEInnoDB COMMENT租赁订单主表;CREATE TABLE biz_plant_inventory ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 库存记录ID, plant_code VARCHAR(32) NOT NULL UNIQUE COMMENT 植物唯一编码, variety_id BIGINT NOT NULL COMMENT 品种ID, warehouse_id BIGINT COMMENT 所在仓库ID, location_status VARCHAR(20) NOT NULL COMMENT 在库/在途/租赁中/养护中, current_order_id BIGINT COMMENT 当前所属订单ID, purchase_price DECIMAL(10,2) COMMENT 采购成本价, health_status VARCHAR(20) COMMENT 健康状态, purchase_date DATE COMMENT 入库日期, last_maintain_time DATETIME COMMENT 上次养护时间, remark VARCHAR(255), KEY idx_variety (variety_id), KEY idx_location_status (location_status) ) ENGINEInnoDB COMMENT植物库存明细表;两个表之间的关联关系是订单表和库存表通过 current_order_id 建立运行时关联不是通过外键强绑定因为植物在订单之间流转时顺序是“退租回收 - 重新质检 - 再上架”中间有状态跃迁外键反而不好管理。开发的时候我全程手动维护这个关系靠的是状态机引擎里对每一步前置状态的校验比如只有 location_status在库 的植物才能被分配到新订单上。3. 核心业务流程与关键代码实现解析3.1 订单状态机的设计与实现租赁订单的状态流转比普通电商订单复杂因为中间有审核环节、配送环节、租期中环节、续租/退租分支。我一开始用一堆 if/else 去判断状态能否流转改到第三次就发现每次新增一个状态都要动原来的代码特别容易被自己绕晕。后来重构成了状态机模式虽然代码量多了一点但每个状态的流转逻辑都收敛在各自的类里排查问题的时候按状态找代码非常舒服。订单状态我最终定义了七种待审核、待支付、待发货、租赁中、已退租、已完成、已取消。流转规则是这样的下单后进入待审核因为企业租赁需要后台人工确认资质和押金审核通过后进入待支付24小时内未支付系统自动关单支付成功进入待发货等待配送任务绑定签收后进入租赁中合同周期开始计算客户发起退租并归还植物后进入已退租财务确认无欠费、植物无破损后订单进入已完成任何环节取消则进入已取消。用策略模式处理状态流转核心代码是维护一张状态流转配置表校验合法流转然后执行动作Component public class LeaseOrderStateMachine { private static final MapOrderStatus, SetOrderStatus TRANSITION_MAP new HashMap(); static { TRANSITION_MAP.put(OrderStatus.PENDING_REVIEW, EnumSet.of(OrderStatus.PENDING_PAYMENT, OrderStatus.CANCELLED)); TRANSITION_MAP.put(OrderStatus.PENDING_PAYMENT, EnumSet.of(OrderStatus.PENDING_DELIVERY, OrderStatus.CANCELLED)); TRANSITION_MAP.put(OrderStatus.PENDING_DELIVERY, EnumSet.of(OrderStatus.LEASING)); TRANSITION_MAP.put(OrderStatus.LEASING, EnumSet.of(OrderStatus.RETURNED)); TRANSITION_MAP.put(OrderStatus.RETURNED, EnumSet.of(OrderStatus.COMPLETED, OrderStatus.LEASING)); } public void transition(LeaseOrder order, OrderStatus targetStatus) { OrderStatus currentStatus order.getOrderStatus(); SetOrderStatus allowedTargets TRANSITION_MAP.get(currentStatus); if (allowedTargets null || !allowedTargets.contains(targetStatus)) { throw new BizException(非法的订单状态流转: currentStatus - targetStatus); } // 执行流转前后的业务动作 order.setOrderStatus(targetStatus); } }这个写的还只是最基础的版本实际项目里我加了一个 StatusHandler 接口每个状态对应一个 Handler在流转时调用对应的前置校验方法。这样做的好处是以后如果想加“暂停租赁”或者“订单转赠”这类新状态不用改动已有的流转逻辑只要加一个新的枚举和 Handler 就行。答辩的时候能讲出这个设计思路比甩一堆 CRUD 代码有说服力得多。3.2 租赁价格计算不要小看这几行公式价格计算是这个系统我自认为设计得比较清楚的一部分。植物租赁的计费逻辑表面上很简单“月租金乘租期月数”但落到实际业务里会有很多细节首月如何计算、不满一个月的按日折算还是按整月收取、续租是否有折扣、提前退租是否要收违约金、配送费是首次收取还是每次更换植物都收取。我的方案是把计算规则全部收敛到一个 PriceCalculator 类里所有涉及金额的地方统一走这个类不在业务代码里散落加减乘除。金额计算统一用 BigDecimal避免 float 和 double 带来的精度问题。租期计价这块按自然月为单位不满一个月的按“月租金除以当月天数乘以实际天数”折算成日租金。折算公式虽然多一步除法但客户不会因为这点差异来扯皮反而觉得系统算得公平。Component public class PriceCalculator { /** * 计算一笔租赁订单的总金额 */ public BigDecimal calcTotalAmount(LeaseOrderDTO dto) { BigDecimal monthlyRent dto.getMonthlyRent(); // 计算租期月数不满一个月的按日折算 BigDecimal leaseMonths calcLeaseMonths(dto.getLeaseStartDate(), dto.getLeaseEndDate()); // 基础租金 月租 x 租期月数 BigDecimal totalRent monthlyRent.multiply(leaseMonths); // 打折规则租期达到3个月打95折6个月打9折12个月打85折 BigDecimal discount DiscountRule.match(leaseMonths.intValue()).getRate(); BigDecimal totalAmount totalRent.multiply(discount); // 加上首次配送费如果是续租订单则免配送费 if (!dto.getRenewalFlag()) { totalAmount totalAmount.add(dto.getDeliveryFee()); } // 加上押金 totalAmount totalAmount.add(dto.getDepositAmount()); return totalAmount.setScale(2, RoundingMode.HALF_UP); } }这里 DiscountRule 是一个枚举类用来匹配租期长短对应的折扣率。之所以把折扣率提取成枚举而不是写死 if 判断是因为后期运营一定会在后台配置不同的促销策略枚举形态比散落的 if 好维护。再说回实际开发中容易踩的坑BigDecimal 的 divide 运算必须指定精度和舍入模式否则除不尽的时候会抛 ArithmeticException这个坑我初学的时候踩过代码里用了保留四位小数后四舍五入把精度误差控制在货币体系的合理范围内。3.3 配送任务与路径规划的实现配送是整个系统里最容易出 bug 的模块因为它的数据模型跨了订单、库存、配送员、仓库好几个对象。我的实现思路是后台管理员把一批同区域的待发货订单打包成一个配送任务任务创建后系统按照仓库位置和客户位置的经纬度用贪心最近邻算法对客户点做排序然后把排序结果返回给小程序端展示司机可以按顺序跑。路径规划这块我本来想引入第三方地图 API但毕设项目不要求那么重而且把 API 申请流程写进文档反而增加了答辩负担。所以我用了一个数学上足够简单的方案从仓库点出发每次在未访问客户点里找离当前点最近的一个依次串联成路线。代码本身不复杂核心约 30 行但配合 Google 的 S2 库把经纬度转成球面距离计算量小效果也不错。public ListLong planDeliveryRoute(Long warehouseId, ListLong orderIds) { ListDeliveryPoint points buildPoints(warehouseId, orderIds); // 起点是仓库 DeliveryPoint current getWarehousePoint(points); ListLong route new ArrayList(); SetLong visited new HashSet(); while (visited.size() orderIds.size()) { DeliveryPoint nearest null; double minDist Double.MAX_VALUE; for (DeliveryPoint point : points) { if (visited.contains(point.getOrderId())) { continue; } double dist distance(current.getLatitude(), current.getLongitude(), point.getLatitude(), point.getLongitude()); if (dist minDist) { minDist dist; nearest point; } } visited.add(nearest.getOrderId()); route.add(nearest.getOrderId()); current nearest; } return route; }真实跑下来这个算法在 10 个客户点以内的效果已经很理想了计算时间几乎是瞬时完成路线合理性也在可接受范围。如果是 30 个点以上贪心算法可能会出现局部绕路的情况但毕设的场景根本触达不到那个量级商业系统才会需要真正的车辆路径规划求解器。3.4 养护工单自动生成定时任务怎么设计养护是植物租赁系统区别于其他租赁系统的核心差异点。植物不是死物它需要定期浇水、修剪、施肥、查看病虫害。不同品种的养护周期不一样有的三天一次有的一周一次。另外还有一个隐性业务规则客户可以额外购买“深度养护”服务加了这项服务的植物在基础养护频率上翻倍。我用 xxl-job 的调度框架实现了一个定时任务每天凌晨两点扫描所有处于‘租赁中’状态的植物库存记录根据植物品种的养护周期计算出下一次养护日期如果该日期落在未来三天内且当前日期还不存在未完成养护工单就自动生成一条新工单。工单生成后通过 WebSocket 推送给对应的养护师傅。核心是在查询这一层用了联表 SQL 加日期条件筛选避免一次性把全部数据加载到内存里遍历SELECT i.id, i.plant_code, i.current_order_id, v.maintain_cycle_days, o.address_detail, o.contact_name, o.contact_phone FROM biz_plant_inventory i JOIN biz_plant_variety v ON i.variety_id v.id JOIN biz_lease_order o ON i.current_order_id o.id WHERE i.location_status 租赁中 AND o.order_status 租赁中 AND ( SELECT COUNT(*) FROM biz_maintenance_record m WHERE m.inventory_id i.id AND m.is_completed 1 AND m.planned_date CURDATE() ) 0 AND DATE_ADD( (SELECT MAX(planned_date) FROM biz_maintenance_record r WHERE r.inventory_id i.id AND r.is_completed 1), INTERVAL v.maintain_cycle_days DAY ) DATE_ADD(CURDATE(), INTERVAL 3 DAY);这个 SQL 里最关键的子查询是“找出每个植物距离上次已完成养护的间隔是否达到标准周期”。一开始我写的版本效率很差因为每天扫描一次全量数据索引也用不上。后来改成在养护记录表上加联合索引 (inventory_id, is_completed, planned_date)查询时间降了一个数量级。这种优化经验写在文档里是实打实的加分项。3.5 前端页面与技术集成要点前端我用 Vue 3 的 Composition API 写了管理后台页面不算复杂但有几个点值得说。一是整个后台的菜单权限按角色动态渲染从后端接口拉取当前用户的权限列表前端用 v-if 控制路由和按钮的显隐。二是图表统计用的是 Apache ECharts直接从后端返回统计维度数据前端做一次维度映射就可以渲染不额外引入重型的数据处理框架。三是上传植物图片阶段用了分片上传的思维不是真实的分片而是先把图片压缩到 500KB 以内再传避免服务器负载压力。用户端小程序用 uni-app 开发一套代码能同时编译到微信小程序和 H5。下单流程比较顺滑首页展示植物列表点击进入详情选择租期确认地址预览价格明细拉起微信支付。支付回调这里有个关键细节微信支付成功回调可能重复发送系统必须在回调处理接口里做幂等控制。我的做法是回调处理逻辑的首行先按支付流水号查数据库如果这条流水已经更新过状态直接返回成功不再执行后续业务动作。这个细节非常考验工程意识面试官大概率会问。4. Redis 缓存、并发控制与性能优化实战4.1 热点数据缓存策略植物详情页是整个系统访问量最大的接口因为用户打开小程序第一眼看到的就是植物列表点进去是详情。如果每个请求都直接查数据库数据库压力会非常大。我的方案是分两级缓存植物列表页用 Redis 缓存热门品种数据过期时间设置为五分钟五分钟内的请求直接打缓存植物详情页缓存单条数据过期时间按品种的更新频率来定。核心思想是根据数据更新频率和使用热度平衡缓存时间和数据库一致性。public ListPlantVarietyVO getHotVarietyList() { String cacheKey RedisKey.HOT_VARIETY_LIST; String cachedJson redisTemplate.opsForValue().get(cacheKey); if (StringUtils.isNotBlank(cachedJson)) { return JSON.parseArray(cachedJson, PlantVarietyVO.class); } ListPlantVarietyVO list plantVarietyMapper.selectHotList(); redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(list), 5, TimeUnit.MINUTES); return list; }缓存更新策略我用的是旁路缓存模式读操作先读缓存读不到再读数据库并回填写操作先更新数据库再主动删除缓存而不是更新缓存。这样实现简单并发环境下不容易出现数据不一致。库存余量这种数据变化频繁且实时性要求高不走 Redis 缓存直接查数据库并配合乐观锁控制。4.2 超卖问题的乐观锁解决方案库存超卖是并发控制里的经典问题。植物租赁虽然不像秒杀那样瞬间爆发但高峰期同时有几个客户抢同一品种的植物时如果没有并发控制就会出现两个订单扣减了同一棵植物的库存。我的解决思路是乐观锁加唯一索引双保险。数据库层面对植物库存表的 current_order_id 字段加了唯一索引同一时间一棵植物只能被绑定到一个订单代码层面通过版本号控制更新条件更新时检查当前版本号是否和查询时一致Update(UPDATE biz_plant_inventory SET location_status在途, current_order_id#{orderId}, versionversion1 WHERE id#{inventoryId} AND version#{version} AND location_status在库) int tryOccupyInventory(Param(inventoryId) Long inventoryId, Param(orderId) Long orderId, Param(version) Integer version);返回结果大于 0 表示抢占成功等于 0 说明这棵植物的状态已经发生变化需要换一棵或者提示客户库存不足。这个方案在并发度不高的情况下体验很好用户感知不到锁的存在。如果未来并发量上去了再改成 Redis 分布式锁也不难只是毕设阶段没必要把系统搞重。4.3 索引优化与慢查询排查数据库性能优化这块我踩了不少坑也总结出了一些实际经验。页面上有一个“客户租赁历史”查询输入客户手机号查订单列表结果数据量一涨就变得很慢。我 explain 一看发现订单表上的 customer_id 索引已经建了但因为查询条件里还带了 order_status 的过滤MySQL 在数据量大时选择了全表扫描而不是索引下推。最后通过把 (customer_id, order_status, created_time) 建成联合索引解决。这个优化思路比较典型单列索引在 and 条件多的时候往往失效或者效率低联合索引能匹配更精确的查询路径。另外我还养成了一个习惯所有列表查询接口都必须做分页坚决不允许一次把全部数据返回给前端植物库存列表、订单列表、养护记录列表都是如此。分页本身不复杂用 MyBatis Plus 的 Page 对象一行代码就能搞定但能把这件事坚持做到所有列表接口体现的是工程意识。5. 常见问题排查与避坑指南5.1 状态不对账财务结算数据对不上我第一次把财务模块写完之后找同事帮忙测试。同事模拟了一个客户租了三个月植物中途提前退租结果财务模块算出来的应收金额和手工算的对不上。排查到最后发现是状态机里少了一条流转链订单从“租赁中”可以直接跳到“已退租”但退租逻辑里没去算违约金导致应退金额和实际退款之间差了半天的罚款。这类问题已经超出单纯编程的范畴本质是业务规则没有完全数字化。我的解决方案一个是把状态机和业务动作绑定任何流程流转必须走 Service 层的方法不允许直接把状态字段 set 后调 update 更新这样每个状态变更的前置和后置动作都不容易漏另一个是在财务模块增加了手工调账单功能运营遇到数据不一致时可以在后台做校正既保证了数据的最终一致也保留了运营的灵活性。5.2 微信支付回调重复导致重复发券支付的幂等性问题再展开一次因为太典型了。微信支付回调是异步的可能因为网络原因间隔几秒重试多次如果回调处理函数不是幂等的就会造成同一笔订单被处理两次。我一开始没写幂等判断测试时发现客户支付成功后账户里多了两条充值记录一下子就慌了。后面在回调入口处加了一个基于唯一业务号的防重判断具体做法是独立一张支付流水表表里对 transaction_id 加了唯一索引插入成功才继续更新订单状态插入失败就说明这条回调已经处理过了直接返回成功。这个方法能彻底避免并发场景下同时收到两次回调的竞态问题。另外凡是涉及金额变动的地方都加上了审计日志保留完整的操作痕迹万一出问题可以回溯操作记录。5.3 MyBatis Plus 的坑与解决MyBatis Plus 用起来确实省时间但有几个隐藏地对新手不友好的地方。字段映射驼峰转下划线默认是开启的但如果你在实体类里用了 resultMap 自己配置映射驼峰转换可能会失效这就导致查询出来的某些字段是 null。排查方式是打开 MyBatis 的 SQL 日志输出先确认 SQL 语句本身有没有查这些字段再确认映射关系。另一个常见的坑是 MyBatis Plus 的 update 方法默认只更新非空字段也就是说如果你想把某个字段更新成 null直接调默认 updateById 是不生效的。解决办法是在实体字段上加上 TableField(updateStrategy FieldStrategy.IGNORED) 注解或者手写一个 UpdateWrapper 手动 set 对应字段。这个细节如果不知道排查起来会非常浪费时间。5.4 Lombok 与编译环境的兼容性问题Lombok 在本地编译正常但打包部署到服务器上报 java.lang.ExceptionInInitializerError这个现象遇到过的人不在少数。原因一般是 JDK 版本与 Lombok 版本不兼容Lombok 旧版本对 JDK 9 的支持有 bug。解决方法是把 Lombok 升级到适配当前 JDK 版本的版本比如 JDK 17 对应 Lombok 1.18.30 以上。另外一个野路子是检查项目里是否引入了多个 Lombok 版本依赖冲突也会导致类似的编译异常。开发工具这块我建议用 IDEA 并装好 Lombok 插件Eclipse 环境对 Lombok 的支持比较麻烦配置不到位很容易出现开了注解但 getter/setter 生成不了的问题。新手如果不想在这一步卡太久也可以先不用 Lombok老老实实手动生成 getter/setter这是最稳的方式。6. 部署上线从本地开发到服务器运行6.1 环境准备与打包构建部署这块其实是很多同学容易忽略但实际面试高频考察的部分。我的部署架构是单台服务器Nginx 做反向代理和静态资源服务后端 Jar 包通过 systemd 守护进程托管MySQL 和 Redis 分别用 Docker 容器部署方便管理。服务器配置选了 2核4G 的入门级云主机这个配置跑这套系统绰绰有余。打包之前有几件事必须确认。数据库连接配置要改成服务器的内网地址如果是通过公网访问要注意安全组放行相应端口MySQL 密码不要硬编码写在 application.yml 里优先用环境变量注入Redis 要配置访问密码不能裸奔在公网环境下。这些都是最基本的线上安全意识。# 前端构建 npm run build # 后端打包跳过测试 mvn clean package -DskipTests # 上传到服务器后启动 nohup java -Xms512m -Xmx512m -jar plant-lease-server.jar \ --spring.profiles.activeprod \ --DB_HOST127.0.0.1 \ --DB_PORT3306 \ --REDIS_HOST127.0.0.1 /app/logs/app.log 21 6.2 systemd 配置服务守护用 nohup 启动进程有一个问题服务器重启或者进程意外退出应用不会自动拉起来。我用 systemd 写了一个服务配置文件实现开机自启和崩溃自动重启[Unit] DescriptionPlant Lease Server Afternetwork.target mysql.service redis.service [Service] Typesimple Userapp WorkingDirectory/app/plant-lease EnvironmentFile/app/plant-lease/.env ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /app/plant-lease/plant-lease-server.jar Restartalways RestartSec5 StandardOutputappend:/app/logs/app.log StandardErrorappend:/app/logs/app-error.log [Install] WantedBymulti-user.target配置亮点在于使用 EnvironmentFile 管理数据库密码等敏感信息服务重启不会暴露在进程列表里。再用 Nginx 把 80 端口的 HTTP 流量反向代理到 Spring Boot 的 8080 端口同时托管前端静态页面。这样整套系统就完成了一个生产环境的最小闭环。6.3 线上问题定位的三个实用工具线上环境和本地开发最大的区别是排查问题的手段受限。我常用的三个工具组合是看日志、看线程、看数据库。日志这块logback 配置里给不同包设置了不同的日志级别关键业务包用 DEBUG框架包用 INFO避免线上日志量过大。线程排查主要用 jstack 导出线程快照看是否有死锁或者长时间的阻塞特别是各 Service 层加锁的地方容易出问题。数据库这块就是定位慢 SQL开启 MySQL 的慢查询日志把执行时间超过1秒的 SQL 记录下来再逐一优化。这三个工具组合虽然传统但确实能解决 95% 以上的线上问题。毕设答辩谈到部署运维经验时能说出清楚这三个工具的用途和适用场景就已经超过绝大多数同龄人了。7. 写在最后的几点经验心得整套系统从设计到上线前后花了六周左右。前两周在梳理业务和搭建框架中间三周在写核心业务代码最后一周在做性能优化和部署。最大的体会是毕业设计不是把技术名词堆上去就完事真正重要的是系统能不能跑通一条完整的业务链路。植物租赁这个题目让我每个模块都不是空中楼阁。比如状态机、乐观锁、定时任务、消息推送、支付回调防重这些知识点全部都有对应的真实场景而不是为了写而写。另外还有一点比较实用的小经验开发过程中不管时间多紧都要保持编写接口文档的习惯哪怕只是简单地记录请求参数和返回结构。因为后期调试、联调、答辩、扩展功能都会频繁用到这份文档它对整个项目的推进和展示都有很大帮助。如果时间充裕建议提前为每个接口准备好测试用例能极大提升联调和演示环节的流畅程度。这个系统后续如果想继续做得更深入方向其实很多。比如加入 IoT 传感器的植物状态监控、基于历史订单数据的客户流失预警、更精准的车辆路径规划算法等等。但那些都是后话先把基础打扎实这套完整项目经验足够支撑一段高质量的面试自我介绍了。