眠子子子讲个实际场景，你接手一个毕设或者课程项目，题目叫“基于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 {