SpringBoot共享汽车管理系统设计与实现：从数据库到JWT权限的完整毕设指南

1. 项目核心认知：共享汽车管理系统到底在做什么

每年到毕业季，计算机专业的同学基本都会遇到同一个痛点：毕设选题既要能体现技术能力，又要保证工作量足够、逻辑闭环，还得在答辩时经得起老师追问。很多同学选了个图书管理或者宿舍管理，做完倒是做完了，但老师一问“为什么用这个表结构”“并发场景怎么处理”，直接就愣住。相比之下，“基于SpringBoot的共享汽车管理系统”是历届毕设里性价比很高的题目，因为它的业务天然就带多个模块、多种角色、多种状态流转，展开写既不显得单薄，又能把Java后端技术的重点都覆盖进去。

这类系统本质上是解决一个问题：在一个城市投放一批车辆，用户通过线上平台完成注册、实名、预约、取车、还车、计费、支付这一整套用车闭环，运营方则要有后台能管理车辆、订单、用户、价格策略。听起来并不复杂，但一旦落到系统设计上，它比单纯的图书管理复杂出一个量级：车辆不是静态资源，它有位置、有状态、有定时任务要处理订单超时；订单不是简单的增删改查，它有预约、取车、行驶中、已还车、已支付、已取消等状态流转；费用不是一个字段就能算清的，它涉及起步价、时长费、里程费、优惠券抵扣、押金退还规则。这些业务细节堆在一起，恰好把SpringBoot开发中最该掌握的内容全部串起来。

先说结论：这个题目适合大部分Java方向的毕业生，也适合想积累项目经验的在校生。它不需要你懂算法、不需要研究高并发中间件，但非常吃基础功——SpringBoot核心机制、MyBatis或MyBatis-Plus持久层操作、MySQL表设计和事务、Redis做缓存与分布式锁、JWT做登录鉴权，如果能再引入RabbitMQ处理异步消息，整个项目的技术栈就非常完整。把这些点吃透并讲明白，毕业设计的基本盘就稳了。

2. 整体设计与功能模块拆分

2.1 用户端、运营端与管理端的三层视角

一个能打动人（包括答辩老师）的毕设项目，不能只是把CRUD堆在一起。第一次做系统设计时，很多人容易犯的错误是把所有功能平铺在一个项目里，哪个功能都做了，哪个都做得不深。我在做这类共享出行项目时习惯先按“角色视角”把系统拆开，因为角色的差异往往决定了权限设计、接口粒度、数据表结构的设计方向。

用户端，也就是普通用户能看到的界面和功能。用户要能注册登录，要去实名认证（姓名加身份证号，可能还要手机号验证码），要能在经过审核的车辆中选择附近的可租车辆，要能按时间段预约车辆，要能发起取车、还车操作，要能查看实时费用、在线支付，还要能查看历史订单和账单明细。这一端页面最多、交互最频繁，是系统的门面。运营端给业务人员用，负责审核用户的实名信息，录入和管理车辆信息，包括车辆的型号、车牌号、所在网点、当前状态（空闲、预约、行驶、维修、下线），同时能处理用户发起的异常订单和投诉。管理端则更偏向系统管理层面的东西：账号权限分配、角色管理、价格策略配置，比如设置不同车型的起步价、每公里单价、每分钟时长费，还能查看整体的运营数据。一个做毕设的项目，可以不把三层拆成真正物理隔离的多个系统，但数据库设计、代码分层、接口权限上必须体现出这种清晰的边界。

我经手过一套还算成功的共享汽车毕设项目，它的包结构是这样的：controller 下面分成 user、operator、admin 三个包，对应的接口路径前缀是 /api/user、/api/operator、/api/admin，拦截器根据 JWT 中的角色信息做接口级权限校验。这样不管是在自己开发调试还是在写论文画架构图、在答辩讲系统设计时，都容易说清楚。

2.2 核心业务链路：从找车到支付的一张流程图

功能模块拆完后，第二步是梳理核心业务链路。共享汽车和共享单车最大的区别在于流程更长、涉及的资金动作更多，也更强调订单状态的管理。从头到尾把链路走一遍，就知道系统必须有哪些表、哪些接口、哪些状态机控制逻辑了。

