企业官网建设流程全解析

做毕设辅导这些年，看到汽车租赁管理系统这个题目几乎是“常青树”一般的存在。每年都有学生选它，原因不难理解：车辆、用户、订单、租金这几样核心对象，正好把增删改查练透，又比图书管理多了一层业务状态流转，工作量适中，做完之后答辩也有东西可讲。这里我以个人带过的真实项目为蓝本，把架构思路、核心表设计、关键代码、运行配置以及被问得最多的几个问题一次性说透，希望对正在选题目或者已经开题的同学有实际帮助。

这个题目适合谁？如果你的 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 核心业务流程拆解

整个系统最关键的流程是下单租车，我把它拆成六个步骤：

1. 用户登录，前端带上 token 或 session。
2. 用户选择车辆，选择起始日期和结束日期。
3. 后端校验车辆存在且状态是空闲。
4. 后端计算租车天数，乘以日租价格得到总金额。
5. 生成订单，初始状态为待支付。
6. 将车辆状态改为已租出。

还车流程则反过来：

1. 管理员选择一条进行中的订单。
2. 校验订单确实是进行中状态。
3. 修改订单状态为已完成。
4. 将对应车辆状态改为空闲。
5. 记录归还时间，用于计算实际租期。

这套流程里面的订单状态流转是答辩时的加分点，一定要能讲清楚：待支付、进行中、已完成、已取消，这四种状态不是随意跳转的，而是有方向的。取消只能发生在待支付或进行中但还未取车的阶段，完成只能从进行中进入。把这些规则写清楚，说明你考虑了业务合理性。

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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</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?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8 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 必填，不然会报时区错误。useSSL=false 可以省去一堆证书告警。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 { List<Car> 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 id="selectAvailableCars" resultType="com.example.rental.entity.Car"> SELECT * FROM t_car WHERE status = 0 <if test="brand != null and brand != ''"> AND brand LIKE CONCAT('%', #{brand}, '%') </if> <if test="minPrice != null"> AND daily_price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND daily_price &lt;= #{maxPrice} </if> ORDER BY daily_price ASC </select>

动态 SQL 的价值在于：筛选条件是可选的，前端传什么条件就拼接什么条件，不需要为每种情况写一个独立 SQL。传空参数时，直接查所有空闲车辆，接口的设计灵活性就在这里体现。

更新车辆状态时，SQL 里加个条件判断可以顺便判断当前状态，比如把“只能从空闲改成已租”落到 SQL 层面：

<update id="updateStatus"> UPDATE t_car SET status = #{status} WHERE id = #{id} <if test="expectStatus != 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 ?brand=&minPrice=&maxPrice= GET /api/car/detail?id=1 POST /api/order/rent {carId, startDate, endDate} GET /api/order/my ?userId=1 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); List<Car> 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 'root'@'localhost'，十次里有八次是密码不对或者 root 账号的 host 限制。MySQL 8 之后的密码加密方式也要注意，如果连接报Public Key Retrieval is not allowed，在 JDBC URL 后面加allowPublicKeyRetrieval=true即可。

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 都会一路顺畅。

如果你正准备用这套技术栈做汽车租赁系统，按这篇文章里的思路去搭框架和表结构，再结合自己名称、页面的个性化调整，整体要稳重很多。项目做完了，记得把测试数据清理一遍，演示时用真实一点的数据，再去跑一次完整链路，确认没有断点。祝你顺利。