眠子子子讲个实际场景，你接手一个毕设或者课程项目，题目叫“基于Android的随心行汽车租赁系统”，技术栈写着 Spring Boot + Vue + Android。这三个词凑在一起，乍一看很唬人，但拆开落地的时候会发现，它不是一个“大而全”的平台，而是一条完整的前后端闭环：管理员用网页后台管车、管单、管用户，用户用手机端完成注册、选车、下单、还车这一套租赁流程。我最初做这类项目的时候，习惯先把它当玩具看，后来把整条链路跑通以后才意识到，这类题目真正考察的不是某个框架用得有多花哨，而是你在“后端接口怎么设计、管理端怎么对接、手机端怎么展示”三者之间能不能找到一套和谐相处的结构。
这篇文章我就围绕这个标题，把从零搭建这类系统的完整思路、核心逻辑、常见坑位，以及可以直接抄作业的实现方案都捋一遍。如果你是刚开始做 Spring Boot 和 Vue 的毕设玩家，或者想在自己的 Android 项目里加一个完整的业务闭环，这篇文章应该能省你不少事。
1. 项目整体设计与架构思路
先别急着写代码，做这类多端项目最容易犯的错误就是一上来就建表、写接口、堆页面。到后面你会发现，后台接口的字段命名跟 Android 端对不上，管理员在网页端改了个车辆状态，用户手机端刷新半天还是旧数据。这些问题的根源不是编码能力，而是前期没有把“业务边界”和“数据流”画清楚。
1.1 三类角色的权限边界
租车业务里一定有普通用户、平台管理员，可能还有车辆维护员之类的角色，但最核心的就是前两者。用户端完成注册、登录、浏览车辆、下单、支付（模拟或真实）、查看订单、还车、评价这些动作。管理端负责车型管理、车辆库存管理、订单审核、订单统计、用户管理等。
在设计接口的时候，用户端和管理端虽然操作的是同一批数据，但不能直接共用一套接口。比如用户端只查上架中的、没被预定的车；管理端要能看到所有车，包括下架的、维修中的。如果你把管理端查询逻辑和用户端查询逻辑揉在一个接口里，后面每加一个状态判断都要改两个端的调用，十分痛苦。
1.2 技术分层与通信协议
Spring Boot 负责提供 RESTful API，Vue 管理后台跑在浏览器里，通过 Axios 调接口，Android 端用 Retrofit 调同样的接口。三个端各自独立，唯一的“共同语言”就是 JSON 数据和接口约定。
这里有一个非常重要的经验：接口返回结构一定要统一。我见过太多项目，有的接口返回 {code: 0, data: {...}}，有的直接返回一个数组，还有的异常时直接返回 500 页面。你在 vue 和 Android 两端做统一拦截处理的时候，只能到处写 if-else，非常崩溃。建议从一开始就定死一套规范：
json复制{
"code": 200,
"message": "success",
"data": {}
}
成功时 code 为 200，业务异常时 code 为业务错误码（比如 40001 表示车辆不可用），data 里放具体数据。这样不管是 Vue 的响应拦截器还是 Android 的 Retrofit 封装，都可以在出入口统一处理，页面里只需要关心成功以后的数据。
1.3 为什么选这些技术而不是其他组合
很多人问，Spring Boot 和 SSM 比到底强在哪，既然要做管理后台，为什么不用 Thymeleaf 而要再单独架一个 Vue。我的理解是，Spring Boot 帮我们解决了 90% 的配置烦恼，内嵌 Tomcat、自动装配这些特性让后端变成一个“写好业务就行”的流程，适合快速迭代。而后端渲染 Thymeleaf 在面对复杂的交互页面（比如车辆图片上传、订单筛选、动态表单校验）时，写起来既绕又难维护。Vue 把数据和 DOM 绑定的工作大量减免，更适合做这种模块多、状态多的后台管理系统。Android 端天然独立于 Web，用原生开发能保证更好的交互体验，特别是地图定位、相机拍照这种系统能力调用上。
这套组合的实际优点是后续扩展能力很强。如果你想给系统加一个小程序端，后端接口完全不用动，新写一个前端调用层就行，这其实是分层架构带来的最大红利。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 后端：Spring Boot 接口层设计与数据建模
后端是整个项目的心脏，手机端和网页端都在围着它转。我建议先把数据库表和接口文档定出来，再去做页面，这会省掉一大半联调时间。
2.1 核心数据库表设计
租车系统最少需要以下这几张表：
user用户表：用户 ID、用户名、密码（注意不要明文存）、手机号、身份证号、驾驶证号、用户类型（普通用户/管理员）、注册时间。car车辆表：车辆 ID、品牌、型号、车牌号、颜色、日租金、车辆图片 URL、车辆状态（0 下架 / 1 上架 / 2 租用中 / 3 维修中）。order订单表：订单 ID、用户 ID、车辆 ID、取车时间、还车时间、总租金、订单状态、创建时间。comment评论表：评论 ID、订单 ID、用户 ID、评分、评论内容、评论时间。
这几个表是骨架，后面的业务都是在它们之间做联动。表关系上，一个用户可以有多个订单，一个订单对应一辆车，一个订单最多有一条评价。在订单表里直接用 car_id 和 user_id 冗余关联，而不是走中间表，更符合租车这种单项业务的核心逻辑。
2.2 密码加密与登录令牌的选择
密码存储这条线，很多学生项目直接明文存数据库，这非常危险。哪怕只是课程设计，也要用 BCrypt 这类加盐哈希算法。Spring Security 里自带 BCryptPasswordEncoder，但如果你不想引入整个 Spring Security 的重量级配置，也可以用 spring-security-crypto 单拿加密工具出来用。
登录令牌这边，我的建议是直接引入 JWT，而不是用 Session。原因很简单：Android 端和 Vue 端都需要在请求头里带一个 Authorization 字段，Session 那套 Cookie 机制在原生 App 里处理起来很别扭。JWT 是后端签名的 token，里面可以塞用户 ID、用户名、过期时间，前端拿到后存下来，每次请求带上就好，后端通过拦截器校验。
前后端约定好 token 传递方式后，拦截和处理起来是这样的：
java复制@Component
public class JwtInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String token = request.getHeader("Authorization");
if (token == null || !JwtUtil.verify(token)) {
response.setStatus(401);
return false;
}
// 从 token 解析用户信息，放入 ThreadLocal 或 request attribute
return true;
}
}
需要注意的一点是，要放行登录、注册接口以及车列表这类公开查询接口，不然 Android 端用户啥都没干就弹 401。
2.3 车辆可用性的并发扣减
租车业务最典型的并发场景是：一辆车被 A 用户预定后，同一时间段 B 用户也来下单。如果不做任何控制，就会出现一车两租的情况。最简单的处理方式是“状态位 + 事务”：用户下单时，先更新车辆状态，更新的 SQL 带条件“状态为可租”，如果影响行数为 0，说明车已经没了。
sql复制UPDATE car SET status = 2 WHERE id = ? AND status = 1
Spring Boot 里可以用 @Transactional 包裹整个下单方法，先执行这条更新语句，再插入订单记录。如果更新行数为 0 就抛出异常回滚事务。这个方案在中小型项目里完全够用，不需要引入 Redis 分布式锁，既保持了逻辑的简单性，也解决了大部分并发冲突。
2.4 订单时间冲突校验
除了状态位，时间冲突也是一个容易漏掉的点。用户选择“8月10号取车、8月12号还车”，车辆状态是“可租”，但实际这辆车在 8月11号已经被另一个单子占用了。这种场景靠状态位解决不了，必须在订单表里做区间重叠判断：
sql复制SELECT COUNT(*) FROM `order`
WHERE car_id = ?
AND status IN (1, 2)
AND (
(take_time <= ? AND return_time >= ?) -- 新订单在旧订单中间
OR (take_time <= ? AND return_time >= ?) -- 交叉
OR (take_time >= ? AND return_time <= ?) -- 旧订单在新订单中间
)
查询结果大于 0，说明跟已有订单撞了。这个查询条件在测试的时候很容易被忽略，但它恰恰是租车系统区别于普通 CRUD 的核心业务规则。
3. 管理后台：Vue 的页面组织与接口对接
Vue 端做管理后台，最常用的配套是 Element UI 或 Element Plus。使用 Vue 3 + Vite + Element Plus 的组合在目前来看是比 Vue 2 项目更适合新手的，Vite 的启动速度比 webpack 快很多，调试反馈也及时。
3.1 项目初始化和目录划分
创建项目可以直接用 Vite 命令：
bash复制npm create vite@latest car-admin -- --template vue
cd car-admin
npm install
npm install axios element-plus vue-router pinia
目录划分建议按照“视图 + 组件 + 请求层”来走：
src/api/下放所有后端接口请求，每个模块一个文件（如car.js、order.js）。src/router/里定义路由，并加一个全局前置守卫，没有 token 就跳转登录。src/views/里放页面级组件（车辆列表、订单审核、用户管理、数据统计）。src/components/放被多个页面复用的子组件（车辆表单弹窗、图片上传、状态标签）。
这样分的核心好处是，页面里不直接写 axios.get，而是统一从 api 模块引入函数。以后后端接口路径改了，只需要改一个 api 文件，而不是全局搜接口字符串。
3.2 Axios 拦截器与登录态管理
管理后台和后端交互，保持登录态是第一步。每次请求都需要在 header 里带上 token，响应如果是 401 说明登录失效，此时应该清空本地 token 并跳回登录页。这个逻辑放在 Axios 拦截器里最合适：
javascript复制// src/utils/request.js
import axios from 'axios'
import router from '../router'
const request = axios.create({
baseURL: '/api',
timeout: 10000
})
request.interceptors.request.use(config => {
const token = localStorage.getItem('admin_token')
if (token) {
config.headers.Authorization = token
}
return config
})
request.interceptors.response.use(
response => {
const res = response.data
if (res.code !== 200) {
ElMessage.error(res.message)
return Promise.reject(new Error(res.message))
}
return res.data
},
error => {
if (error.response && error.response.status === 401) {
localStorage.removeItem('admin_token')
router.push('/login')
}
return Promise.reject(error)
}
)
export default request
这样做的好处是，页面代码不需要关心 code 判断和错误弹窗，只需要拿到数据操作即可。
3.3 车辆管理的增删改查与图片上传
车辆管理是后台最常写的模块，这里的痛点是“图片上传”。如果图片是 base64 直接塞进数据库，数据库很快会变得非常冗余。更好的方式是单独做一个文件上传接口，把图片存到服务器的某个目录（比如 /upload/），数据库里只存访问路径。
javascript复制// src/api/car.js
import request from '../utils/request'
export function getCarList(params) {
return request.get('/car/list', { params })
}
export function addCar(data) {
return request.post('/car/add', data)
}
export function updateCar(data) {
return request.put('/car/update', data)
}
export function deleteCar(id) {
return request.delete(`/car/delete/${id}`)
}
export function uploadImage(data) {
return request.post('/file/upload', data, {
headers: { 'Content-Type': 'multipart/form-data' }
})
}
在后端，文件上传接口用 MultipartFile 接收，存到本地磁盘，同时配置一个静态资源映射目录：
java复制@PostMapping("/upload")
public Result upload(@RequestParam("file") MultipartFile file) {
String fileName = System.currentTimeMillis() + "_" + file.getOriginalFilename();
String filePath = uploadDir + fileName;
file.transferTo(new File(filePath));
return Result.success("/upload/" + fileName);
}
如果服务器将来迁移到云环境，这块可以换成 OSS，但对本地部署的项目来说，本地磁盘文件存储已经够了。
3.4 订单管理页的思路
订单管理页的核心不是简单的数据列表，而是要有筛选和操作按钮。比如按照订单状态（待取车、使用中、已完成、已取消）筛选，按用户名或车牌搜索，以及“审核通过”“标记还车”“取消订单”这类按钮。这些操作最终映射到后端的几个接口，前端只需要在点击时调用对应函数并刷新列表即可。
一个比较实用的技巧是使用 el-table 的 row-key 和展开行，默认展示订单摘要，展开后看到用户详情、车辆详情、时间明细。这样列表页不至于太臃肿，信息层级也比较清楚。
4. Android 客户端：从登录到下单的完整链路
Android 端是用户接触最直接的入口，体验好不好全看细节。我建议使用 Kotlin 作为开发语言，配合 Retrofit + Coroutine 处理网络请求，这种组合在可读性和异步处理上比 Java + Thread 要舒服很多。
4.1 Android 端网络层封装
跟 Vue 端一样，Android 端也需要做统一网络层封装。在 build.gradle.kts 里加依赖：
kotlin复制dependencies {
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("com.squareup.okhttp3:logging-interceptor:4.9.0")
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.6.4")
}
然后把 ApiService、RetrofitClient、数据类定义好。一个比较常见的问题是把 Result 响应体又包了一层，导致解析时拿到的是 Result<Result<Car>>。我的建议是定义一个统一的 ApiResponse
kotlin复制data class ApiResponse<T>(
val code: Int,
val message: String,
val data: T
)
Retrofit 的 Service 接口返回类型不要直接用 ApiResponse<T>，而是用 ApiResponse<Car> 这种具体类型。Gson 会自动做泛型解析。
4.2 用户端首页与车辆列表加载
首页一般是“顶部 Banner + 推荐车辆 + 全部车辆列表”。这里注意一个经验：不要在 Android 端自己实现轮播图，直接用现成的库（比如 Banner、ViewPager2 + RecyclerView）。自己实现的话，生命周期、触摸冲突、自动轮播这些坑够你调好几天。
车辆列表用 RecyclerView 展示，每张卡片包含车型图片、名称、日租金、状态标签。网络图片加载推荐使用 Coil，因为它是 Kotlin 写的，支持协程，调用非常简单：
kotlin复制imageView.load(car.imageUrl) {
placeholder(R.drawable.placeholder)
error(R.drawable.error)
}
4.3 下单页面：时间选择与价格计算
下单页是 Android 端业务逻辑最集中的地方。用户选择取车时间、还车时间，系统自动计算租金。租金计算规则一般是“天数 × 日租金”，但要注意汽车租赁的计费模式：
- 如果取车时间是 8月10日 10:00，还车时间是 8月12日 10:00，算两天。
- 如果超过还车时间，部分系统按一个小时代价算超时费。
最简单的实现方式是使用 java.time 包（Kotlin 里的 LocalDateTime）做日期计算，然后传给后端做最终校验。前端算出来给用户看，后端算出来作为最终扣费依据，两者不一致时以后端为准。
4.4 订单状态轮询与“我的订单”列表
下单完成后，用户需要在“我的订单”里看到订单状态的变化。由于前端和后端没有做 WebSocket 实时推送（这个项目用轮询最简单），Android 端可以在进入订单详情页时拉取一次最新状态，同时用一个定时任务每 10 秒轮询一次，直到订单进入“已完成”或“已取消”状态为止。
这个轮询操作不要在 Activity 里随意使用 Handler+Runnable，会更推荐用协程的循环来实现，写在 lifecycleScope 里，页面销毁时自动取消，避免内存泄漏：
kotlin复制lifecycleScope.launch {
while (isActive) {
val result = apiService.getOrderDetail(orderId)
// 更新 UI
if (result.data.status in listOf(3, 4)) break
delay(10000)
}
}
4.5 Android 端的拍照与证件上传
用户注册时一般要上传驾驶证照片，这是 Android 端除了网络请求以外最容易踩坑的地方。因为 Android 7.0 以后，直接传 file:// 类型的 URI 是不允许的，必须走 FileProvider 的方式。很多人在网上搜索的时候看到类似 content://com.tencent.wework.fileprovider/external_path/android/data/com 这样的地址，会误以为这是系统路径，其实那只是因为手机里安装了多个应用、每个应用都有各自的 FileProvider 路径导致的混淆。正确做法是：
- 在自己的 App 内部配置 FileProvider。
- 拍照时把图片保存到
getExternalCacheDir()目录。 - 用 FileProvider 的
getUriForFile获取 content URI。 - 再把该 URI 转成可以上传的输入流。
这部分代码是 Android 端最容易出问题的，建议把拍照裁剪逻辑封装成一个工具类，别在每个页面里重复写。
xml复制<provider
android:name="androidx.core.content.FileProvider"
android:authorities="${applicationId}.fileprovider"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/file_paths" />
</provider>
5. 核心业务难点拆解：车辆状态、订单状态与金融安全
这一节说的东西，是面试官或者评审老师最容易追问的地方，也是让项目从“增删改查”变成“系统”的关键。
5.1 车辆状态机与订单状态机的联动
车辆状态有“上架、下架、租用中、维修中”，订单状态有“待支付、已支付待取车、使用中、已完成、已取消”。这两个状态机之间不能随便跳，否则会出现数据不一致。
典型流程是这样的：
- 用户下单成功并且完成支付 -> 车辆状态变为“租用中”，订单状态变为“已支付待取车”。
- 用户确认取车（或者系统自动计算）-> 订单状态变为“使用中”。
- 用户还车 -> 订单状态变为“已完成”，车辆状态变回“上架”。
- 用户取消订单 -> 订单状态变为“已取消”，车辆状态变回“上架”。
这个流程必须用后端接口控制，不能在前端直接改状态。比如还车接口要做的事情是：校验订单是否处于“使用中”状态，计算超时费用，更新订单状态，同时把车辆改成“上架”。如果这些逻辑分散到前端或各写各的，就会出现订单已完成但车还是租用中的情况。
5.2 支付功能的技术选型与模拟支付方案
真实对接微信支付、支付宝需要营业执照和商户号，对个人开发者不太现实。毕设和课程设计阶段，最常见的做法是“模拟支付”：用户点击支付后，后端直接把订单状态变成已支付，并且生成一条支付流水记录（金额、交易号、支付时间）。这样既保留了业务流程的完整性，又绕过了资质限制。
如果想让项目看起来更完整，可以考虑接入一个第三方的沙箱支付平台，但那样会增加不少联调成本。我的建议是，项目答辩重点放在业务闭环上，支付沙箱不是最核心的技术点。把支付流水表设计好，模拟支付逻辑写清楚，就足够体现你对业务的理解了。
5.3 权限校验与越权处理
多端系统最容易被忽略的安全问题是越权。比如用户 A 拿到了订单 ID 后，直接去调用了“取消订单”接口，把用户 B 的订单取消了。问题根源在于后端接口没有校验“当前操作用户”和“订单所属用户”是否一致。
解决方式是，在需要身份的操作中，从 token 里解析出当前用户 ID，然后在 SQL 更新条件里带上 user_id：
sql复制UPDATE `order`
SET status = 4
WHERE id = ? AND user_id = ?
这样就算别人拿到了订单 ID，也操作不了不属于自己的订单。这条原则放在所有涉及用户数据的接口上，包括删除评论、查看订单详情等。
5.4 缓存与热点数据优化
Spring Boot 默认的查询是每次请求都打数据库，如果后续车辆数据量大了，首页和车辆列表会明显变慢。可以引入 Redis 做缓存，把车辆列表、热门车辆这种查询频率高、更新频率低的数据缓存起来。
我建议的缓存策略是：查询车辆列表时先查缓存，缓存不存在再查数据库并回填，管理员在后台修改或删除车辆时主动删除缓存。对于简单项目，使用 Spring Cache 注解就能搞定：
java复制@Cacheable(value = "carList", key = "#page + '_' + #size")
public List<CarVO> getCarList(int page, int size) { ... }
@CacheEvict(value = "carList", allEntries = true)
public void updateCar(Car car) { ... }
需要提醒的是，Spring Cache 只是简化了调用方式，底层还是离不开 Redis 的 key 过期和淘汰策略。在答辩的时候，能说清楚“为什么这里用缓存、缓存一致性怎么保证”，会比单纯输出 CRUD 高出一个档次。
6. 常见问题与避坑实录
这里整理几个我实际开发中踩过、或者帮别人排查过的典型问题，每一个都有真实场景，不是理论空谈。
6.1 Spring Boot 版本太高导致的依赖兼容问题
新手入门最痛苦的，一个是 Spring Boot 版本太高，另一个是 JDK 版本跟框架不匹配。比如 Spring Boot 3.x 要求 JDK 17，如果电脑上装的是 JDK 8，启动项目就会报错。我建议做课程设计阶段直接使用 Spring Boot 2.7.x + JDK 8，这套组合在网上搜到的教程最多，遇到的坑绝大多数已有答案。等你把项目跑通了，再考虑升级到 3.x 体验一把 Jakarta 命名空间的变化。
如果非要用 Spring Boot 3.x，还需要注意 javax 包名变成了 jakarta，很多老代码的 import 语句全部要改。这个改动看似机械，实际会影响所有实体类和拦截器，第一次踩坑时容易懵。
6.2 时区问题导致的订单时间错乱
订单表的取车时间、还车时间如果直接存数据库，而服务器时区和手机时区不一致，会出现用户选了 8月10日，实际存进去变成了 8月9日的诡异现象。
解决方式是：数据库统一使用 datetime，后端在接收前端传参时明确指定时区，推荐统一使用 GMT+8。简单粗暴的做法是在 Spring Boot 配置文件中设置：
properties复制spring.jackson.time-zone=GMT+8
server.servlet.encoding.force=true
同时在 Android 端发送时间参数时，格式化成 "yyyy-MM-dd HH:mm:ss"，避免使用时间戳。你只要保证从用户输入到后端存库这一路都走同一个格式化规则，时间就不会错。
6.3 Vue 打包后布局异常
本地开发好好的，npm run build 部署到服务器后布局乱了。这通常有两个原因，一是打包后的静态资源路径是绝对路径 /assets/xxx.js，但你的项目部署在子目录下，导致资源 404；二是路由用的 history 模式，刷新时后端没有做重定向。
解决方式是在 vite.config.js 中设置 base: './'，让资源引用改为相对路径。路由模式建议直接用 hash 模式，最简单，刷新不会 404：
javascript复制const router = createRouter({
history: createWebHashHistory(),
routes
})
6.4 Android 端上传图片选错文件路径
前面提到拍照要使用 FileProvider，另一个经常出问题的是“相册选择图片”。在 Android 11 以上，不能直接拿相册返回的 Uri 路径去文件系统读，必须用 ContentResolver 打开输入流。很多人的 Crash 来自这里：
kotlin复制val inputStream = contentResolver.openInputStream(uri)
别去拼什么 /storage/emulated/0/... 这种真实路径，Android 的存储权限已经收得很紧了，用 ContentResolver 才是通用做法，不管是 QQ、微信还是系统相册返回的 Uri，都能正常读取。
6.5 数据库连接池与连接泄漏
Spring Boot 默认使用 HikariCP，一般不需要调优，但要注意一条：如果项目里用了事务或者流式查询，用完没有关闭资源，时间长了连接池会被耗尽，系统表现为“越来越卡”，明显在并发量不高的情况下也会频繁超时。排查的时候用 show processlist 看 MySQL 连接数，几百个连接都 Sleep 就知道是泄漏了。
代码里要确保 JDBC 的 Connection、Statement、ResultSet 全部在 finally 或 try-with-resources 中关闭。如果使用 MyBatis-Plus，它的 queryWrapper 基本不会泄漏，但如果自己写了 JDBC 代码，这关一定要把好。
7. 部署上线与答辩准备
7.1 本地联调三端的环境准备
开发和测试阶段，建议这样区分环境：后端跑在本机 8080 端口，Vue 开发环境用 Vite 的默认端口 5173，并通过代理把 /api 转发到 8080。Android 模拟器访问本机后端时，不能用 localhost，要用 10.0.2.2（这是模拟器映射到宿主机地址的专用 IP），真机联调时则要用电脑的局域网 IP。
如果 Android 端真机连不上后端，先别急着查代码，先用 ipconfig / ifconfig 确认电脑 IP，再用手机浏览器访问 http://电脑IP:8080 看通不通。网络层通不了，代码写得再对也白搭。
7.2 服务器部署的轻量方案
部署时可以不用买很贵的云服务器，一个 2 核 4G 的实例就够跑这套系统。后端打 Jar 包，用 nohup 启动：
bash复制nohup java -jar car-rental.jar --server.port=8080 &
前端 Vue 项目 npm run build 之后，把 dist 目录用 Nginx 托管，并把 /api 反向代理到 8080 端口。Android 端打包成 APK 后，把接口地址改成服务器的 IP 或域名。数据库用 MySQL 8，上线前注意设置数据库编码为 utf8mb4。
7.3 答辩/汇报时的技术亮点提炼
如果你要把这个项目作为毕设或面试项目展示，不要只讲“我用了 Spring Boot、Vue、Android”，要有侧重点。核心亮点可以从这几方面准备：
- 业务上：订单时间冲突检测、车辆状态并发扣减。
- 安全上：JWT 鉴权、BCrypt 密码加密、接口越权校验。
- 优化上：Redis 缓存车辆列表、轮询改协程。
- 工程化上：统一返回体、Axios 拦截器、Retrofit 封装。
每个亮点准备一个“我遇到了什么问题、怎么解决、效果怎么样”的表达，比任何 PPT 都有说服力。
根据我个人的实际开发体验，这类三端联动的租车系统，最花时间的反而不是那些看起来困难的功能。用户管理、车辆增删改查这些老实说就是熟练功，真正磨人的是订单状态流转里那些边界情况——用户下单了但一直没支付、车辆取走了却没有按时归还、管理员下架车辆时车辆还有进行中的订单。每一条都需要你在后端设置好状态校验和兜底逻辑。建议先画一张简单的状态流转图，把每种可能的路径走一遍再动手写代码，后面会顺畅很多。如果时间来得及，还可以加上一些扩展的小功能，比如用 ECharts 在后台做一个租车热度统计，或者在 Android 端接入百度地图展示取还车站点，这些都是低成本高观感的加分项。希望这篇内容能给你的项目提供一个清晰的实施路径，少走几段弯路。最后一个小提示：接口文档一定要写，别偷懒，哪怕只是 Markdown 写一份，等 Android 端和后端联调的时候，你会感激自己当时这个决定。