用户打开小程序或网页，系统定位到附近的几点（也就是共享汽车的固定停车网点），用户在线看到网点的空闲车辆列表，点选车辆后进入预约页面，选择取车时间段（由于毕设场景，时间段最少可以是小时级粒度），系统锁定这辆车并生成预约单，同时为了避免用户随便占车，要求预付一笔预约保证金或者冻结一定额度。预约成功后，用户在预约的时间内到网点，在车辆前通过扫码或输入取车码的方式解锁发车，此时订单从“预约”变为“取车”，计费正式开始。车辆使用期间，系统实时记录时长，也可以通过接入定位模块采集行驶里程。到达目的地附近网点后，用户在手机上或车载终端完成还车操作，系统校验车辆已停在合法停放区域，释放车辆状态，同时根据时长、里程、车型单价等规则计算费用，生成待支付账单，用户完成支付，如果之前有冻结的押金，此时可以申请退还。如果用户因为迟到等原因没有按时取车，预约单会超时自动取消，保证金原路退回。

这条链路走完，你会发现系统里真正被高频访问和操作的核心对象其实是两个：车辆和订单，其他实体基本是辅助。围绕这两个核心对象，所有模块围绕它们转，一旦选定这个主线，数据库设计、接口设计就都不会跑偏。

2.3 功能清单速览：一份可以直接抄的模块表

为了不让设计和实际开发脱节，我整理了一份功能清单。这份清单的特点在于：每一项都标注了对应的核心数据表、主要接口和涉及的权限角色，方便开发时逐步勾选做进度管理。启动项目后建议按这个顺序分阶段完成，而不是什么都想做然后什么都做不完。

特别说明一点：车辆管理这里我用了“车辆”和“车辆类型”分开的设计，原因很简单——计费规则通常跟车型绑定而不跟具体某一辆车绑定，比如同一品牌同型号的车，它们的计价标准应该完全一致。如果每辆车直接拉一个price_per_minute字段，后续要调价就会非常痛苦，得遍历所有车逐台改。用车型去承载价格，将来要引入新的定价方案或者做活动促销，只需要在fee_rule表里做多版本或时间区间控制即可，更容易扩展，也更符合真实共享出行系统的行业习惯。

2.4 为什么系统需要“状态流转”而不只是“状态字段”

很多做毕设的同学会用这样的方式处理车辆或订单的状态：表里有一个status字段（比如订单状态1表示待支付、2表示进行中、3表示已完成），前端判断状态显示不同按钮，后端根据状态写一堆if...else判断是否允许某个操作。如果业务比较简单，这种写法没什么致命问题，但共享汽车订单的生命周期比较长，从预约到支付中间还隔着线下取车动作，如果不加约束，很容易出现各种脏数据：同一辆车被两个订单同时预约，一个已经还车的订单还能再次发起取车，一个过了支付时限的订单仍然可以支付成功。

我的做法是为状态流转设计一张明确的状态机表，把每个状态允许跳转到哪个状态、以及触发跳转的上游条件写清楚。以订单状态为例：PENDING_PAY（待支付）可以流转到CANCELED（用户取消或超时取消）或BOOKED（预约成功），BOOKED可以流转到IN_USE（用户取车）、CANCELED，IN_USE只能流转到FINISHED（还车完成），FINISHED在支付前只能流转到PAY_PENDING或CANCELED_PAY，支付成功后才进入COMPLETED。代码里用枚举类定义这些状态，使用状态模式或者简单在Service层统一封装状态变更的校验逻辑，保证任何一条状态分支都经过校验，不会出现非法跳转。

从这个角度说，系统中真正的技术点反而分布在这张状态机如何实现、如何避免并发修改上。答辩时如果能主动讲到“订单状态流转中出现的并发情况，我通过乐观锁+Redis缓存预校验来解决”，老师会认为你不是在抄代码，而是真正思考过系统边界的人。

3. 技术选型与关键架构决策

3.1 SpringBoot 不是唯一选项，但它是毕设场景的最优解

