简介基于 Servlet 与 Oracle 数据库构建的 Java 汽车租赁管理系统源码包配套设计文档面向 Java Web 学习者、毕业设计及课程设计人群。系统按用户、客户、汽车、业务管理、业务统计五大模块组织覆盖租车订单、车辆调度、客户信息维护等常见业务场景。包内文件共 1249 个压缩包约 14.18MB其中 java 与 class 文件为核心逻辑包含 76 个 jsp 动态页面、60 个 html 和 110 个 jpg/gif 界面素材另有 26 个 css、163 个 js 用于前端交互以及 sql 数据库脚本、doc 设计文档目录结构清晰便于整体导入 Eclipse 开发。该资源上线以来已有 1872 人浏览学习。通过完整源码与设计书读者可梳理 Servlet、DAO 层的调用关系理解各功能模块的数据库设计思路也可基于现有代码做二次开发或用于毕业设计答辩准备。1. 一套JAVA汽车租赁管理系统源码含设计书意味着什么下载过JAVA完整源码的开发者基本都有同感代码能跑通设计思路几乎靠猜。一套同时含设计书的汽车租赁管理系统价值就在于能用文档反推代码逐项核对需求、表结构和规则落到实处的程度。租车业务比普通增删改查多了“状态流转”和“费用计算”两座小山空闲到已预订到出租中的状态流转、日租金与逾期费的结算逻辑复杂程度刚好够讲清事务和表设计。这份项目适合三类人准备java面试八股文阶段缺少项目作答的求职者、需要完整课设的大三学生、想补一套规范化CRUD经验的后端新人。阅读路径建议是先翻设计书再开IDE最后才是启动程序。2. 从设计书反推数据模型车辆、客户与订单表的建表思路2.1 设计书里最该先读的部分E-R图与数据字典一份规范的软件设计书最核心的内容集中在两处E-R图和数据字典。E-R图告诉你实体间的关系数据字典告诉你每个字段的业务含义。汽车租赁系统主要的实体有六到八个车辆、品牌车型、客户、员工、租赁订单、费用明细、门店、还车记录。很多源码设计书里品牌车型是用一个字符串塞在车辆表里的“carType”字段而不是独立的brand表——这在E-R图阶段就埋下了隐患。读设计书时先画一张实体关系草图标出哪些是一对多、哪些是多对多再对比源码里的建表语句差距会立刻浮现。2.2 车辆表字段设计与状态索引车辆表是主数据字段上有几个常见争议点值得展开。第一个是车牌号是否做主键。实车业务里车牌会因过户而变化VIN码才是物理不变标识但在课程设计和多数中小租赁公司系统里车牌号做主键是实操中能接受的简化。更稳妥的方式还是自增ID主键加车牌唯一索引既保留业务唯一性又不影响外键引用。第二个争议是车辆状态用int还是字符串结论是用TINYINT——金额字段用DECIMAL状态字段用TINYINT这是JAVA基础里很容易被忽略却经常被面试官追问的约定。字段类型说明设计要点idBIGINT自增主键所有外键引用统一指向idplate_numberVARCHAR(10)车牌号建唯一索引业务上不允许重复daily_rentDECIMAL(10,2)日租金金额一律定点数不用FLOATstatusTINYINT车辆状态0空闲 1已预订 2租赁中 3维修中 4停用CREATE TABLE car_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 自增主键, plate_number VARCHAR(10) NOT NULL COMMENT 车牌号, vin_code VARCHAR(17) COMMENT 车架号VIN, brand VARCHAR(32) NOT NULL COMMENT 品牌, model VARCHAR(64) NOT NULL COMMENT 车型, color VARCHAR(16) COMMENT 颜色, daily_rent DECIMAL(10, 2) NOT NULL DEFAULT 0.00 COMMENT 日租金元, deposit DECIMAL(10, 2) NOT NULL DEFAULT 0.00 COMMENT 押金元, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0空闲 1已预订 2租赁中 3维修中 4已停用, store_id BIGINT NOT NULL COMMENT 所属门店ID, purchase_date DATE COMMENT 购入日期, current_mileage INT DEFAULT 0 COMMENT 当前里程公里, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, UNIQUE KEY uk_plate_number (plate_number), KEY idx_status_store (status, store_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 车辆信息表;建表语句的逻辑很直白车牌号建唯一索引保证一辆车在系统里只出现一次status和store_id建组合索引是因为“某个门店下可租车辆的列表页”是最常见的业务查询走idx_status_store可以避免全表扫描。DEFAULT CURRENT_TIMESTAMP这种写法只适用于一个表里最多两个时间字段的场景如果表里出现第三个DATETIME建议在程序里显式传值。提示写数据字典时给每个字段加COMMENT是必须养成的习惯。MySQL里SHOW FULL COLUMNS结果会直接展示注释省去频繁翻设计书的功夫。2.3 租赁订单主从表拆分租赁订单不能设计成一张大宽表。订单包含基本信息哪个客户、哪辆车、哪个门店、起止时间和费用信息基础租金、超时费、超里程费、押金扣除、保险金额如果全塞一张表字段超过二十个且大量字段在还车结算前都是NULL非常难维护。常见做法是在rental_order主表之外加一张order_fee_detail明细表用fee_type区分费用条目。这样扩展新费用类型不需要改表只需要加一条明细。CREATE TABLE rental_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 订单号, customer_id BIGINT NOT NULL COMMENT 客户ID, car_id BIGINT NOT NULL COMMENT 车辆ID, store_id BIGINT NOT NULL COMMENT 取车门店ID, start_time DATETIME NOT NULL COMMENT 计划取车时间, plan_end_time DATETIME NOT NULL COMMENT 计划还车时间, actual_end_time DATETIME DEFAULT NULL COMMENT 实际还车时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待取车 1租赁中 2待结算 3已完成 4已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_customer_create_time (customer_id, create_time), KEY idx_car_status (car_id, status) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 租赁订单主表; CREATE TABLE order_fee_detail ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT 订单ID, fee_type TINYINT NOT NULL COMMENT 费用类型1基础租金 2超时费 3超里程费 4押金扣款, amount DECIMAL(10, 2) NOT NULL COMMENT 金额元, remark VARCHAR(255) COMMENT 备注, KEY idx_order_id (order_id), CONSTRAINT fk_fee_order FOREIGN KEY (order_id) REFERENCES rental_order (id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 订单费用明细表;明细表通过外键关联主表并在order_id上建索引因为按订单查费用明细是最高频操作之一。主表里order_no建唯一索引order_no的生成规则要保证在并发下不重复常用的拼法是把当前时间按年月日时分秒格式化后加三位随机数或者用Snowflake算法。区分主从表之后计费代码就可以把不同费用类型分发到不同策略类这是源码里比较值得借鉴的订单结构设计。2.4 用SQL脚本把设计书落的MySQL拿到源码先看数据库目录下有没有schema.sql或init.sql。执行导入后立即做两件核对的事第一逐张开表检查字段注释是否存在第二抽查两张关键表的数据量确认没有把示例数据和生产结构混在一起。核对注释可以直接跑SQL查询information_schemaSELECT table_name, column_name, column_type, column_comment FROM information_schema.columns WHERE table_schema rental_db AND column_comment ORDER BY table_name, ordinal_position;mysql -uroot -p rental_db docs/schema.sql mysql -uroot -p rental_db -e SHOW FULL COLUMNS FROM car_info;三条命令分别用于导入结构、查询无注释字段、查看单表结构。如果跑完第三条有大量空注释输出说明建表脚本和设计书脱节能改就改。检查外键约束是否真实存在也很重要设计书里画了关系线但建表时没加FOREIGN KEY的情况在源码里不算少见虽然业务上靠service层也能维护一致但面试聊到物理外键和逻辑外键的取舍时至少要知道自己项目用的是哪种。3. 用Spring Boot把租赁流程跑通预订、取车、还车、计费3.1 项目结构先把“流程服务”和“费用计算”拆开看过不少租赁源码最常见的毛病是RentService里既管数据库增删改查又处理费用计算公式一个方法两三百行。合理的分包应该这样controller层只负责参数接收和结果封装service层按业务能力拆分RentService管流程编排FeeChargeService管费用计算dao层保持纯粹的MyBatis Mapper。流程服务调用费用服务是单向依赖费用服务不反向依赖流程服务。这种拆分不是过度设计。还车时先算费用费用计算完成后再更新订单状态如果这两个逻辑在同一方法里顺序执行后期引入“改价”“优惠券”会非常痛苦。底层思路是单一职责原则的实践也是java面试题里常考的设计原则应用场景。模块关键类职责范围流程编排RentService预订、取车、还车、取消的调度与状态流转费用计算FeeChargeService计算基础租金、超时费、超里程费数据访问CarInfoMapper / OrderMapperMyBatis映射只做单表读写3.2 预订接口事务、行锁与唯一订单号的配合预订车辆的代码是整套系统里第一个值得逐行读的部分。这一步的完整业务规则是校验车辆是否存在且状态为空闲创建订单把车辆状态改为已预订。三步必须同时成功或同时失败否则会出现“有订单没车”或“有车没订单”的脏数据。Service RequiredArgsConstructor public class RentService { private final CarInfoMapper carInfoMapper; private final RentalOrderMapper orderMapper; Transactional(rollbackFor Exception.class) public RentalOrder reserve(Long carId, Long customerId, LocalDateTime startTime, LocalDateTime planEndTime) { // 行锁查询防止两个请求同时读到空闲状态 CarInfo car carInfoMapper.selectByIdForUpdate(carId); if (car null || car.getStatus() ! 0) { throw new BizException(车辆当前不可预订状态码 car.getStatus()); } RentalOrder order new RentalOrder(); order.setOrderNo(generateOrderNo()); order.setCarId(carId); order.setCustomerId(customerId); order.setStartTime(startTime); order.setPlanEndTime(planEndTime); order.setStatus(0); orderMapper.insert(order); car.setStatus(1); carInfoMapper.updateById(car); return order; } }逻辑说明Transactional(rollbackFor Exception.class)指定异常回滚范围比默认的RuntimeException更宽业务里随手抛出的CheckedException也能触发回滚。SELECT ... FOR UPDATE是行级悲观锁在并发高的情况下效率不如乐观锁但对课程设计和中小门店系统来说胜在实现简单、行为可预期。注意锁要加在事务里才有效selectByIdForUpdate必须在同一个事务方法内执行。generateOrderNo()如果依赖数据库自增ID就要在insert之后才能拿到更常见的做法是把时间戳加随机数提前拼好。java八股文里的“事务传播行为”在这里就是练习题reserve方法调orderMapper.insert和carInfoMapper.updateById走的是默认的REQUIRED传播两个Mapper操作属于同一事务。如果有人在service里给更新车辆方法单独加了Transactional(propagation Propagation.REQUIRES_NEW)那车辆状态就会被提前提交事务回滚范围被破坏。看源码时可以顺带检查每个方法上的事务注解是否都加在主入口上这是事务面试题的绝佳素材。3.3 还车计费用策略类代替if-else还车时要更新实际还车时间、计算各项费用、锁押金、更新车辆状态。真正的复杂度在费用计算。不少源码是这么写的先查订单然后用十几个if判断超时没、超里程没、有没有违约最后塞进同一个update语句。这种写法在规则少的时候没问题规则一旦变多每次都动同一段代码迟早出事。常见的做法是定义FeeCalculator策略接口每种费用一个实现类。public interface FeeCalculator { BigDecimal calc(RentContext ctx); } Component public class OverdueFeeCalculator implements FeeCalculator { Override public BigDecimal calc(RentContext ctx) { long overdueMinutes Duration.between(ctx.getPlanEndTime(), ctx.getActualEndTime()).toMinutes(); if (overdueMinutes 0) return BigDecimal.ZERO; BigDecimal hourlyRate ctx.getDailyRent().divide(BigDecimal.valueOf(24), 2, RoundingMode.HALF_UP); return hourlyRate.multiply(BigDecimal.valueOf(overdueMinutes)) .divide(BigDecimal.valueOf(60), 2, RoundingMode.HALF_UP); } }RentContext是一个参数对象把订单、车辆、实际还车时间、实际里程全部封装进去。OverdueFeeCalculator只关心超时费计算时先得出分钟差再用日租金除以24得到小时单价最后按分钟折算。RoundingMode.HALF_UP是四舍五入金额计算必须显式指定舍入模式否则BigDecimal.divide在除不尽时会抛ArithmeticException。在service层用for循环遍历所有FeeCalculator实现把结果累加后写入order_fee_detail表。这样设计的好处有两点新增一种费用类型时不需要改动已有代码只需要新增一个实现类每个策略类的方法足够小单测容易写写单元测试时构造RentContext的代码也能复用直接反映设计书里超时费的业务规则。3.4 登录权限与角色数据隔离员工登录的认证与授权课程设计源码普遍用Session存角色判断用户角色后在controller入口手动查一次再决定放不放行。更值得做的是升级为JWT方案因为JWT是java面试题库里高频出现的考点。PostMapping(/login) public ResultString login(RequestBody LoginRequest req) { User user userMapper.selectByUsername(req.getUsername()); if (user null || !PasswordEncoder.matches(req.getPassword(), user.getPassword())) { throw new BizException(用户名或密码错误); } MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(role, user.getRole()); String token JwtUtil.createToken(claims, 24 * 60 * 60 * 1000L); return Result.ok(token); }PasswordEncoder.matches比对的是BCrypt密文和明文数据库里绝不能存明文密码。JwtUtil生成token时把userId和role放进claims过期时间设为一天。后续拦截器拿到token后解析claims把role与当前接口要求的角色比对。还需要注意角色数据隔离门店员工只能看自己门店的车辆和订单管理员可以看全量数据。数据隔离不是前端隐藏按钮就能解决而是在SQL查询条件里强制带上store_id拦截器从token里取出所属门店后拼入查询条件。这一条如果没做就会出现低权限用户越权访问其他门店数据的隐患。4. 设计书怎么用从文档反向审查源码的四个具体动作4.1 用功能模块清单反查Controller覆盖度设计书首页通常会画功能模块图系统管理、车辆管理、客户管理、租赁管理、结算管理、统计报表。拿这张图逐项对照Controller类大概率会发现统计报表只有两三个汇总接口结算管理里“押金退还”没有写实现。这个反查过程不是挑毛病而是理解作者的设计取舍。比如统计模块缺失通常是因为设计书写了复杂报表而作者为了赶工砍掉了如果自己接手只需要补一个简单的当日营收、在租车辆数、逾期订单数三个统计接口就能把功能清单对上。4.2 用数据字典核对表结构与注释设计书的数据字典和实际建表脚本经常不一致。差异点往往是字段名改了但注释没同步更新、类型从decimal退化成double、加了冗余字段却没写用途。用information_schema查询能快速找出所有缺失注释的字段这一步在接手任何老项目时都值得做一遍建议把输出结果存成一份名为“字段核对清单”的文档后续排错的时候直接对照。4.3 把业务规则变成测试用例矩阵设计书里的“业务规则”章节是测试用例的最好素材。比如“同一客户在同一时间段只能预订一辆车”、“车辆维护期间不能下单”、“还车时间超过计划时间两小时以上按全天计费”每一条规则都可以直接对应一个JUnit测试方法。把规则摘出来按规则编号组织成测试最后得到的不只是代码而是一份可执行的验收清单。规则编号业务规则期望行为对应测试方法R-001空闲车辆才可预订返回成功车辆状态变已预订testReserveSuccessR-002已预订车辆再次预订抛BizException状态不变化testReserveConflictR-003还车时间超过计划时间订单状态变待结算生成超时费明细testReturnWithOverdueR-004客户同时段重复下单第二单抛异常事务回滚testCannotBookOverlap4.4 用设计书验证状态流转的合法性设计书里即使没画状态图也会有文字描述“预订后不可取消、取车后进入租赁中、还车后待结算”。源码里如果只有setStatus裸调用就存在非法跳转的可能例如从“已取消”直接跳到“已完成”。处理方法是在service层建一个状态机校验private static final MapInteger, SetInteger ALLOWED_TRANSITIONS Map.of( 0, Set.of(1, 4), 1, Set.of(2, 4), 2, Set.of(3) ); public RentalOrder changeStatus(Long orderId, int targetStatus) { RentalOrder order orderMapper.selectById(orderId); SetInteger allowed ALLOWED_TRANSITIONS.get(order.getStatus()); if (!allowed.contains(targetStatus)) { throw new BizException(非法状态流转 order.getStatus() - targetStatus); } order.setStatus(targetStatus); orderMapper.updateById(order); return order; }用Map定义合法迁移路径把校验集中在一个方法里任何地方要改订单状态都必须走这里。相比在SetStatus方法里加一堆if判断这种方式扩展性更强后续加“维修中”状态只需要改Map定义。对照设计书文字描述逐条检查这个Map就能确认状态流转逻辑有没有漏。5. 从课程设计走向生产级四个值得动手的重构方向5.1 计费规则从硬编码改为配置表把超时费每小时单价、超里程每公里单价、免费里程数这些常量从代码挪到sys_config表用ConfigurationProperties加载到内存。改价不用重新发版对运营来说差异巨大。5.2 报表查询加Redis缓存统计接口如果每次都实时SUM表数据量上来后会拖垮主库。常见做法是把当日营收、车辆利用率这类指标以JSON结构存Rediskey里带日期每天凌晨用定时任务算好查询直接读缓存缓存miss才回源数据库。5.3 引入消息队列解耦还车通知还车结算完成后要发短信、推送APP通知、更新车辆清洁状态这些动作阻塞在主线程里会拉长接口响应时间。用Spring Event先做进程内解耦后续规模大了再替换成RocketMQ。还车接口只负责事务性操作其余逻辑监听事件异步执行。5.4 给核心表和接口补充压测用JMeter对预订接口做一次简单并发测试50线程同时订同一辆车观察是否出现超卖。跑完就会理解FOR UPDATE行锁在并发下的效果也能验证数据库连接池参数是否合理。压测这一步做完整个系统的健壮性心里就有底了。本文还有配套的精品资源点击获取 Java汽车租赁管理系统源码：设计书驱动的Spring Boot实践
简介基于 Servlet 与 Oracle 数据库构建的 Java 汽车租赁管理系统源码包配套设计文档面向 Java Web 学习者、毕业设计及课程设计人群。系统按用户、客户、汽车、业务管理、业务统计五大模块组织覆盖租车订单、车辆调度、客户信息维护等常见业务场景。包内文件共 1249 个压缩包约 14.18MB其中 java 与 class 文件为核心逻辑包含 76 个 jsp 动态页面、60 个 html 和 110 个 jpg/gif 界面素材另有 26 个 css、163 个 js 用于前端交互以及 sql 数据库脚本、doc 设计文档目录结构清晰便于整体导入 Eclipse 开发。该资源上线以来已有 1872 人浏览学习。通过完整源码与设计书读者可梳理 Servlet、DAO 层的调用关系理解各功能模块的数据库设计思路也可基于现有代码做二次开发或用于毕业设计答辩准备。1. 一套JAVA汽车租赁管理系统源码含设计书意味着什么下载过JAVA完整源码的开发者基本都有同感代码能跑通设计思路几乎靠猜。一套同时含设计书的汽车租赁管理系统价值就在于能用文档反推代码逐项核对需求、表结构和规则落到实处的程度。租车业务比普通增删改查多了“状态流转”和“费用计算”两座小山空闲到已预订到出租中的状态流转、日租金与逾期费的结算逻辑复杂程度刚好够讲清事务和表设计。这份项目适合三类人准备java面试八股文阶段缺少项目作答的求职者、需要完整课设的大三学生、想补一套规范化CRUD经验的后端新人。阅读路径建议是先翻设计书再开IDE最后才是启动程序。2. 从设计书反推数据模型车辆、客户与订单表的建表思路2.1 设计书里最该先读的部分E-R图与数据字典一份规范的软件设计书最核心的内容集中在两处E-R图和数据字典。E-R图告诉你实体间的关系数据字典告诉你每个字段的业务含义。汽车租赁系统主要的实体有六到八个车辆、品牌车型、客户、员工、租赁订单、费用明细、门店、还车记录。很多源码设计书里品牌车型是用一个字符串塞在车辆表里的“carType”字段而不是独立的brand表——这在E-R图阶段就埋下了隐患。读设计书时先画一张实体关系草图标出哪些是一对多、哪些是多对多再对比源码里的建表语句差距会立刻浮现。2.2 车辆表字段设计与状态索引车辆表是主数据字段上有几个常见争议点值得展开。第一个是车牌号是否做主键。实车业务里车牌会因过户而变化VIN码才是物理不变标识但在课程设计和多数中小租赁公司系统里车牌号做主键是实操中能接受的简化。更稳妥的方式还是自增ID主键加车牌唯一索引既保留业务唯一性又不影响外键引用。第二个争议是车辆状态用int还是字符串结论是用TINYINT——金额字段用DECIMAL状态字段用TINYINT这是JAVA基础里很容易被忽略却经常被面试官追问的约定。字段类型说明设计要点idBIGINT自增主键所有外键引用统一指向idplate_numberVARCHAR(10)车牌号建唯一索引业务上不允许重复daily_rentDECIMAL(10,2)日租金金额一律定点数不用FLOATstatusTINYINT车辆状态0空闲 1已预订 2租赁中 3维修中 4停用CREATE TABLE car_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 自增主键, plate_number VARCHAR(10) NOT NULL COMMENT 车牌号, vin_code VARCHAR(17) COMMENT 车架号VIN, brand VARCHAR(32) NOT NULL COMMENT 品牌, model VARCHAR(64) NOT NULL COMMENT 车型, color VARCHAR(16) COMMENT 颜色, daily_rent DECIMAL(10, 2) NOT NULL DEFAULT 0.00 COMMENT 日租金元, deposit DECIMAL(10, 2) NOT NULL DEFAULT 0.00 COMMENT 押金元, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0空闲 1已预订 2租赁中 3维修中 4已停用, store_id BIGINT NOT NULL COMMENT 所属门店ID, purchase_date DATE COMMENT 购入日期, current_mileage INT DEFAULT 0 COMMENT 当前里程公里, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, UNIQUE KEY uk_plate_number (plate_number), KEY idx_status_store (status, store_id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 车辆信息表;建表语句的逻辑很直白车牌号建唯一索引保证一辆车在系统里只出现一次status和store_id建组合索引是因为“某个门店下可租车辆的列表页”是最常见的业务查询走idx_status_store可以避免全表扫描。DEFAULT CURRENT_TIMESTAMP这种写法只适用于一个表里最多两个时间字段的场景如果表里出现第三个DATETIME建议在程序里显式传值。提示写数据字典时给每个字段加COMMENT是必须养成的习惯。MySQL里SHOW FULL COLUMNS结果会直接展示注释省去频繁翻设计书的功夫。2.3 租赁订单主从表拆分租赁订单不能设计成一张大宽表。订单包含基本信息哪个客户、哪辆车、哪个门店、起止时间和费用信息基础租金、超时费、超里程费、押金扣除、保险金额如果全塞一张表字段超过二十个且大量字段在还车结算前都是NULL非常难维护。常见做法是在rental_order主表之外加一张order_fee_detail明细表用fee_type区分费用条目。这样扩展新费用类型不需要改表只需要加一条明细。CREATE TABLE rental_order ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 订单号, customer_id BIGINT NOT NULL COMMENT 客户ID, car_id BIGINT NOT NULL COMMENT 车辆ID, store_id BIGINT NOT NULL COMMENT 取车门店ID, start_time DATETIME NOT NULL COMMENT 计划取车时间, plan_end_time DATETIME NOT NULL COMMENT 计划还车时间, actual_end_time DATETIME DEFAULT NULL COMMENT 实际还车时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待取车 1租赁中 2待结算 3已完成 4已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_customer_create_time (customer_id, create_time), KEY idx_car_status (car_id, status) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 租赁订单主表; CREATE TABLE order_fee_detail ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_id BIGINT NOT NULL COMMENT 订单ID, fee_type TINYINT NOT NULL COMMENT 费用类型1基础租金 2超时费 3超里程费 4押金扣款, amount DECIMAL(10, 2) NOT NULL COMMENT 金额元, remark VARCHAR(255) COMMENT 备注, KEY idx_order_id (order_id), CONSTRAINT fk_fee_order FOREIGN KEY (order_id) REFERENCES rental_order (id) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 订单费用明细表;明细表通过外键关联主表并在order_id上建索引因为按订单查费用明细是最高频操作之一。主表里order_no建唯一索引order_no的生成规则要保证在并发下不重复常用的拼法是把当前时间按年月日时分秒格式化后加三位随机数或者用Snowflake算法。区分主从表之后计费代码就可以把不同费用类型分发到不同策略类这是源码里比较值得借鉴的订单结构设计。2.4 用SQL脚本把设计书落的MySQL拿到源码先看数据库目录下有没有schema.sql或init.sql。执行导入后立即做两件核对的事第一逐张开表检查字段注释是否存在第二抽查两张关键表的数据量确认没有把示例数据和生产结构混在一起。核对注释可以直接跑SQL查询information_schemaSELECT table_name, column_name, column_type, column_comment FROM information_schema.columns WHERE table_schema rental_db AND column_comment ORDER BY table_name, ordinal_position;mysql -uroot -p rental_db docs/schema.sql mysql -uroot -p rental_db -e SHOW FULL COLUMNS FROM car_info;三条命令分别用于导入结构、查询无注释字段、查看单表结构。如果跑完第三条有大量空注释输出说明建表脚本和设计书脱节能改就改。检查外键约束是否真实存在也很重要设计书里画了关系线但建表时没加FOREIGN KEY的情况在源码里不算少见虽然业务上靠service层也能维护一致但面试聊到物理外键和逻辑外键的取舍时至少要知道自己项目用的是哪种。3. 用Spring Boot把租赁流程跑通预订、取车、还车、计费3.1 项目结构先把“流程服务”和“费用计算”拆开看过不少租赁源码最常见的毛病是RentService里既管数据库增删改查又处理费用计算公式一个方法两三百行。合理的分包应该这样controller层只负责参数接收和结果封装service层按业务能力拆分RentService管流程编排FeeChargeService管费用计算dao层保持纯粹的MyBatis Mapper。流程服务调用费用服务是单向依赖费用服务不反向依赖流程服务。这种拆分不是过度设计。还车时先算费用费用计算完成后再更新订单状态如果这两个逻辑在同一方法里顺序执行后期引入“改价”“优惠券”会非常痛苦。底层思路是单一职责原则的实践也是java面试题里常考的设计原则应用场景。模块关键类职责范围流程编排RentService预订、取车、还车、取消的调度与状态流转费用计算FeeChargeService计算基础租金、超时费、超里程费数据访问CarInfoMapper / OrderMapperMyBatis映射只做单表读写3.2 预订接口事务、行锁与唯一订单号的配合预订车辆的代码是整套系统里第一个值得逐行读的部分。这一步的完整业务规则是校验车辆是否存在且状态为空闲创建订单把车辆状态改为已预订。三步必须同时成功或同时失败否则会出现“有订单没车”或“有车没订单”的脏数据。Service RequiredArgsConstructor public class RentService { private final CarInfoMapper carInfoMapper; private final RentalOrderMapper orderMapper; Transactional(rollbackFor Exception.class) public RentalOrder reserve(Long carId, Long customerId, LocalDateTime startTime, LocalDateTime planEndTime) { // 行锁查询防止两个请求同时读到空闲状态 CarInfo car carInfoMapper.selectByIdForUpdate(carId); if (car null || car.getStatus() ! 0) { throw new BizException(车辆当前不可预订状态码 car.getStatus()); } RentalOrder order new RentalOrder(); order.setOrderNo(generateOrderNo()); order.setCarId(carId); order.setCustomerId(customerId); order.setStartTime(startTime); order.setPlanEndTime(planEndTime); order.setStatus(0); orderMapper.insert(order); car.setStatus(1); carInfoMapper.updateById(car); return order; } }逻辑说明Transactional(rollbackFor Exception.class)指定异常回滚范围比默认的RuntimeException更宽业务里随手抛出的CheckedException也能触发回滚。SELECT ... FOR UPDATE是行级悲观锁在并发高的情况下效率不如乐观锁但对课程设计和中小门店系统来说胜在实现简单、行为可预期。注意锁要加在事务里才有效selectByIdForUpdate必须在同一个事务方法内执行。generateOrderNo()如果依赖数据库自增ID就要在insert之后才能拿到更常见的做法是把时间戳加随机数提前拼好。java八股文里的“事务传播行为”在这里就是练习题reserve方法调orderMapper.insert和carInfoMapper.updateById走的是默认的REQUIRED传播两个Mapper操作属于同一事务。如果有人在service里给更新车辆方法单独加了Transactional(propagation Propagation.REQUIRES_NEW)那车辆状态就会被提前提交事务回滚范围被破坏。看源码时可以顺带检查每个方法上的事务注解是否都加在主入口上这是事务面试题的绝佳素材。3.3 还车计费用策略类代替if-else还车时要更新实际还车时间、计算各项费用、锁押金、更新车辆状态。真正的复杂度在费用计算。不少源码是这么写的先查订单然后用十几个if判断超时没、超里程没、有没有违约最后塞进同一个update语句。这种写法在规则少的时候没问题规则一旦变多每次都动同一段代码迟早出事。常见的做法是定义FeeCalculator策略接口每种费用一个实现类。public interface FeeCalculator { BigDecimal calc(RentContext ctx); } Component public class OverdueFeeCalculator implements FeeCalculator { Override public BigDecimal calc(RentContext ctx) { long overdueMinutes Duration.between(ctx.getPlanEndTime(), ctx.getActualEndTime()).toMinutes(); if (overdueMinutes 0) return BigDecimal.ZERO; BigDecimal hourlyRate ctx.getDailyRent().divide(BigDecimal.valueOf(24), 2, RoundingMode.HALF_UP); return hourlyRate.multiply(BigDecimal.valueOf(overdueMinutes)) .divide(BigDecimal.valueOf(60), 2, RoundingMode.HALF_UP); } }RentContext是一个参数对象把订单、车辆、实际还车时间、实际里程全部封装进去。OverdueFeeCalculator只关心超时费计算时先得出分钟差再用日租金除以24得到小时单价最后按分钟折算。RoundingMode.HALF_UP是四舍五入金额计算必须显式指定舍入模式否则BigDecimal.divide在除不尽时会抛ArithmeticException。在service层用for循环遍历所有FeeCalculator实现把结果累加后写入order_fee_detail表。这样设计的好处有两点新增一种费用类型时不需要改动已有代码只需要新增一个实现类每个策略类的方法足够小单测容易写写单元测试时构造RentContext的代码也能复用直接反映设计书里超时费的业务规则。3.4 登录权限与角色数据隔离员工登录的认证与授权课程设计源码普遍用Session存角色判断用户角色后在controller入口手动查一次再决定放不放行。更值得做的是升级为JWT方案因为JWT是java面试题库里高频出现的考点。PostMapping(/login) public ResultString login(RequestBody LoginRequest req) { User user userMapper.selectByUsername(req.getUsername()); if (user null || !PasswordEncoder.matches(req.getPassword(), user.getPassword())) { throw new BizException(用户名或密码错误); } MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(role, user.getRole()); String token JwtUtil.createToken(claims, 24 * 60 * 60 * 1000L); return Result.ok(token); }PasswordEncoder.matches比对的是BCrypt密文和明文数据库里绝不能存明文密码。JwtUtil生成token时把userId和role放进claims过期时间设为一天。后续拦截器拿到token后解析claims把role与当前接口要求的角色比对。还需要注意角色数据隔离门店员工只能看自己门店的车辆和订单管理员可以看全量数据。数据隔离不是前端隐藏按钮就能解决而是在SQL查询条件里强制带上store_id拦截器从token里取出所属门店后拼入查询条件。这一条如果没做就会出现低权限用户越权访问其他门店数据的隐患。4. 设计书怎么用从文档反向审查源码的四个具体动作4.1 用功能模块清单反查Controller覆盖度设计书首页通常会画功能模块图系统管理、车辆管理、客户管理、租赁管理、结算管理、统计报表。拿这张图逐项对照Controller类大概率会发现统计报表只有两三个汇总接口结算管理里“押金退还”没有写实现。这个反查过程不是挑毛病而是理解作者的设计取舍。比如统计模块缺失通常是因为设计书写了复杂报表而作者为了赶工砍掉了如果自己接手只需要补一个简单的当日营收、在租车辆数、逾期订单数三个统计接口就能把功能清单对上。4.2 用数据字典核对表结构与注释设计书的数据字典和实际建表脚本经常不一致。差异点往往是字段名改了但注释没同步更新、类型从decimal退化成double、加了冗余字段却没写用途。用information_schema查询能快速找出所有缺失注释的字段这一步在接手任何老项目时都值得做一遍建议把输出结果存成一份名为“字段核对清单”的文档后续排错的时候直接对照。4.3 把业务规则变成测试用例矩阵设计书里的“业务规则”章节是测试用例的最好素材。比如“同一客户在同一时间段只能预订一辆车”、“车辆维护期间不能下单”、“还车时间超过计划时间两小时以上按全天计费”每一条规则都可以直接对应一个JUnit测试方法。把规则摘出来按规则编号组织成测试最后得到的不只是代码而是一份可执行的验收清单。规则编号业务规则期望行为对应测试方法R-001空闲车辆才可预订返回成功车辆状态变已预订testReserveSuccessR-002已预订车辆再次预订抛BizException状态不变化testReserveConflictR-003还车时间超过计划时间订单状态变待结算生成超时费明细testReturnWithOverdueR-004客户同时段重复下单第二单抛异常事务回滚testCannotBookOverlap4.4 用设计书验证状态流转的合法性设计书里即使没画状态图也会有文字描述“预订后不可取消、取车后进入租赁中、还车后待结算”。源码里如果只有setStatus裸调用就存在非法跳转的可能例如从“已取消”直接跳到“已完成”。处理方法是在service层建一个状态机校验private static final MapInteger, SetInteger ALLOWED_TRANSITIONS Map.of( 0, Set.of(1, 4), 1, Set.of(2, 4), 2, Set.of(3) ); public RentalOrder changeStatus(Long orderId, int targetStatus) { RentalOrder order orderMapper.selectById(orderId); SetInteger allowed ALLOWED_TRANSITIONS.get(order.getStatus()); if (!allowed.contains(targetStatus)) { throw new BizException(非法状态流转 order.getStatus() - targetStatus); } order.setStatus(targetStatus); orderMapper.updateById(order); return order; }用Map定义合法迁移路径把校验集中在一个方法里任何地方要改订单状态都必须走这里。相比在SetStatus方法里加一堆if判断这种方式扩展性更强后续加“维修中”状态只需要改Map定义。对照设计书文字描述逐条检查这个Map就能确认状态流转逻辑有没有漏。5. 从课程设计走向生产级四个值得动手的重构方向5.1 计费规则从硬编码改为配置表把超时费每小时单价、超里程每公里单价、免费里程数这些常量从代码挪到sys_config表用ConfigurationProperties加载到内存。改价不用重新发版对运营来说差异巨大。5.2 报表查询加Redis缓存统计接口如果每次都实时SUM表数据量上来后会拖垮主库。常见做法是把当日营收、车辆利用率这类指标以JSON结构存Rediskey里带日期每天凌晨用定时任务算好查询直接读缓存缓存miss才回源数据库。5.3 引入消息队列解耦还车通知还车结算完成后要发短信、推送APP通知、更新车辆清洁状态这些动作阻塞在主线程里会拉长接口响应时间。用Spring Event先做进程内解耦后续规模大了再替换成RocketMQ。还车接口只负责事务性操作其余逻辑监听事件异步执行。5.4 给核心表和接口补充压测用JMeter对预订接口做一次简单并发测试50线程同时订同一辆车观察是否出现超卖。跑完就会理解FOR UPDATE行锁在并发下的效果也能验证数据库连接池参数是否合理。压测这一步做完整个系统的健壮性心里就有底了。本文还有配套的精品资源点击获取