做毕设辅导这些年看到汽车租赁管理系统这个题目几乎是“常青树”一般的存在。每年都有学生选它原因不难理解车辆、用户、订单、租金这几样核心对象正好把增删改查练透又比图书管理多了一层业务状态流转工作量适中做完之后答辩也有东西可讲。这里我以个人带过的真实项目为蓝本把架构思路、核心表设计、关键代码、运行配置以及被问得最多的几个问题一次性说透希望对正在选题目或者已经开题的同学有实际帮助。这个题目适合谁如果你的 Java 基础不算扎实又想稳扎稳打做一个能跑、能演示、能讲清逻辑的系统它就是非常合适的选项。技术栈锁定在 Spring Boot、MySQL、MyBatis 三件套不碰分布式、不碰微服务但又能把主流开发的流程完整走一遍。整套系统做下来你对三层架构的理解、对数据库设计的敏感度、对接口调试的熟练度都会有肉眼可见的提升。1. 项目解读与选型思路1.1 这个毕设到底要解决什么问题汽车租赁管理系统最核心的业务就一句话用户选车、下单租车、到期还车、管理员管车。听起来简单但把这句话拆开里面藏着不少设计点。先说用户侧用户需要注册、登录、浏览车辆列表、查看车辆详情、按品牌或价格筛选车辆、提交租车订单、支付毕设里一般做成模拟支付或线下支付、查询自己的订单记录、取消未开始的订单。这些功能覆盖了最基本的 CRUD也带一点状态判断。再看向管理员侧管理员要维护车辆信息新增、修改、下架、标记维修、审核订单、处理还车操作、查看所有用户订单、统计经营数据比如订单数、营收金额。这些功能比用户端更考验数据表关系的设计能力。所以这个题目不是简单的“表格增删改查”而是需要你把一个完整业务闭环跑通车辆状态和订单状态互相联动价格计算要准确用户和管理员权限要有区别。这也是它比图书管理这类题目高级一点的地方。1.2 为什么挑 Spring Boot MySQL MyBatis 这套组合很多学生在选技术栈的时候会纠结到底是 Spring Boot 还是 SSM是 MyBatis 还是 JPA数据库用 MySQL 还是要用别的。我通常建议就选 Spring Boot MySQL MyBatis理由非常现实。第一Spring Boot 是目前企业级开发的绝对主流毕设写这个答辩老师不会有任何异议。它把 Spring 的繁琐配置封装掉了一个启动类就能跑起 Web 服务对学生来说学习成本低、上手快。第二MyBatis 的优势在于 SQL 可控。汽车租赁系统里有很多动态查询需求比如管理员按车辆品牌、日租价格区间、状态筛选车辆用户按可用时间查看空闲车辆这些用 MyBatis 的动态 SQL 写起来非常自然也不用担心自动生成的 SQL 性能不好。第三MySQL 免费、开源、资料多而且这门课大多数学校都开过。用它做数据库遇到问题一搜就能搜到答案不至于在环境上卡太久。这三者组合起来形成了一条非常清晰的链路前端页面请求 - Spring Boot 的 Controller 接收 - Service 处理业务 - Mapper 通过 MyBatis 操作 MySQL。每一层职责单一写起来顺手答辩时也方便讲原理。1.3 这个系统设计上怎么保持“说得清、做得完”毕设最怕的就是做的时候很嗨写论文和答辩时讲不出所以然。汽车租赁管理系统的好处是业务流程天然带有状态机车辆是空闲还是已租订单是待支付还是进行中这些状态可以用一个数字字段表达然后统一维护状态流转逻辑。我设计项目时尽量遵循几个原则Controller 只做参数接收和结果返回不写业务逻辑。Service 层承担业务规则判断比如“车辆是否空闲”“租期是否合法”。Mapper 层只做数据读写SQL 写在 XML 里方便审计和复用。状态字段用数字表示并加注释说明含义比如 0 空闲、1 已租、2 维修。这套分层逻辑不仅是编码规范更是论文里“系统设计”章节的素材。你把每一层的作用写清楚再加上类图、时序图论文的核心章节就有内容了。2. 系统功能与数据库设计2.1 用户端与管理端的角色拆解在设计角色时我建议用一个字段区分用户和管理员而不是单独建两张用户表。字段 role 用 0 表示普通用户1 表示管理员。登录时根据角色跳转到不同的首页后端接口用拦截器校验角色即可。用户端功能集合注册、登录、退出登录。密码不要明文存用 BCrypt 加密。车辆列表页支持按品牌、日租价格区间筛选分页展示。车辆详情页展示车辆基本信息、日租价格、所属门店如果有的话、当前状态。提交租车订单选择起止日期后端自动计算天数和总金额。我的订单分页查询当前用户的订单按状态区分可取消未开始的订单。还车后评价可选加分项简单评价打分作为表关系的一个扩展。管理端功能集合车辆管理新增车辆、编辑车辆信息、删除车辆、标记维修/上架/下架。订单管理查看所有订单处理还车查看订单详情。用户管理查看注册用户列表禁用恶意用户可选。数据统计统计总订单数、总营收、各车辆被租次数。用几条聚合 SQL 就能实现。这里有一条重要经验功能宁可少而精不要多而糙。很多同学喜欢堆功能结果每个功能都做不深一答辩就露馅。把上面这些功能做扎实系统已经相当完整了。2.2 核心业务流程拆解整个系统最关键的流程是下单租车我把它拆成六个步骤用户登录前端带上 token 或 session。用户选择车辆选择起始日期和结束日期。后端校验车辆存在且状态是空闲。后端计算租车天数乘以日租价格得到总金额。生成订单初始状态为待支付。将车辆状态改为已租出。还车流程则反过来管理员选择一条进行中的订单。校验订单确实是进行中状态。修改订单状态为已完成。将对应车辆状态改为空闲。记录归还时间用于计算实际租期。这套流程里面的订单状态流转是答辩时的加分点一定要能讲清楚待支付、进行中、已完成、已取消这四种状态不是随意跳转的而是有方向的。取消只能发生在待支付或进行中但还未取车的阶段完成只能从进行中进入。把这些规则写清楚说明你考虑了业务合理性。2.3 数据库表设计直接把建表语句抄走数据库是整个系统的地基表设计得好后期写代码能省一半力气。我习惯用五张表用户表、车辆表、订单表外加门店表和评价表看需求选加。用户表设计如下CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT 密码(BCrypt加密), real_name VARCHAR(50) COMMENT 真实姓名, phone VARCHAR(20) COMMENT 手机号, role TINYINT DEFAULT 0 COMMENT 角色:0用户,1管理员, status TINYINT DEFAULT 1 COMMENT 状态:1正常,0禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间 );车辆表需要体现租车业务的特殊性车牌号要唯一日租价格用 DECIMAL 避免浮点精度问题CREATE TABLE t_car ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, brand VARCHAR(30) COMMENT 品牌, model VARCHAR(50) COMMENT 车型, plate_number VARCHAR(20) NOT NULL UNIQUE COMMENT 车牌号, daily_price DECIMAL(10,2) NOT NULL COMMENT 日租价格, status TINYINT DEFAULT 0 COMMENT 状态:0空闲,1已租,2维修, pic_url VARCHAR(255) COMMENT 车辆图片地址, description TEXT COMMENT 车辆描述, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 录入时间 );订单表是业务核心外键关联用户和车辆同时冗余了车辆型号和日租价格快照。这里有个细节要注意车辆价格后续可能涨价或降价但已生成的订单总价不能跟着变所以要冗余记录下单时的车型和价格CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 订单编号, user_id INT NOT NULL COMMENT 下单用户ID, car_id INT NOT NULL COMMENT 车辆ID, car_model VARCHAR(50) COMMENT 车型快照, daily_price DECIMAL(10,2) COMMENT 日租价格快照, start_date DATE NOT NULL COMMENT 租车开始日期, end_date DATE NOT NULL COMMENT 租车结束日期, total_price DECIMAL(10,2) NOT NULL COMMENT 订单总价, status TINYINT DEFAULT 0 COMMENT 状态:0待支付,1进行中,2已完成,3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, return_time DATETIME COMMENT 实际归还时间, FOREIGN KEY (user_id) REFERENCES t_user(id), FOREIGN KEY (car_id) REFERENCES t_car(id) );如果你想把项目做得更有层次可以加一张评价表CREATE TABLE t_comment ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, user_id INT NOT NULL, car_id INT NOT NULL, content VARCHAR(500), score TINYINT COMMENT 评分1-5, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );加了评价表以后论文里就能写“系统实现了订单闭环和用户反馈机制”这比单纯的管理系统听起来完整很多。2.4 为什么订单和车辆必须分开两张表这一点我每次都要强调因为真有学生把订单信息直接写进车辆表里。车辆表里存“谁租了这辆车”乍一看方便但一辆车从出租到归还期间用户、时间、价格都在变化如果都塞在同一行里后面清洗数据会特别痛苦。正确的做法是车辆表只管车辆本身的静态信息谁租了它、租多久、价格多少全部由订单表记录。两表通过 car_id 关联。这样做的好处有三个第一一辆车可以被多次租每次租都是独立订单历史记录不会相互覆盖。第二车辆状态和订单状态是独立变量可以分别维护。车辆已租出不代表订单已完成状态不同步时更容易定位问题。第三做统计聚合时非常方便比如“统计某辆车这个月的出租天数”就是按车辆 ID 分组查订单表而不是去翻车辆表的历史记录。这个设计思路本身就是组建表能力的一种直接体现也是答辩中的一个预备问题。3. 后端核心模块与关键逻辑3.1 项目结构搭建与依赖配置项目骨架建议用 Spring Initializr 生成选 Java 8 或 11 都行打包方式用 jar。依赖方面只需要最基础的几个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency需要注意的是mybatis-spring-boot-starter 的版本和 Spring Boot 版本要匹配。我用 Spring Boot 2.7.x 配 MyBatis 2.3.1属于很稳的组合。如果你选了 Spring Boot 3.x那就要注意 MyBatis 配置方式的变化最稳妥是先查一下当前版本对应的 starter 版本号。application.yml 配置如下server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/car_rental?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.rental.entity configuration: map-underscore-to-camel-case: true有几个坑这里直接提前说掉。serverTimezone 必填不然会报时区错误。useSSLfalse 可以省去一堆证书告警。map-underscore-to-camel-case 这个配置非常关键它能把数据库表里的下划线字段自动映射成 Java 的驼峰属性比如 plate_number 映射成 plateNumber省去大量手动映射工作量。3.2 MyBatis 映射与动态 SQL 实战实体类我习惯和表结构一一对应用 Lombok 注解简化Data public class Car { private Integer id; private String brand; private String model; private String plateNumber; private BigDecimal dailyPrice; private Integer status; private String picUrl; private String description; private Date createTime; }Mapper 接口只定义方法真正的 SQL 写在 XML 里public interface CarMapper { ListCar selectAvailableCars(Param(brand) String brand, Param(minPrice) BigDecimal minPrice, Param(maxPrice) BigDecimal maxPrice); Car selectById(Integer id); int updateStatus(Param(id) Integer id, Param(status) Integer status); int insert(Car car); int update(Car car); }对应的 XML 文件写动态查询这是 MyBatis 最实用的功能select idselectAvailableCars resultTypecom.example.rental.entity.Car SELECT * FROM t_car WHERE status 0 if testbrand ! null and brand ! AND brand LIKE CONCAT(%, #{brand}, %) /if if testminPrice ! null AND daily_price gt; #{minPrice} /if if testmaxPrice ! null AND daily_price lt; #{maxPrice} /if ORDER BY daily_price ASC /select动态 SQL 的价值在于筛选条件是可选的前端传什么条件就拼接什么条件不需要为每种情况写一个独立 SQL。传空参数时直接查所有空闲车辆接口的设计灵活性就在这里体现。更新车辆状态时SQL 里加个条件判断可以顺便判断当前状态比如把“只能从空闲改成已租”落到 SQL 层面update idupdateStatus UPDATE t_car SET status #{status} WHERE id #{id} if testexpectStatus ! null AND status #{expectStatus} /if /update这样可以做到数据库层面的状态校验后续讲并发安全的时候这就是一个很扎实的论据。3.3 租车下单的业务逻辑与事务处理下单租车是系统里最关键的接口涉及多张表修改必须加事务控制。核心实现如下Transactional(rollbackFor Exception.class) public Order rentCar(RentRequest req, Integer userId) { Car car carMapper.selectByIdForUpdate(req.getCarId()); if (car null) { throw new BusinessException(车辆不存在); } if (car.getStatus() ! 0) { throw new BusinessException(车辆当前不可租); } // 计算租车天数 long days req.getEndDate().toEpochDay() - req.getStartDate().toEpochDay(); if (days 0) { throw new BusinessException(租车结束日期必须晚于开始日期); } // 生成订单 Order order new Order(); order.setOrderNo(CK System.currentTimeMillis()); order.setUserId(userId); order.setCarId(car.getId()); order.setCarModel(car.getModel()); order.setDailyPrice(car.getDailyPrice()); order.setStartDate(req.getStartDate()); order.setEndDate(req.getEndDate()); BigDecimal total car.getDailyPrice().multiply(BigDecimal.valueOf(days)); order.setTotalPrice(total); order.setStatus(0); orderMapper.insert(order); // 车辆状态改为已租 carMapper.updateStatusByIdAndExpect(car.getId(), 1, 0); return order; }这里面有几个值得讲清楚的地方。第一是selectByIdForUpdate这条 SQL 会用悲观锁锁住车辆行防止两个用户同时看到车辆空闲后同时下单。虽然演示场景下并发量不大但这个写法在答辩时可以说“我考虑了并发下的同车同租问题用行级锁保证数据安全”这很容易成为答辩亮点。第二是价格用 BigDecimal 而不是 double避免浮点计算带来的金额误差。计算方式也很清晰日租价格乘以租车天数。第三是事务的 rollbackFor指定了任何异常都回滚。如果不写这个参数默认只在 RuntimeException 时回滚如果业务代码抛出受检异常事务就失效了这是很多项目的隐藏坑。3.4 登录认证与拦截器设计毕设项目没必须上 Spring Security那样会增加大量配置和理解成本。我推荐用拦截器加 Session 或者 JWT 的思路做一个轻量级认证。我这里用简单方案登录成功后把用户 ID 放入 session并写一个拦截器public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(userId); if (user null) { response.setStatus(401); response.getWriter().write({\code\:401,\msg\:\未登录\}); return false; } return true; } }注册到 Web 配置里同时放行登录、注册、车辆列表这类不需要权限的接口Configuration public class WebConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/car/list, /api/car/detail); } }角色权限可以在拦截器里再检查一下管理员接口单独约束这样整个系统的权限控制就是完整的。记住一个原则前端页面的按钮隐藏只是体验问题后端接口的权限校验才是安全底线。4. 实际操作从零到跑通系统4.1 初始化数据库脚本项目拿到手或者自己建库时第一步不是写代码而是先把数据库跑起来。我在本地用 Navicat 执行建库脚本统一使用 utf8mb4 字符集避免中文乱码。CREATE DATABASE car_rental DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE car_rental; -- 然后执行上一节中的建表语句顺序上要先建用户表和车辆表再建订单表因为订单表的外键依赖前面两张表。如果你用的是图形化工具脚本执行完检查一下表结构确认外键是否生效。初始化时顺手插入几条演示数据这样系统启动后页面上不至于空荡荡INSERT INTO t_car (brand, model, plate_number, daily_price, status) VALUES (大众, 朗逸, 京A12345, 198.00, 0), (丰田, 卡罗拉, 京A67890, 218.00, 0), (本田, 雅阁, 京B12366, 328.00, 0);演示数据要挑真实感强的答辩的时候把页面一展示大众朗逸、丰田卡罗拉这些都是常见租车车型老师看着也直观。4.2 启动项目与接口自测用 IDEA 直接运行主类启动成功后控制台会打印 Spring Boot 的启动日志看到 Tomcat started on port 8080 就说明环境没问题。接口自测我强烈建议用 Postman 或 Apifox。把常用接口整理成集合方便反复测试比如POST /api/user/register {username, password, realName, phone} POST /api/user/login {username, password} GET /api/car/list ?brandminPricemaxPrice GET /api/car/detail?id1 POST /api/order/rent {carId, startDate, endDate} GET /api/order/my ?userId1 POST /api/admin/order/return {orderId}自测的重点不是“能通就行”而是验证状态流转是否符合预期。比如下单后再次查看该车辆状态应变成已租再次下单同一辆车应返回“车辆不可租”。还车后再下单应能正常下单同时车辆状态恢复为空闲。这一步别忘了把页面上你要展示的每个操作都走一遍尤其是边界情况不登录就下单、租车开始日期大于结束日期、租一辆已租的车这些异常路径准备好答辩时老师就爱挑这种地方问。4.3 前后端联调的关键参数现在毕设大多用 Vue 或 Thymeleaf 写前端不管哪种方式联调时注意几个细节。如果你用 Vue 开发前端页面跨域问题要处理。最简单的方式是在 Controller 层加跨域配置或者在 Spring Boot 里配置一个全局 CorsFilter。我常用的是在 Controller 上加CrossOrigin或者直接在启动类里注册一个过滤器。注意如果引入了拦截器拦截器要放行预检请求 OPTIONS否则前端调接口时会莫名其妙被 401 拦截。分页参数也是一个容易忽略的点。MyBatis 分页可以用 PageHelper 插件引入依赖后一行代码搞定PageHelper.startPage(pageNum, pageSize); ListCar cars carMapper.selectAvailableCars(brand, minPrice, maxPrice);PageHelper 的原理是基于拦截器自动把 SQL 包成带 LIMIT 的查询用起来很简单但要注意它必须在执行 Mapper 方法之前调用且中间不要再执行其他数据库操作否则分页会被干扰。答辩时如果老师问分页怎么做的你要能讲出这条执行链路。4.4 打包交付与运行注意事项毕业设计最后要交文档和演示视频通常还需要提供可运行的程序。我建议用 Maven 打成 jar 包mvn clean package -DskipTests打出来的 jar 在 target 目录下运行命令java -jar car-rental-system-0.0.1-SNAPSHOT.jar给别人演示的时候最怕环境不一致。为了避免这种尴尬最好同时准备两种方式一种是完整本地环境运行另一种是简单的部署说明文档。把 JDK 版本、MySQL 版本、初始化数据库的步骤、默认账号密码写清楚照着步骤能复现这个项目才算真正交付完成。5. 答辩高频问题与避坑实录5.1 环境依赖与常见运行报错这段时间我见过最多的错误来来回回就那几类提前排查可以少走很多弯路。数据库连接报错Access denied for user rootlocalhost十次里有八次是密码不对或者 root 账号的 host 限制。MySQL 8 之后的密码加密方式也要注意如果连接报Public Key Retrieval is not allowed在 JDBC URL 后面加allowPublicKeyRetrievaltrue即可。Unknown column xxx in field list这个报错一般出现在实体类属性和表字段不一致的时候。检查一下 MyBatis 的 map-underscore-to-camel-case 是否打开或者 Java 属性名和数据库字段名是否有出入。最简单的方法是写单元测试前先跑一个最简单的 query把映射问题优先暴露出来。还有一类问题跟端口有关。8080 端口被占用我用 Spring Boot 时经常遇到要么改动server.port要么把占用进程杀掉。测试的时候直接指定一个不易冲突的端口比如 8081反而省事。5.2 数据库设计过程中容易走的弯路有些同学喜欢一开始就把表设计得很复杂用户表、车辆类别表、门店表、油卡表、保险表、违章表……表多了反而容易顾此失彼业务逻辑一团乱。我的建议是核心功能靠五张表跑通扩展表作为论文里的优化方向提一笔即可。比如车辆类别可以做成品牌字段不需要单独一张类型表门店没有多门店需求就写成车辆表的一个字段或干脆不要。表越少事务边界越简单代码就越容易写对。另一个弯路是订单状态设计得过于模糊。有人用“已支付”“进行中”“已结束”三个状态有人加“待审核”还有人把“取消”和“拒绝”混为一谈。建议用我前面提到的四状态模型清晰、常见、好讲对应的业务分支也少代码里 swtich-case 写起来很舒服。5.3 答辩高频问题清单与应对思路答辩的时候老师大概率会围绕系统设计和实现细节提问。我梳理了几个高频问题提前准备好答案现场就不会慌。老师问“为什么用 MyBatis 而不用 JPA”你可以答MyBatis 的 SQL 可控适合业务多变、查询条件复杂的场景而且团队里很多人对 SQL 更熟悉排查问题直接看 XML不用去猜框架自动生成的 SQL。这个回答既体现了工具理解又显得务实。老师问“怎么防止一辆车同时被两个人租”你可以答用了两个层面的保障。业务层在售后时先校验车辆状态必须为空闲才允许下单持久层用 select for update 对车辆行加锁同时更新状态时带条件AND status 0即使并发请求进来第二个事务也拿不到锁或者更新不到行。这个回答把从业务到数据库的多层考虑讲清楚了很加分。老师问“订单取消后车辆状态怎么恢复”你答取消订单前先判断订单状态是待支付然后同时更新订单状态为已取消、车辆状态为空闲这两步放在同一个事务里保证一致性。很简单但很能体现事务意识。老师问“用户密码为什么不存明文”你答使用 BCrypt 哈希加密即使数据库泄露攻击者也无法直接得到原始密码BCrypt 会自动加盐相同密码在不同时刻生成的结果不同安全性远高于 MD5 这类快速算法。这个知识点很小是行业安全的基本功。5.4 让项目出彩的几个增值点如果时间充裕我强烈建议往项目里加一两个增值功能不用很复杂但能显著提升整体印象。第一个增值点是车辆图片上传。用本地文件存储或者上传到指定目录然后数据库只存路径。演示时车辆列表配上真实车辆图片整个系统观感立刻不一样。代码量不大但比纯文本列表专业太多。第二个增值点是数据统计图表。管理员首页放几个统计卡片显示总用户数、总订单数、总营收、今日订单数再配一个简明的柱状图或折线图展示最近七天的营收趋势。这部分用聚合 SQL 加 ECharts 就可以实现是论文“系统实现”里的一个亮点截图。第三个增值点是导出功能。把订单列表导出为 Excel操作简单但答辩时演示一下老师会觉得项目做到了实际可用。最后提醒一句增值点一定要在自己已经跑通核心功能的基础上再加别贪多。核心功能有 80 分再带一两个加分项项目就能稳定落在 90 分以上。写在最后的一点体会带过这么多毕设我最大的感受是汽车租赁管理系统这类题目真正拉开差距的其实不是代码量而是逻辑的完整度和表达力。代码可以网上参考表结构可以套现成模板但是能不能把“车辆状态和订单状态如何联动”“并发下单怎么防重”“事务怎么保证一致性”这几个问题讲清楚才决定你的是高分还是低分。我建议你在动手写代码之前先把业务闭环画一遍谁能做什么、状态怎么流转、哪些地方要加校验、哪些表之间要建关联。这张图画清楚以后后面写代码、写论文、做答辩 PPT 都会一路顺畅。如果你正准备用这套技术栈做汽车租赁系统按这篇文章里的思路去搭框架和表结构再结合自己名称、页面的个性化调整整体要稳重很多。项目做完了记得把测试数据清理一遍演示时用真实一点的数据再去跑一次完整链路确认没有断点。祝你顺利。