刚开始选技术栈时，不少同学会纠结：用SpringBoot还是用更轻量的后端框架，比如直接用Servlet写？用Java还是切到Python的Django或Flask？我的看法是，如果目的是通过答辩并且尽可能多地展示自己对Java后端技术栈的掌握，SpringBoot是毫无疑问的最优选择。理由有几个：第一，生态完善，社区资料、视频教程、可参考的开源项目极多，遇到问题基本都能快速搜到答案，对毕设周期短的现状非常友好；第二，SpringBoot内嵌Tomcat，配合Maven打包后一个java -jar就能跑，部署简单不容易出环境问题；第三，它的自动配置机制本身就是面试、答辩中会被反复追问的考点，选择它等于把项目本身和知识考察点合并在一起，一举两得。

如果坚持用Spring框架的传统SpringMVC+XML配置方式开发这个系统，当然也可以实现，但配置的大量XML文件会让项目的复杂度成倍增加。而SpringBoot提供的是约定优于配置，把数据源连接、事务管理、对象转换的配置项全部自动化处理，写业务代码的效率会高出不少。当然，理解自动配置背后Spring Boot的@EnableAutoConfiguration与spring.factories、@ConditionalOnXxx注解机制，是另一个层面的问题，属于进阶技能，但在做项目时即便不看源码，会按照架构规范搭建项目，也已经能解决实际需求。

3.2 后端中间件选型：MySQL 打底、Redis 加速、可选消息队列

站在毕设时间有限、答辩需要深度的平衡点上，我推荐的中间件组合如下：持久层使用MySQL 8.x加MyBatis-Plus，所有数据关系型业务逻辑都放在这里；缓存与分布式锁使用Redis，存放模拟的验证码、用户登录token、热门网点的车辆列表缓存等；如果需要体现异步解耦，可以引入RabbitMQ处理订单超时取消这种低优先级任务，也可以只是用Spring自带的@Async或者@Scheduled做本地定时任务扫描超时订单。消息队列的引入在评答辩的时候是一个很大的加分项，但需要确保自己真能讲清楚而不是只会写配置。

为什么MySQL 8.x在这类项目中足够用？直观地说，如果系统面向一个小型城市（B端网点不超过100、在线车辆不超过2000），日常每秒的请求量不会太大，MySQL的单机性能完全可以支撑，没必要上来就讨论集群或分库分表。数据库设计的关键不在中间件选型，而在于表结构是否合理、索引是否得当。比如订单表要按user_id和create_time建索引，车辆查询要按city_id、station_id、status建立组合索引，避免全表扫描。

Redis为什么必须引入？一个典型的场景是用户用地图找车时，如果每次都请求MySQL查询附近网点车辆，高并发情况下会比较吃力，而且响应也慢。更务实的方案是把“某网点下当前空闲车辆”这种数据预加载到Redis里，车辆预约成功或还车成功时同步更新缓存，到了查询接口只读缓存返回，响应时间能从几十毫秒降到几毫秒。同时在处理预约“抢车”时，为了防止两个用户同时预约同一辆空闲车造成超卖，可以基于Redis的setnx做一个简单的分布式锁，先到先得。把这个点写进项目说明里，会让整个系统的技术方案变得更加可信。

3.3 前后端分离不分家：Vue 3 + Element Plus 的常规方案

接口层用的是RESTful API风格，返回统一状态码和数据体；前端如果条件允许优先用Vue3加Vite加Element-Plus搭建，页面可以直接套后台管理模板如vue-element-admin；如果前端基础比较薄弱，也可以使用Thymeleaf做服务端渲染，减少跨域问题，但这样整个系统的复杂度就没有从前端分离架构中体现出来，技术含金量会稍低。

前端页面数量和角色相关：用户端至少要覆盖登录注册、车辆查询与预约、个人中心（订单管理，押金管理，优惠券）、支付页面；运营端要覆盖车辆管理列表与表单、实名审核、订单查询；管理端要覆盖价格规则配置、角色权限管理、数据统计仪表盘。前端路由使用Vue Router动态生成菜单，后端返回菜单列表，前端根据权限渲染，核心实现是路由守卫加按钮级指令权限。

如果说我有什么个人经验可以分享，就是不要把时间浪费在做一套特别精美复杂的动画UI上，毕设系统界面干净、功能齐全、交互顺手就够了。真正重要、决定项目上限的始终是后端设计的规范性和答题时对业务逻辑的阐释，很多项目页面炫酷但是一问接口设计就一塌糊涂，这样的项目等于白做。

