1. 项目定位与整体设计思路1.1 毕业设计题目的核心需求拆解先把这个题目的关键词掰开揉碎。汽车租赁系统的设计与实现本质上是要你从零搭建一套能跑的完整业务系统不是写个CRUD Demo交差。评委和导师真正想看的是你对业务流程的理解、对技术栈的把控以及工程化的落地能力。题目里给了三个关键词Java、SpringBoot、一体化系统。这意味着几个硬性要求后端必须基于Java生态SpringBoot是近几年的主流框架不用老掉牙的SSH组合系统要覆盖租赁业务全流程从车辆入库、用户下单、订单审核到还车结算得形成闭环要有完整的权限体系管理员和普通用户是两套操作入口数据隔离必须做好很多同学拿到这类题目第一反应是马上写代码这是最大的坑。我见过太多项目写到一半发现表结构设计错了、业务流程理不清回头重构浪费大量时间。正确顺序应该是先画出完整的业务流程图和数据流图再开始设计数据库最后才动手敲代码。以汽车租赁为例核心业务链其实不复杂用户注册登录、浏览车辆、下订单、管理员审核、用户取车、用车、还车、结算费用。但每个环节都会延伸出细节比如押金怎么处理、超时怎么计费、车辆状态怎么同步、订单取消后车辆何时解锁。这些细节决定了系统的实用性和完整性恰恰是评分的关键分水岭。1.2 技术选型为什么是SpringBoot而非其他技术选型这部分必须想清楚因为毕业设计答辩时老师一定会问为什么用这个不用那个。SpringBoot的核心优势是简化配置、快速启动。传统SSH框架要做一堆XML配置Spring Boot通过自动配置和起步依赖把这事儿省了这对学生党非常友好能把精力放在业务逻辑上而不是折腾配置。同时Spring Boot天然集成了Spring MVC、事务管理、数据校验这些常用组件想连数据库加个依赖就行想接权限框架也有现成的starter。前端这块方案比较灵活。要么用传统的Thymeleaf模板渲染要么做前后端分离配合Vue、React这类框架。我的建议是方案优点缺点适用场景Thymeleaf模板上手快、单体部署简单交互体验一般、前后端耦合时间紧或前端基础薄VueAxios前后端分离交互流畅、职责清晰需要额外搭前端工程有前端基础、想加分这两个方案我都实测过。如果你的主要目标是快速跑通业务逻辑、把时间留给后端实现选Thymeleaf就够了。如果想在答辩时展示工程化能力、展现项目有参考价值Vue前后端分离是更好的选择。数据库方面MySQL是标配理由不用多说稳定、免费、文档多、出问题好查。Redis要不要用如果只是毕设项目非必要不引入它会增加复杂度。当然如果做了一键缓存车辆热度和用户会话管理倒是可以提一下作为亮点。2. 数据库设计与系统架构分层2.1 实体关系梳理与建表思路数据库设计是整个系统的地基这块设计好了后面写代码一路顺畅设计不好后面每个功能都会绕着弯子走。先梳理核心实体用户、车辆、订单。围绕这三张主表衍生出一些辅助表比如车辆品牌分类、租赁价格规则、操作日志等。用户和订单一对多。一个用户可以下多个订单但一个订单只归属一个用户。车辆和订单同理会话一辆车在不同时间点会被不同的订单占用但某一时刻只能被一个有效订单绑定。订单本身要有状态字段我习惯用整数存储0-待支付、1-待审核、2-待取车、3-使用中、4-待还车、5-已完成、6-已取消。用整数比用字符串省空间程序里定义常量引用也不容易写错。另外车辆和订单之间有一种常见的库存关系。比如同一款车型有3辆车可用用户下单时是锁定具体某一辆车还是锁定车型毕设场景里建议直接锁定具体车辆简化逻辑。加一个vehicle_status字段区分空闲、已预约、使用中、维修中四个状态每次订单状态更新时联动修改车辆状态。2.2 核心表结构详解我直接给出一版我实际用过的表结构你可以当模板改。用户表CREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT 加密密码, real_name varchar(30) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, license_number varchar(30) DEFAULT NULL COMMENT 驾驶证号, role tinyint(4) NOT NULL DEFAULT 1 COMMENT 角色0-管理员 1-用户, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1-正常 0-禁用, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT系统用户表;车辆表CREATE TABLE car_info ( id bigint(20) NOT NULL AUTO_INCREMENT, car_no varchar(20) NOT NULL COMMENT 车牌号, brand varchar(30) NOT NULL COMMENT 品牌, model varchar(50) NOT NULL COMMENT 车型, color varchar(20) DEFAULT NULL, daily_rent decimal(10,2) NOT NULL COMMENT 日租金, deposit decimal(10,2) NOT NULL COMMENT 押金, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0-空闲 1-已预约 2-使用中 3-维修中, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_car_no (car_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT车辆信息表;订单表CREATE TABLE rent_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 用户ID, car_id bigint(20) NOT NULL COMMENT 车辆ID, start_date date NOT NULL COMMENT 取车日期, end_date date NOT NULL COMMENT 还车日期, total_amount decimal(10,2) NOT NULL COMMENT 订单总额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_car_id (car_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT租赁订单表;这里有几个关键细节值得专门说。订单编号不要用自增ID裸奔建议采用日期随机数的规则生成比如20250608103045开头加上随机4位。这样对外展示时不会泄露业务数据量也方便按日期定位订单。金额字段用decimal而不是float避免浮点精度问题导致对账不平。所有表都加create_time和update_time排查问题的时候好处很大。2.3 系统架构分层设计用Spring Boot做单体应用最稳妥的分层是经典的三层结构Controller、Service、Mapper。再加一个通用的实体层和工具层基本就覆盖了所有需求。com.example.rental ├── controller // 接口层 ├── service // 业务逻辑层 │ ├── impl ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 接收参数的通用对象 ├── vo // 返给前端的对象 ├── common // 统一返回体、异常处理、常量 ├── config // 配置类如安全配置、跨域配置 └── util // 工具类这套分层的意义在于把SQL操作限制在Mapper层业务逻辑写在Service层Controller只做参数接收和结果返回。好处是改动数据库时上层不受牵连改业务逻辑时不用碰SQL而且单元测试可以单独针对Service层写不用启动整个应用。还有两个跨层设计值得注意。第一是统一返回体我定义一个Result类包code、message、data三个字段所有接口都返回这个结构前端处理起来非常统一。第二是全局异常处理器用RestControllerAdvice把业务异常统一转成友好的错误提示不要一报错就抛出500堆栈给前端看。3. 核心功能实现与实操要点3.1 用户登录与权限控制的落地登录逻辑看起来简单实际上有几个隐藏的坑。首先是密码存储绝对不能明文入库用BCrypt做加盐哈希。Spring Security或Sa-Token都自带BCrypt实现不用自己手写加密算法。我踩过的坑一开始用MD5加固定盐后来发现盐值如果泄露撞库还是很容易。换成BCrypt之后每次哈希值都不同但校验结果一致安全性明显上一个台阶。毕业设计里主动提这一点是一个加分项。会话控制我用的是Sa-Token框架相比Spring Security配置量几乎为零只需三行代码就能搞定登录和鉴权。示例// 登录成功之后给用户签发令牌 StpUtil.login(user.getId()); // 在需要管理员权限的接口上直接加注解 SaCheckRole(admin) GetMapping(/admin/car/list) public Result getCarList() { // 只有管理员才能访问 }登录时当然还要做状态校验比如用户被禁用时不允许登录。前端存储令牌用localStorage即可后端每次请求时从请求头里取出token通过框架自动完成身份识别。权限设计的核心是把接口权限和前端显示分开控制。后端必须做真实的权限校验不能因为前端不显示按钮就把后端校验省略掉。比如用户访问管理员接口后端必须拒绝。我见过一些项目前端隐藏了入口就认为安全了这是典型的安全认知错误。3.2 车辆管理模块的实现细节车辆管理是管理员的日常工作台包含车辆的增删改查、上下架、维修状态设置。这块本身不复杂但有几个细节决定了体验。车辆列表接口一定要支持分页和条件筛选。分页用PageHelper或者MyBatis-Plus的分页插件都行关键是条件筛选参数要设计全面品牌、车型、状态、价格区间。实际使用中我发现省去筛选条件管理系统会变得非常难用尤其是车辆数量超过几十辆之后。新增和修改车辆时车牌号必须做唯一性校验。校验时机要放在Controller层之前也就是Service层先查一遍再传回提示。不要依赖数据库唯一索引报错后捕获异常那是一种很粗鲁的处理方式。合理的处理是Override public Result addCar(CarRequestDTO dto) { CarInfo existing carMapper.findByCarNo(dto.getCarNo()); if (existing ! null) { return Result.error(车牌号已存在); } // 继续新增逻辑 }车辆图片上传也是常见需求。毕设里不要造轮子直接用本地存储把文件放在项目指定的upload目录然后把相对路径存到数据库。需要注意文件类型校验和大小限制禁止上传.exe或超大文件Controller方法里做一层拦截即可。3.3 租赁订单全流程的实现要点订单模块是系统的核心也是最容易出逻辑漏洞的地方。我把整个流程按状态驱动来设计每个状态对应一组可执行操作。理顺了这个状态机写代码时就非常清晰。我设计的状态及对应操作如下状态含义可执行操作0待支付用户支付押金租金然后进入待审核1待审核管理员审核通过后车辆锁定进入待取车2待取车用户在预约日期前到店取车管理员确认后进入使用中3使用中车辆在用户手中到期前提示续租或还车4待还车用户发起还车申请管理员验车结算退款押金5已完成订单闭环结束6已取消用户取消或管理员驳回取消这里有两个关键策略需要讲清楚。第一车辆状态和订单状态必须联动。用户下单并支付后车辆状态应立即从空闲变为已预约防止其他人再对该车下单。订单进入使用中时车辆改为使用中。订单完成或取消时车辆回退为空闲或维修中。这个联动逻辑写在Service层里不使用数据库触发器这样思路更清晰也方便调试。第二金额计算的准确性。租金计算规则是总价 日租金乘天数。天数计算要注意跨月问题用LocalDate计算两个日期差不要用时间戳除以86400000这种方式因为夏令时或者毫秒差可能导致误差。long days ChronoUnit.DAYS.between(startDate, endDate); BigDecimal totalAmount car.getDailyRent() .multiply(BigDecimal.valueOf(days));如果租期内发生超时还车需要额外的超时费计算逻辑。这个可以根据业务规则单独扩展一张费用明细表记录每笔费用的产生原因和金额方便对账。4. 关键业务难点拆解与工程优化4.1 并发选车与数据一致性最常见的并发场景两个用户同时看上了同一辆车同时提交订单。如果不加控制两人可能都下单成功但车只有一辆业务就乱了。解决思路是在数据库层面做行锁也就是在用户确认下单的Service方法上通过悲观锁或乐观锁处理。我用的是简化方案在车辆状态更新时加上条件判断通过UPDATE语句直接影响的行数来判断是否抢车成功。int updated carMapper.lockCar(carId, CarStatus.FREE, CarStatus.BOOKED); if (updated 0) { throw new BusinessException(车辆已被预订请选择其他车辆); }对应SQLUPDATE car_info SET status #{newStatus} WHERE id #{carId} AND status #{oldStatus}这种写法的好处是原子性由数据库保证应用层代码无需显式加锁逆误操作时又安全又高效。项目答辩时如果能讲清楚这个方案的原理和为什么不用应用层锁技术深度就很直观了。4.2 事务边界控制与回滚在创建订单的过程中会涉及多个表的写操作插入订单记录、锁定车辆、扣减用户账户余额或记录流水。这些操作必须放在同一个事务里任何一个失败都能全部回滚否则会出现订单存在但车辆未锁定的脏数据。Spring Boot里用Transactional注解即可但要注意几个细节。第一个细节是事务的边界要放在正确的方法上。一个Service方法包含全部跨表操作时直接在方法上加注解。不要在Controller方法上加因为Controller通常不应该承载事务逻辑。第二个细节是事务内不要捕获异常后吞掉。如果自己捕获了异常不重新抛出Spring就无法触发回滚。正确的做法是捕获后抛出RuntimeException或其子类也可以指定rollbackFor字段。第三个容易被忽略的是自调用问题。同一个类里的方法A调用方法B如果A没加事务注解而B加了B的事务会失效因为事务是通过代理对象生效的内部调用不会走代理。我把事务相关的操作都拆到独立的Service类里从Controller层调用就是为了绕开这个坑。4.3 数据校验与业务规则校验校验分两层基础格式校验和业务规则校验。基础格式校验用JSR 303注解即可比如NotBlank、Email、Pattern。放在DTO类字段上Controller方法参数上加上Validated就能自动生效。比如用户注册时手机号格式、身份证号长度都属于这一层。业务规则校验则要写在Service层比如下单时校验取车日期不能早于今天、还车日期必须晚于取车日期、用户驾驶证状态是否正常、是否存在未完成的订单。这些规则是系统能正常运转的保障漏掉任何一条线上都会被用户钻空子。具体来说校验还车日期时if (dto.getStartDate().isBefore(LocalDate.now())) { throw new BusinessException(取车日期不能早于今天); } if (dto.getEndDate().isBefore(dto.getStartDate())) { throw new BusinessException(还车日期必须晚于取车日期); }注意这里不能用后端校验替代前端校验也不能用前端校验替代后端校验。前端校验是为了用户体验后端校验才是安全的根本。我在实践中见过一个项目下单接口没有校验用户黑名单状态被刷了一堆无效订单整个后台列表肉眼可见地卡顿。这个教训值得写进文档提醒后人。5. 前后端交互设计与管理端页面5.1 接口设计规范与统一返回体接口设计不只是一个技术问题还是一个可维护性问题。前后端分离架构下接口规范能直接决定团队协作效率哪怕这个项目只有你一个人写三个月后回来看代码照样感激当时的自己。我定的规范包含几个部分。路径规划上以/api为前缀按模块划分比如/api/user、/api/car、/api/order。不要混用动词GET表示查询、POST表示新增或提交、PUT表示更新、DELETE表示删除。统一返回体刚才提过这里展开说一下具体结构public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端Axios响应拦截器里统一判断code是否为200非200则弹出错误提示。这样后端不需要每个接口各写一套错误处理逻辑全局异常处理器捕获异常后统一调用Result.error()即可。5.2 管理端和用户端的功能划分用户端和管理端虽然共用一套后端服务但功能侧重完全不同。用户端核心是注册登录、浏览车辆、查看详情、下单支付、查看订单列表、申请还车、取消订单、个人中心。界面要求简洁直观车辆列表支持按价格排序、品牌筛选车辆详情页突出展示租金、押金、车辆配置。管理端功能就更重了仪表盘统计车辆总数、今日订单数、营收总额、车辆管理、订单审核、还车验车、用户管理、费用结算。管理端的数据展示逻辑要清晰订单审核列表要包含完整的关键信息方便管理员快速判断。我建议管理端做一个简单的数据统计页就是几张大数字卡片加一个柱状图用ECharts画图展示近7天订单量趋势。这个页面的技术门槛不高但能在答辩时直观体现系统的完整性属于低成本高回报的功能点。6. 测试方案、常见问题与答辩经验6.1 功能测试要点与测试数据准备很多毕业设计都卡在测试这一关。所谓测通了不是打开浏览器点两下就算而是要覆盖核心业务链路和边界场景。我建议至少准备三组测试数据一组正常数据、一组业务边界数据、一组非法数据。正常数据注册一个用户下单租车走完整个流程直到还车退款。边界数据还车日期等于取车日期租金是否只算一天可租车辆只剩一辆时两个账号连续下单是否只有一人成功用户取消已审核订单车辆是否正确释放。非法数据车牌号重复、手机号格式错误、订单金额为负数、未登录访问订单接口。这些测试用例正好对应了业务规则校验是否完善也是答辩时评委最爱口头问的点。测试时我习惯手动测完核心链路后再用Postman导出一份接口测试集把每个接口的请求和断言记录下来。这份测试集用于答辩演示时非常有说服力也比口头说我都测过了更具体。6.2 常见问题排查与避坑手册写代码过程中踩过的坑我整理了一份速查表每个问题都是实际发生过的值得你提前避开常见问题原因分析解决方案登录接口返回406返回对象缺少无参构造方法确保DTO和VO类有无参构造日期字段前后端差8小时时区不一致application.yml中配置Jackson时区上传图片404静态资源映射未配置添加WebMvcConfigurer映射虚拟路径分页查询数据重复排序字段不唯一orderBy改为id desc和create_time接口返回大字段卡顿关联查询全表扫描添加索引并优化SQL修改车辆状态不生效乐观锁条件错误检查UPDATE影响行数是否为1这里展开说一下日期差8小时的问题很多人踩了但没搞明白。Spring Boot默认的JSON序列化会把LocalDateTime转成UTC格式前端解析后看到的时间比数据库存储的时间少8小时。解决办法是在application.yml里配置spring: jackson: time-zone: GMT8 date-format: yyyy-MM-dd HH:mm:ss还有一个经常被忽视的问题是数据库连接的编码MySQL连接串要加characterEncodingUTF-8和useSSLfalse。否则中文乱码和维护连接时SSL握手报错会来回折腾人。6.3 答辩演示与项目讲解要点系统做完了最后一步是答辩演示。我观察过很多同学的答辩现场发现系统做得很好但讲得混乱特别可惜。讲解的主线应该围绕业务闭环展开不要一头扎进代码细节。开场先讲清楚系统是什么、解决什么问题、技术栈怎么选的然后按用户端到管理端的顺序带着评委走一条完整业务主线注册登录、浏览车辆、下单支付、管理员审核、取车使用、还车结算。演示时要刻意展示几个亮点操作。第一个是并发抢车的效果开着两个浏览器同时下单同一辆车展示只有一个成功。第二个是异常处理的友好提示比如车辆已被预订时展示明文提示。第三个是全局权限控制用普通用户登录后直接输入管理端URL展示被拦截效果。答辩提炼技术亮点时我建议从这几个方向切入状态机驱动的租车流程设计、数据库行级锁解决并发冲突、事务保证跨表数据一致性、统一异常处理与全局响应规范。把每个点的为什么想清楚答辩时就不怕追问了。最后再分享一条实际体会这套系统的核心价值不只是能用而是你完整走了一遍需求分析、数据库设计、接口定义、功能实现、测试部署的全流程。做完之后你把项目里用到的设计思路沉淀下来以后做任何管理类系统基本都能快速套用。我是做完这个项目之后才真正体会到SpringBoot不只是一个框架更是一种组织业务逻辑的思路。
1. 项目定位与整体设计思路1.1 毕业设计题目的核心需求拆解先把这个题目的关键词掰开揉碎。汽车租赁系统的设计与实现本质上是要你从零搭建一套能跑的完整业务系统不是写个CRUD Demo交差。评委和导师真正想看的是你对业务流程的理解、对技术栈的把控以及工程化的落地能力。题目里给了三个关键词Java、SpringBoot、一体化系统。这意味着几个硬性要求后端必须基于Java生态SpringBoot是近几年的主流框架不用老掉牙的SSH组合系统要覆盖租赁业务全流程从车辆入库、用户下单、订单审核到还车结算得形成闭环要有完整的权限体系管理员和普通用户是两套操作入口数据隔离必须做好很多同学拿到这类题目第一反应是马上写代码这是最大的坑。我见过太多项目写到一半发现表结构设计错了、业务流程理不清回头重构浪费大量时间。正确顺序应该是先画出完整的业务流程图和数据流图再开始设计数据库最后才动手敲代码。以汽车租赁为例核心业务链其实不复杂用户注册登录、浏览车辆、下订单、管理员审核、用户取车、用车、还车、结算费用。但每个环节都会延伸出细节比如押金怎么处理、超时怎么计费、车辆状态怎么同步、订单取消后车辆何时解锁。这些细节决定了系统的实用性和完整性恰恰是评分的关键分水岭。1.2 技术选型为什么是SpringBoot而非其他技术选型这部分必须想清楚因为毕业设计答辩时老师一定会问为什么用这个不用那个。SpringBoot的核心优势是简化配置、快速启动。传统SSH框架要做一堆XML配置Spring Boot通过自动配置和起步依赖把这事儿省了这对学生党非常友好能把精力放在业务逻辑上而不是折腾配置。同时Spring Boot天然集成了Spring MVC、事务管理、数据校验这些常用组件想连数据库加个依赖就行想接权限框架也有现成的starter。前端这块方案比较灵活。要么用传统的Thymeleaf模板渲染要么做前后端分离配合Vue、React这类框架。我的建议是方案优点缺点适用场景Thymeleaf模板上手快、单体部署简单交互体验一般、前后端耦合时间紧或前端基础薄VueAxios前后端分离交互流畅、职责清晰需要额外搭前端工程有前端基础、想加分这两个方案我都实测过。如果你的主要目标是快速跑通业务逻辑、把时间留给后端实现选Thymeleaf就够了。如果想在答辩时展示工程化能力、展现项目有参考价值Vue前后端分离是更好的选择。数据库方面MySQL是标配理由不用多说稳定、免费、文档多、出问题好查。Redis要不要用如果只是毕设项目非必要不引入它会增加复杂度。当然如果做了一键缓存车辆热度和用户会话管理倒是可以提一下作为亮点。2. 数据库设计与系统架构分层2.1 实体关系梳理与建表思路数据库设计是整个系统的地基这块设计好了后面写代码一路顺畅设计不好后面每个功能都会绕着弯子走。先梳理核心实体用户、车辆、订单。围绕这三张主表衍生出一些辅助表比如车辆品牌分类、租赁价格规则、操作日志等。用户和订单一对多。一个用户可以下多个订单但一个订单只归属一个用户。车辆和订单同理会话一辆车在不同时间点会被不同的订单占用但某一时刻只能被一个有效订单绑定。订单本身要有状态字段我习惯用整数存储0-待支付、1-待审核、2-待取车、3-使用中、4-待还车、5-已完成、6-已取消。用整数比用字符串省空间程序里定义常量引用也不容易写错。另外车辆和订单之间有一种常见的库存关系。比如同一款车型有3辆车可用用户下单时是锁定具体某一辆车还是锁定车型毕设场景里建议直接锁定具体车辆简化逻辑。加一个vehicle_status字段区分空闲、已预约、使用中、维修中四个状态每次订单状态更新时联动修改车辆状态。2.2 核心表结构详解我直接给出一版我实际用过的表结构你可以当模板改。用户表CREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录名, password varchar(100) NOT NULL COMMENT 加密密码, real_name varchar(30) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, license_number varchar(30) DEFAULT NULL COMMENT 驾驶证号, role tinyint(4) NOT NULL DEFAULT 1 COMMENT 角色0-管理员 1-用户, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1-正常 0-禁用, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT系统用户表;车辆表CREATE TABLE car_info ( id bigint(20) NOT NULL AUTO_INCREMENT, car_no varchar(20) NOT NULL COMMENT 车牌号, brand varchar(30) NOT NULL COMMENT 品牌, model varchar(50) NOT NULL COMMENT 车型, color varchar(20) DEFAULT NULL, daily_rent decimal(10,2) NOT NULL COMMENT 日租金, deposit decimal(10,2) NOT NULL COMMENT 押金, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0-空闲 1-已预约 2-使用中 3-维修中, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_car_no (car_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT车辆信息表;订单表CREATE TABLE rent_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 用户ID, car_id bigint(20) NOT NULL COMMENT 车辆ID, start_date date NOT NULL COMMENT 取车日期, end_date date NOT NULL COMMENT 还车日期, total_amount decimal(10,2) NOT NULL COMMENT 订单总额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 订单状态, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_car_id (car_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT租赁订单表;这里有几个关键细节值得专门说。订单编号不要用自增ID裸奔建议采用日期随机数的规则生成比如20250608103045开头加上随机4位。这样对外展示时不会泄露业务数据量也方便按日期定位订单。金额字段用decimal而不是float避免浮点精度问题导致对账不平。所有表都加create_time和update_time排查问题的时候好处很大。2.3 系统架构分层设计用Spring Boot做单体应用最稳妥的分层是经典的三层结构Controller、Service、Mapper。再加一个通用的实体层和工具层基本就覆盖了所有需求。com.example.rental ├── controller // 接口层 ├── service // 业务逻辑层 │ ├── impl ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 接收参数的通用对象 ├── vo // 返给前端的对象 ├── common // 统一返回体、异常处理、常量 ├── config // 配置类如安全配置、跨域配置 └── util // 工具类这套分层的意义在于把SQL操作限制在Mapper层业务逻辑写在Service层Controller只做参数接收和结果返回。好处是改动数据库时上层不受牵连改业务逻辑时不用碰SQL而且单元测试可以单独针对Service层写不用启动整个应用。还有两个跨层设计值得注意。第一是统一返回体我定义一个Result类包code、message、data三个字段所有接口都返回这个结构前端处理起来非常统一。第二是全局异常处理器用RestControllerAdvice把业务异常统一转成友好的错误提示不要一报错就抛出500堆栈给前端看。3. 核心功能实现与实操要点3.1 用户登录与权限控制的落地登录逻辑看起来简单实际上有几个隐藏的坑。首先是密码存储绝对不能明文入库用BCrypt做加盐哈希。Spring Security或Sa-Token都自带BCrypt实现不用自己手写加密算法。我踩过的坑一开始用MD5加固定盐后来发现盐值如果泄露撞库还是很容易。换成BCrypt之后每次哈希值都不同但校验结果一致安全性明显上一个台阶。毕业设计里主动提这一点是一个加分项。会话控制我用的是Sa-Token框架相比Spring Security配置量几乎为零只需三行代码就能搞定登录和鉴权。示例// 登录成功之后给用户签发令牌 StpUtil.login(user.getId()); // 在需要管理员权限的接口上直接加注解 SaCheckRole(admin) GetMapping(/admin/car/list) public Result getCarList() { // 只有管理员才能访问 }登录时当然还要做状态校验比如用户被禁用时不允许登录。前端存储令牌用localStorage即可后端每次请求时从请求头里取出token通过框架自动完成身份识别。权限设计的核心是把接口权限和前端显示分开控制。后端必须做真实的权限校验不能因为前端不显示按钮就把后端校验省略掉。比如用户访问管理员接口后端必须拒绝。我见过一些项目前端隐藏了入口就认为安全了这是典型的安全认知错误。3.2 车辆管理模块的实现细节车辆管理是管理员的日常工作台包含车辆的增删改查、上下架、维修状态设置。这块本身不复杂但有几个细节决定了体验。车辆列表接口一定要支持分页和条件筛选。分页用PageHelper或者MyBatis-Plus的分页插件都行关键是条件筛选参数要设计全面品牌、车型、状态、价格区间。实际使用中我发现省去筛选条件管理系统会变得非常难用尤其是车辆数量超过几十辆之后。新增和修改车辆时车牌号必须做唯一性校验。校验时机要放在Controller层之前也就是Service层先查一遍再传回提示。不要依赖数据库唯一索引报错后捕获异常那是一种很粗鲁的处理方式。合理的处理是Override public Result addCar(CarRequestDTO dto) { CarInfo existing carMapper.findByCarNo(dto.getCarNo()); if (existing ! null) { return Result.error(车牌号已存在); } // 继续新增逻辑 }车辆图片上传也是常见需求。毕设里不要造轮子直接用本地存储把文件放在项目指定的upload目录然后把相对路径存到数据库。需要注意文件类型校验和大小限制禁止上传.exe或超大文件Controller方法里做一层拦截即可。3.3 租赁订单全流程的实现要点订单模块是系统的核心也是最容易出逻辑漏洞的地方。我把整个流程按状态驱动来设计每个状态对应一组可执行操作。理顺了这个状态机写代码时就非常清晰。我设计的状态及对应操作如下状态含义可执行操作0待支付用户支付押金租金然后进入待审核1待审核管理员审核通过后车辆锁定进入待取车2待取车用户在预约日期前到店取车管理员确认后进入使用中3使用中车辆在用户手中到期前提示续租或还车4待还车用户发起还车申请管理员验车结算退款押金5已完成订单闭环结束6已取消用户取消或管理员驳回取消这里有两个关键策略需要讲清楚。第一车辆状态和订单状态必须联动。用户下单并支付后车辆状态应立即从空闲变为已预约防止其他人再对该车下单。订单进入使用中时车辆改为使用中。订单完成或取消时车辆回退为空闲或维修中。这个联动逻辑写在Service层里不使用数据库触发器这样思路更清晰也方便调试。第二金额计算的准确性。租金计算规则是总价 日租金乘天数。天数计算要注意跨月问题用LocalDate计算两个日期差不要用时间戳除以86400000这种方式因为夏令时或者毫秒差可能导致误差。long days ChronoUnit.DAYS.between(startDate, endDate); BigDecimal totalAmount car.getDailyRent() .multiply(BigDecimal.valueOf(days));如果租期内发生超时还车需要额外的超时费计算逻辑。这个可以根据业务规则单独扩展一张费用明细表记录每笔费用的产生原因和金额方便对账。4. 关键业务难点拆解与工程优化4.1 并发选车与数据一致性最常见的并发场景两个用户同时看上了同一辆车同时提交订单。如果不加控制两人可能都下单成功但车只有一辆业务就乱了。解决思路是在数据库层面做行锁也就是在用户确认下单的Service方法上通过悲观锁或乐观锁处理。我用的是简化方案在车辆状态更新时加上条件判断通过UPDATE语句直接影响的行数来判断是否抢车成功。int updated carMapper.lockCar(carId, CarStatus.FREE, CarStatus.BOOKED); if (updated 0) { throw new BusinessException(车辆已被预订请选择其他车辆); }对应SQLUPDATE car_info SET status #{newStatus} WHERE id #{carId} AND status #{oldStatus}这种写法的好处是原子性由数据库保证应用层代码无需显式加锁逆误操作时又安全又高效。项目答辩时如果能讲清楚这个方案的原理和为什么不用应用层锁技术深度就很直观了。4.2 事务边界控制与回滚在创建订单的过程中会涉及多个表的写操作插入订单记录、锁定车辆、扣减用户账户余额或记录流水。这些操作必须放在同一个事务里任何一个失败都能全部回滚否则会出现订单存在但车辆未锁定的脏数据。Spring Boot里用Transactional注解即可但要注意几个细节。第一个细节是事务的边界要放在正确的方法上。一个Service方法包含全部跨表操作时直接在方法上加注解。不要在Controller方法上加因为Controller通常不应该承载事务逻辑。第二个细节是事务内不要捕获异常后吞掉。如果自己捕获了异常不重新抛出Spring就无法触发回滚。正确的做法是捕获后抛出RuntimeException或其子类也可以指定rollbackFor字段。第三个容易被忽略的是自调用问题。同一个类里的方法A调用方法B如果A没加事务注解而B加了B的事务会失效因为事务是通过代理对象生效的内部调用不会走代理。我把事务相关的操作都拆到独立的Service类里从Controller层调用就是为了绕开这个坑。4.3 数据校验与业务规则校验校验分两层基础格式校验和业务规则校验。基础格式校验用JSR 303注解即可比如NotBlank、Email、Pattern。放在DTO类字段上Controller方法参数上加上Validated就能自动生效。比如用户注册时手机号格式、身份证号长度都属于这一层。业务规则校验则要写在Service层比如下单时校验取车日期不能早于今天、还车日期必须晚于取车日期、用户驾驶证状态是否正常、是否存在未完成的订单。这些规则是系统能正常运转的保障漏掉任何一条线上都会被用户钻空子。具体来说校验还车日期时if (dto.getStartDate().isBefore(LocalDate.now())) { throw new BusinessException(取车日期不能早于今天); } if (dto.getEndDate().isBefore(dto.getStartDate())) { throw new BusinessException(还车日期必须晚于取车日期); }注意这里不能用后端校验替代前端校验也不能用前端校验替代后端校验。前端校验是为了用户体验后端校验才是安全的根本。我在实践中见过一个项目下单接口没有校验用户黑名单状态被刷了一堆无效订单整个后台列表肉眼可见地卡顿。这个教训值得写进文档提醒后人。5. 前后端交互设计与管理端页面5.1 接口设计规范与统一返回体接口设计不只是一个技术问题还是一个可维护性问题。前后端分离架构下接口规范能直接决定团队协作效率哪怕这个项目只有你一个人写三个月后回来看代码照样感激当时的自己。我定的规范包含几个部分。路径规划上以/api为前缀按模块划分比如/api/user、/api/car、/api/order。不要混用动词GET表示查询、POST表示新增或提交、PUT表示更新、DELETE表示删除。统一返回体刚才提过这里展开说一下具体结构public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端Axios响应拦截器里统一判断code是否为200非200则弹出错误提示。这样后端不需要每个接口各写一套错误处理逻辑全局异常处理器捕获异常后统一调用Result.error()即可。5.2 管理端和用户端的功能划分用户端和管理端虽然共用一套后端服务但功能侧重完全不同。用户端核心是注册登录、浏览车辆、查看详情、下单支付、查看订单列表、申请还车、取消订单、个人中心。界面要求简洁直观车辆列表支持按价格排序、品牌筛选车辆详情页突出展示租金、押金、车辆配置。管理端功能就更重了仪表盘统计车辆总数、今日订单数、营收总额、车辆管理、订单审核、还车验车、用户管理、费用结算。管理端的数据展示逻辑要清晰订单审核列表要包含完整的关键信息方便管理员快速判断。我建议管理端做一个简单的数据统计页就是几张大数字卡片加一个柱状图用ECharts画图展示近7天订单量趋势。这个页面的技术门槛不高但能在答辩时直观体现系统的完整性属于低成本高回报的功能点。6. 测试方案、常见问题与答辩经验6.1 功能测试要点与测试数据准备很多毕业设计都卡在测试这一关。所谓测通了不是打开浏览器点两下就算而是要覆盖核心业务链路和边界场景。我建议至少准备三组测试数据一组正常数据、一组业务边界数据、一组非法数据。正常数据注册一个用户下单租车走完整个流程直到还车退款。边界数据还车日期等于取车日期租金是否只算一天可租车辆只剩一辆时两个账号连续下单是否只有一人成功用户取消已审核订单车辆是否正确释放。非法数据车牌号重复、手机号格式错误、订单金额为负数、未登录访问订单接口。这些测试用例正好对应了业务规则校验是否完善也是答辩时评委最爱口头问的点。测试时我习惯手动测完核心链路后再用Postman导出一份接口测试集把每个接口的请求和断言记录下来。这份测试集用于答辩演示时非常有说服力也比口头说我都测过了更具体。6.2 常见问题排查与避坑手册写代码过程中踩过的坑我整理了一份速查表每个问题都是实际发生过的值得你提前避开常见问题原因分析解决方案登录接口返回406返回对象缺少无参构造方法确保DTO和VO类有无参构造日期字段前后端差8小时时区不一致application.yml中配置Jackson时区上传图片404静态资源映射未配置添加WebMvcConfigurer映射虚拟路径分页查询数据重复排序字段不唯一orderBy改为id desc和create_time接口返回大字段卡顿关联查询全表扫描添加索引并优化SQL修改车辆状态不生效乐观锁条件错误检查UPDATE影响行数是否为1这里展开说一下日期差8小时的问题很多人踩了但没搞明白。Spring Boot默认的JSON序列化会把LocalDateTime转成UTC格式前端解析后看到的时间比数据库存储的时间少8小时。解决办法是在application.yml里配置spring: jackson: time-zone: GMT8 date-format: yyyy-MM-dd HH:mm:ss还有一个经常被忽视的问题是数据库连接的编码MySQL连接串要加characterEncodingUTF-8和useSSLfalse。否则中文乱码和维护连接时SSL握手报错会来回折腾人。6.3 答辩演示与项目讲解要点系统做完了最后一步是答辩演示。我观察过很多同学的答辩现场发现系统做得很好但讲得混乱特别可惜。讲解的主线应该围绕业务闭环展开不要一头扎进代码细节。开场先讲清楚系统是什么、解决什么问题、技术栈怎么选的然后按用户端到管理端的顺序带着评委走一条完整业务主线注册登录、浏览车辆、下单支付、管理员审核、取车使用、还车结算。演示时要刻意展示几个亮点操作。第一个是并发抢车的效果开着两个浏览器同时下单同一辆车展示只有一个成功。第二个是异常处理的友好提示比如车辆已被预订时展示明文提示。第三个是全局权限控制用普通用户登录后直接输入管理端URL展示被拦截效果。答辩提炼技术亮点时我建议从这几个方向切入状态机驱动的租车流程设计、数据库行级锁解决并发冲突、事务保证跨表数据一致性、统一异常处理与全局响应规范。把每个点的为什么想清楚答辩时就不怕追问了。最后再分享一条实际体会这套系统的核心价值不只是能用而是你完整走了一遍需求分析、数据库设计、接口定义、功能实现、测试部署的全流程。做完之后你把项目里用到的设计思路沉淀下来以后做任何管理类系统基本都能快速套用。我是做完这个项目之后才真正体会到SpringBoot不只是一个框架更是一种组织业务逻辑的思路。