4. 数据库设计详解与核心业务逻辑

4.1 表结构设计：一张能跑通全局的ER图

在开发前先把ER图画清楚，比一开始就写代码高效得多。共享汽车管理系统的主要数据表可以归纳为六大类：用户域、车辆域、订单域、财务域、网点域、系统管理域。

用户域：用户表、用户实名信息表、驾驶证信息表、积分表。用户基本信息字段包括用户名、密码（BCrypt加密存储）、真实姓名、手机号、头像URL、注册时间、状态。实名信息表单独拆分，是为了记录用户反复提交证件、审核不通过时审核备注等信息。车辆域：车辆表、车型表、车辆图片表、车况上报记录表。车辆表的核心字段有车牌号（唯一）、所属网点ID、车型ID、当前状态、总行驶里程、当前电量/油量（如果做电动车）、城市ID、定位信息。订单域：订单主表和订单状态变更流水表。这里的订单流水表要记录每次订单状态变更的时间、操作人、变更前后状态、备注，这样用户才能在“我的订单”中看到完整的时间线，运营方也能定位纠纷。财务域：支付单表、退款单表、押金单表、费用规则表、优惠券表。每一笔资金操作都有独立流水，金额用DECIMAL类型。网点域：城市表、网点表。网点是共享汽车停放的固定位置，只有在网点内才能取还车。系统管理域：用户角色表、菜单表、角色菜单关联表、操作日志表。

每一张表都要有id、create_time、update_time三个基本公共字段，状态字段建议使用tinyint或varchar来表示。我在设计时习惯用varchar存状态的英文标识符，比如FREE、BOOKED、IN_USE、MAINTENANCE，因为看到数据的含义比看到1、2、3更容易，这一点在后期调试中非常有用。

4.2 订单状态机与超时取消：核心难点这样突破

订单状态机是整个系统代码量比较集中的地方。在写Service层时，强烈建议不要每个状态字段直接塞个setter，而是建立一个OrderStateMachine组件，负责统一的订单流转校验。以关键状态请求为例：

1. 发起预约请求时，入参为userId、vehicleId、startTime、endTime。
2. 系统先判断用户是否完成实名认证，没有则直接提示去认证。
3. 查询该车辆当前状态必须为FREE，并且该时间段无其他未取消订单，这就是库存/时段锁定。
4. 生成预约单并设置状态为PENDING_PAY（如果需要支付预约费或冻结预授权），同时将车辆状态设为BOOKED。
5. 支付成功或预授权成功后订单状态变为BOOKED；超过15分钟未支付则自动取消。

这里有一个很容易忽略的细节：如果用户在已经预定某辆车后，又决定取消，取消时车辆状态要从BOOKED还原为FREE，并且所有状态变更要放在同一个事务里保证原子性。还要给每个查询车辆是否冲突的SQL加上FOR UPDATE或乐观锁version字段，避免出现同一辆车同一时间段被重复预约的“超卖”问题。这些细节在答辩和代码审查时都是容易被提问的点。

4.3 费用计算模型：如何把计价规则做到不坑用户也不坑系统

费用模型是共享汽车管理系统的核心业务价值所在，也是体现系统水平的关键模块。常见计价规则为：总费用 = 起步价 + 时长费用 + 里程费用 + 可能的夜间服务费或异地还车费，超过封顶价后按封顶价计算。还要考虑优惠券抵扣、用户积分抵扣等。

设计费用规则表时，需要支持不同车型、不同时间段、不同城市拥有不同的价格。推荐设计思路是fee_rule字段包括车型ID、适用城市ID、生效日期范围、起步价、起步包含分钟数、每分钟单价、每公里单价、日封顶价、夜间时段单价。运营配置界面就是维护这张规则表的可视化版本。在实际计算时，Service层根据订单的起止时间、里程数、车型等找到适配的规则并计算。为避免系统上线后出现金额不正确的问题，订单表上还要持久化计费快照字段：计费开始时间、计费结束时间、行驶里程、选中规则ID、各项明细费用，这样后续对账和退款都能追溯。

这里给一个直接可参考的示例：假设某车型起步价为15元（含30分钟时长），超过后每分钟0.5元，每公里1.8元。用户用车2小时（120分钟），里程25公里，总费用等于15元加上超出的90分钟乘以0.5元/分钟（45元）加上25公里乘以1.8元/公里（45元），合计105元。如果系统同时有夜间计费（晚上10点到次日6点每分钟1.2倍），那么夜间部分要在规则引擎中拆段计算。这种表结构能做到每一条配置都有据可查，而不是把价格散落在代码的魔法数字中。

4.4 为什么推荐使用DTO而不是直接传递实体类

很多初学阶段的项目图省事直接把数据库实体类当作接口的返回对象和使用对象，表面看代码量少了很多，但埋下了不少隐患。实体类一旦被序列化出去，所有表字段都会被暴露给前端，包括密码的哈希值、内部备注字段；以后改动表结构时，还容易影响接口的兼容性。

更规范的做法是：Controller层入参使用XxxQuery或XxxDTO，返回使用XxxVO；Service层内部可以把DO（数据库实体）转换为VO，而这个转换可以使用MapStruct、BeanUtils或手写。以用户资料接口为例，查询用户信息后不能把密码字段返回出去，这在代码里手写赋值又太琐碎，最优雅的方案就是定义一个UserVO，字段只包含用户ID、用户名、头像等必要信息，通过BeanUtils将DO的属性拷贝过去但忽略敏感字段。另一个让人纠结的场景是分页查询，用MyBatis-Plus的Page对象直接当返回值其实也可以，但很多资深开发者还是会包装一层PageResult，将总记录数、总页数、当前页记录列表统一结构，因为前端分页组件需要的字段不止list，还要total等，这个结构在多项目间通用。

5. 实操过程与核心逻辑实现

5.1 初始化项目：从IDEA到能跑起来的第一个Hello请求

拿到一台开发机，第一步是准备环境：JDK 1.8或11（若是Spring Boot 2.x推荐1.8以上，若是3.x则必须17以上），Maven 3.6以上，MySQL 8.x，Redis，IDEA或Eclipse。推荐使用Spring Initializr生成项目骨架，Group填com.example或自己学校的域名倒序，Artifact填car-sharing，依赖勾选上Lombok、Spring Web、MyBatis Framework、MySQL Driver、Validation、Redis。

要注意Spring Boot版本与JDK版本匹配的问题：现在热词里经常能看到“springboot版本太高”的讨论，我这里也提醒一句。Spring Boot 3.x默认要求JDK 17，如果电脑里装的是JDK1.8，硬要用3.x会导致项目启动直接报错。毕设多数情况建议用Spring Boot 2.7.x，成熟稳定，网上参考资料也多，配合JDK1.8不会踩版本坑。如果确实想用Spring Boot 3.x，则全程统一使用JDK17，不要混用。

生成项目后第一件事不是急着写业务代码，而是把配置文件配通。我习惯把application.yml拆成三个环境：application-dev.yml（本地开发库）、application-prod.yml（演示环境）、application.yml（公共配置，激活dev）。在application.yml按如下内容配置数据源、MyBatis-Plus、Redis和端口号：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/car_sharing?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  redis:
    host: localhost
    port: 6379
    database: 0

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

其中map-underscore-to-camel-case解决数据库下划线字段与Java驼峰属性的自动映射问题，这个细节很多新手容易漏配置，然后会发现查询结果全是null。逻辑删除字段配置也很重要，业务数据不要物理删除，统一用软删除更安全。

5.2 用户认证与权限控制：JWT 从发出到校验的完整链路

共享汽车系统涉及到用户、运营、管理员三端操作，所以权限认证是必须实现的。有两个主流的实现路线：一是使用Spring Security配合JWT，功能强大但配置复杂，如果本身对Security的过滤器链不熟，会在一开始浪费大量时间；二是自己写一个HandlerInterceptor实现JWT的拦截、解析与角色判定。做毕设时，如果只是为了完成任务，第二种方案完全够用并且更好讲；学有余力时再升级成Spring Security或Sa-Token也不迟。

我的实现思路是：用户登录成功后，使用JWT工具类生成三端都通用的token，字段中包含userId、userName、roleCode，expiration设为2小时。jwt依赖建议用io.jsonwebtoken:jjwt，版本0.9.1或0.11.5。给出一个最简示例，核心逻辑可以直接参考：

java复制@Component
public class JwtUtil {
    private static final String SECRET = "your-256-bit-secret-key";
    private static final long EXPIRE_TIME = 2 * 60 * 60 * 1000L;

    public String createToken(Long userId, String username, String roleCode) {
        return Jwts.builder()
                .claim("userId", userId)
                .claim("username", username)
                .claim("role", roleCode)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }

    public Claims parseToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

JWT的生成细节其实是加密签名的标准实现。有了token之后，还需要在WebMvcConfig中注册拦截器。拦截器的拦截范围可以分为三类：白名单放行（登录、注册、获取验证码、浏览公开车辆列表）、用户接口（前缀/api/user/**）、运营管理接口（前缀/api/operator/**和管理端/api/admin/**）。在preHandle方法中先取出Header里的Authorization: Bearer xxx，解析token，如果过期则返回401状态码，如果角色不匹配则返回403状态码。再强调一次：拦截器中的校验只是轻量级的接口权限校验，它依赖于JWT本身不窜改的特性，但如果涉及较严格的权限模型，还是需要引入RBAC。

5.3 车辆预约的并发处理：防止同一辆车被抢两次

预约核心方法主要由下面这段逻辑构成，重点在于开启事务并先锁定行的查询方式：

java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(Long userId, Long vehicleId, LocalDateTime startTime, LocalDateTime endTime) {
    // 1. 锁车辆行，确认状态可用
    Vehicle vehicle = vehicleMapper.selectByIdForUpdate(vehicleId);
    if (vehicle == null || !VehicleStatus.FREE.equals(vehicle.getStatus())) {
        throw new BusinessException("该车辆当前不可预约");
    }

    // 2. 查询是否存在时间冲突的未取消订单
    Long count = orderMapper.selectConflictCount(vehicleId, startTime, endTime, OrderStatus.CANCELED);
    if (count > 0) {
        throw new BusinessException("车辆在该时间段已被预约");
    }

    // 3. 创建订单并更改车辆状态为BOOKED
    RentalOrder order = new RentalOrder();
    order.setOrderNo(generateOrderNo());
    order.setUserId(userId);
    order.setVehicleId(vehicleId);
    order.setStartTime(startTime);
    order.setEndTime(endTime);
    order.setStatus(OrderStatus.PENDING_PAY);
    order.setDeleted(0);
    orderMapper.insert(order);

    vehicle.setStatus(VehicleStatus.BOOKED);
    vehicleMapper.updateById(vehicle);

    return order.getId();
}

这里selectByIdForUpdate是用了SELECT ... FOR UPDATE对车辆这一行加了行级写锁。两个用户同时提交抢同一辆车时，后一个用户会被阻塞到前一个事务提交，然后重新读到最新状态发现车辆已经被预约，这条并发路径就不会产生脏单。如果不想使用行级锁，还要选择乐观锁的方案，即在vehicle表中加入version字段，更新时检查update_version是否等于读取到的版本，如果别人已经更新过，则更新失败重试。两种方案都能用，事务内的行锁相对直接，适合车辆数量不大、单行热度不高的毕设场景。需要注意的是，行锁的使用必须置于事务内，否则锁瞬间被释放等于没有锁。

关于用户端体验，还有几个细节值得注意：取车码生成要保证6位数字且不重复，还车时要校验该用户确有一个正在使用的订单，开始计费后每分钟进行心跳或定时任务更新车辆最后位置与在线状态。在服务层做接口幂等性控制，每次提交预约请求传入唯一requestId，Redis根据requestId判断是否有重复提交，能有效减少用户因为手滑双点导致的重复单。

5.4 还车计费与费用明细：把每一步的钱都算得明白

还车操作在整个共享汽车链路里属于最容易出问题的环节，因为用户还车时系统同时要做的事很多：确认车辆停在指定网点或合规停车区域、结束订单并释放车辆状态、根据计费规则算出费用并生成待支付账单。

简化版还车处理逻辑：

java复制@Transactional(rollbackFor = Exception.class)
public PayOrder settleOrder(Long orderId, Long stationId) {
    RentalOrder order = orderMapper.selectById(orderId);
    if (order == null || !OrderStatus.IN_USE.equals(order.getStatus())) {
        throw new BusinessException("订单状态异常，无法还车");
    }

    // 1. 计算用车时长和行驶里程
    long minutes = Duration.between(order.getActualStartTime(), LocalDateTime.now()).toMinutes();
    if (minutes <= 0) {
        minutes = 1;
    }
    // 平时车辆装有GPS时走里程统计接口，毕设可以手工录入或默认估算

    // 2. 匹配计价规则
    FeeRule rule = feeRuleMapper.findMatchRule(order.getVehicleTypeId(), order.getCityId(), LocalDateTime.now());
    BigDecimal totalFee = calculateFee(rule, minutes, mileage);

    // 3. 更新车辆位置为新网点，空闲可继续被预约
    order.setActualEndTime(LocalDateTime.now());
    order.setEndStationId(stationId);
    order.setMileage(new BigDecimal(mileage));
    order.setStatus(OrderStatus.PENDING_PAY);
    order.setTotalFee(totalFee);
    orderMapper.updateById(order);

    vehicleMapper.updateStatus(order.getVehicleId(), VehicleStatus.FREE);

    // 4. 生成支付单
    PayOrder payOrder = new PayOrder();
    payOrder.setOrderId(order.getId());
    payOrder.setPayAmount(totalFee);
    payOrder.setPayStatus(PayStatus.UNPAID);
    payOrderMapper.insert(payOrder);

    return payOrder;
}

这里有一个很值得做的设计：还车成功只是生成了待支付账单，为什么不是直接自动扣款？因为在共享出行场景中，用户可能余额不足，可能信用优良可以先离场后补缴，也可能要使用抵扣券。支付动作建议做成异步触发或由用户点击“去支付”，实现方式更清晰。给用户的账单中要回显明细：起步价、超时长费、里程费、优惠券抵扣、实际应付，即每一项都落到数据库或动态计算，不要只给总数。这一步做得好，在“用户体验”层面会比较加分。

5.5 定时任务处理超时与状态回滚

用户预约车辆后如果一直没去取车，车就会一直处于BOOKED状态被浪费，因此需要定时任务处理这批超时预约。实现方式有两个，最简单的是SpringBoot自带的@Scheduled每30秒扫描一次booked_time超过N分钟且状态为BOOKED的订单，将其取消并把车辆状态回滚为FREE。

java复制@Component
public class OrderTimeoutTask {

    @Scheduled(cron = "0 */1 * * * ?")
    public void cancelExpiredBookedOrder() {
        LocalDateTime deadline = LocalDateTime.now().minusMinutes(30);
        List<RentalOrder> expiredOrders = orderMapper.selectExpiredBooked(deadline);
        for (RentalOrder order : expiredOrders) {
            try {
                orderService.cancelOrder(order.getId(), "超时未取车自动取消");
            } catch (Exception e) {
                log.error("cancel expired order error, orderId={}", order.getId(), e);
            }
        }
    }
}

@Scheduled默认是单线程串行执行的，如果任务本身不复杂完全够用。想要更强的容错，例如某个订单取消失败时整体任务停下来重试，可以引入RabbitMQ的延迟队列，发布一条延迟消息，消费者消费时做超时处理。不过在毕设场景中，几十行代码的定时任务就可以完成从“假死状态”恢复的任务，不需要为了追求高级而引入额外中间件，关键是逻辑要自洽、可运行、能解释。

6. 常见问题与排错速查

6.1 数据库乱码、时间差8小时、字段无法映射

经常遇到且容易排查的三类问题，这里直接给出一张总结表，方便开发时对照：

乱码问题在Windows电脑上出现频率尤其高，核心解决思路是让MySQL数据库、连接、后端代码、前端页面四处字符集统一为UTF-8。

6.2 事务不生效：自调用与异常的坑

如果你在同一个类里写了一个方法调用另一个带@Transactional的方法，比如OrderService.createOrder 内部直接调用本类的settleOrder方法，事务注解通常不会生效，这是因为Spring事务通过动态代理实现，只有外部调用才会走到代理逻辑，类内部this调用绕过了代理。解决办法有两种：将涉及事务的方法拆到不同的Spring Bean中，让它们通过注入方式互相调用；或者在启动类或配置类上确保@EnableTransactionManagement生效，并使用AopContext.currentProxy()获取当前代理对象调用。

另一个常见的坑是事务内部捕获了异常导致不会回滚。比如在下单逻辑中，更新车辆状态这行代码抛了一个SQLException，却被外层try...catch吞掉了，直接return一个false，事务根本感知不到异常，自然也不会回滚。正确的做法是在catch块中根据业务场景抛出RuntimeException或BusinessException，让事务管理器捕获到运行时异常后回滚。

6.3 前端请求跨域、接口404和鉴权失败

前后端分离项目最容易在联调阶段趴窝。可以先从几个方向排查：第一是跨域，在后端配置一个全局的CorsFilter，允许前端域名；也可以在后端统一用拦截器给响应加Access-Control-Allow-Origin等Header。第二是404问题，很可能是Spring Boot默认没有把Controller的包扫描到，检查启动类位置和各个Controller所在包路径是否在启动类的子包下；也有可能是前端请求的接口路径与后端@RequestMapping中的路径对不上。第三是鉴权失败，检查JWT过期时间、Token是否在Header中正确传递，以及拦截器是否误拦截了登录接口。做后端联调时可以打开日志，请求的信息一目了然。

6.4 Application运行后马上退出的坑

刚接触SpringBoot项目时，如果引入了spring-boot-starter-web但程序启动后立即退出，大概率原因是没有引入Web或WebFlux模块，因为没有Web容器，启动完就执行完然后退出。解决方式是检查pom.xml中是否包含spring-boot-starter-web依赖。另外，如果使用的是Spring Boot 3.x版本，请确认JDK版本至少为17，否则启动会直接报UnsupportedClassVersionError。这些“看起来不像问题”的问题，往往最耗时间。

总而言之，这类共享汽车系统项目重点不在注册人数或者并发量有多高，而在于是否将全链路的业务思考清楚并用扎实的Java后端手段落到一个可运行的系统上。在开发时遇到问题不要慌，把数据库的状态改变、JWT校验的流程、Spring事务的生效机制这几个基础问题弄懂，绝大部分Bug都能顺藤摸瓜解决。

7. 后续扩展与简历加分思路

项目跑通并完成论文初稿不代表就可以直接交差。如果时间允许，建议在此基础上做两个方向的小扩展，一个偏功能，一个偏工程。

功能扩展的首选方向就是引入地图服务。把车辆位置以经纬度字段存入车辆表以及网点表，引入高德地图或百度地图的Web API，在用户端实现地图选车：加载城市中心点周围3公里内的空闲车辆，预约车辆时展示预计步行距离。这部分主要是前端调外部API渲染地图标记，后端提供“根据经纬度范围查询车辆列表”的接口，用MyBatis-Plus的ge、le条件或自己写SQL的BETWEEN都可实现。这一步的收益是让系统看起来更真实，也更贴近市面上主流软件的使用体验。

工程化方向的建议是引入Docker，做一个简单的部署方案。写一个Dockerfile把SpringBoot应用打包为镜像，再用docker-compose.yml同时编排MySQL、Redis和应用容器，在本地一键启动整个项目。这种扩展不但方便答辩现场演示——不用在老师电脑上配环境，也是简历上非常加分的工程能力证明：熟悉容器化部署、具备基本DevOps意识。结合热词中“docker部署springboot项目”的出现频率，也能看出这个技能在求职和毕设语境里有多受关注。

做扩展的原则是：不贪多，只做自己能讲明白并且能稳定演示的功能。一次答辩展示里出现一个复杂不稳定的地图组件，如果现场网络出问题，可能给老师留下不好的观感。而Docker部署相对稳定可控，演示时还显得专业。

我个人带过不少学生做类似的选题，最大的体会是：毕设项目的深度不在页面的多少，而在于每个模块之间是否真正联动、每张表之间关系是否清晰、每次状态变化是否经得起推敲。与其在最后一个月熬夜堆页面，不如在开工前花两天把状态机画清楚、数据库设计好，后边的开发过程会顺畅很多。哪怕只是按照本文拆分出的这些模块逐步做下来，也足够产出一个能答辩、能写进简历的完整共享汽车租赁运营系统了。