
最近很多同学在后台问我毕业设计怎么选方向我的答案一直很明确全栈管理系统类项目是性价比最高的一条路。工作量可控、技术栈主流、演示效果好而汽车租赁系统可以说是这一类项目里的标准模板业务逻辑清晰又不会像电商、论坛那样绕来绕去把新手绕晕。今天就把我手上这套 SpringBoot Vue MySQL 汽车租赁系统平台从数据库设计到前后端实现再到打包部署的完整思路一次性讲透源码、数据库脚本和部署文档都是配套的跟着走基本不会卡壳。先说清楚这套系统到底能干什么。它分用户端和管理员端用户端负责注册登录、浏览车辆、下单租车、在线还车、查看订单和个人信息管理员端负责车辆管理、用户管理、订单审核与处理、还车结算、公告发布。整条业务线覆盖了“车辆上架 - 用户选车 - 下单 - 确认取车 - 按期归还 - 费用结算”全流程该有的业务状态都能体现拿来当毕业设计或者项目经验写进简历都撑得住。先讲整体设计思路再逐层拆代码和数据库最后把部署文档的关键点和常见坑一起整理了重点针对的是那些“刚开始配环境就卡半天”的兄弟但有一点经验的人也能从这里抠出一些平时文档里不写的细节。1. 项目整体设计与模块拆解1.1 系统功能范围用户、车辆、订单、还车四条主线汽车租赁系统听起来业务不复杂但“租”和“还”两个动作前后牵扯的数据状态不少。我从一开始就把功能定位成四条主线用户管理、车辆管理、订单管理、还车结算管理外加公告和个人中心这些辅助模块。用户端要做的动作包括注册账号、登录、浏览在租车辆、查看车辆详情、提交租车订单、模拟取车、在预计还车时间之前发起还车、查看自己的历史订单和订单状态。管理员端则是登录后台、对车辆进行增删改查和上下架操作、审核用户提交的订单、处理取车和还车流程、确认还车时计算费用并归档订单、发布平台公告、对注册用户进行状态管理。这里有一个设计上权衡过的点是不是要把还车做得特别复杂比如自动计算超时费、押金、赔偿金我最终选择保留最核心的“基础租金 超时费”模式。因为毕业设计的评审更看重的是你有没有把核心业务流程讲清楚、把系统跑通、把异常情况处理到位而不是业务规则有多复杂。你可以在这个基础上往押金、会员折扣、车辆故障上报方向扩展工作量上去了答辩时也有话讲。1.2 技术选型为什么是 SpringBoot Vue MySQL这套组合在当下已经不算什么新颖方案但恰恰是最合适毕业设计和中小型管理系统落地的组合。SpringBoot 负责后端接口Vue 负责前端页面MySQL 负责数据持久化前后端通过 JSON 交互整个过程清晰可控。SpringBoot 的核心优势是“约定优于配置”不用像早期 SSM 那样写一大堆 XML 配置内置 Tomcat打 jar 包就能跑非常适合快速交付。Vue 的渐进式框架特性让前端按组件拆分页面数据双向绑定对表单操作特别友好像我这种后端为主的前端也不用花太多精力去折腾复杂的 DOM 操作。MySQL 则是开源关系型数据库里最稳妥的选择资料多、工具全、排查问题方便面试时也好聊。实际开发的时候后端我用 SpringBoot 2.7.x MyBatis Plus 3.5.x前端用 Vue 2 Element UI数据库用 MySQL 5.7 或 8.0 都可以JDK 用 1.8。这套版本组合非常成熟网上资料随处能搜到遇到问题基本上不会卡死。之前试过 SpringBoot 3.x但它默认 JDK 17 起步MyBatis Plus 和某些组件之间存在适配问题新手踩进去容易出不来。所以选型阶段稳字当头版本宁可“老”不要“新”。1.3 业务流程梳理一张图理清前后端协作我用文字把整个核心业务流转画一遍用户在首页看到车辆列表点击详情页选择租用天数提交订单后订单状态是“待审核”。管理员在后台看到这笔订单确认车辆没问题后操作“确认取车”订单状态变为“租用中”同时车辆状态变为“已租出”避免其他用户重复下单选到同一辆车。用户驾驶到期后来系统点“申请还车”管理员后台确认车辆归还、没有明显损坏根据实际使用天数计算费用订单状态变为“已完成”。这条流程里最核心的设计是“订单状态机”。我在订单表里用 state 字段存状态0 待审核、1 租用中、2 待还车、3 已完成、4 已取消。每次状态变更都在后端做校验比如待审核的订单才能确认取车租用中的订单才能申请还车。实际写代码时把状态流转写成常量类防止硬编码满天飞。后端接口设计上我把用户端和管理员端拆分在不同的 Controller 里用户端路径带 /user管理员端路径带 /admin这样权限拦截器好写代码结构也清晰。接口返回统一用 Result 对象封装code 为 200 表示成功非 200 表示失败前端 axios 拦截器统一判断处理不用每个页面重复写错误提示。2. 数据库设计与核心表结构2.1 六张核心表的字段规划和关联关系汽车租赁系统的表结构是这套毕业设计里最能体现基本功的部分。我最终确定六张核心表用户表、车辆表、订单表、还车记录表、公告表、管理员表。不建议上来就设计十几二十张表评审老师看的是你的 E-R 关系合不合理而不是表多就厉害。用户表存手机号、密码、用户名、身份证号、驾驶证号、角色和状态密码用 MD5 加盐加密存储不能明文入库。车辆表存车辆名称、品牌、型号、车牌号、颜色、日租金、车辆图片、车辆状态0 可租、1 已租出、2 维修中还有一个车辆介绍字段可以存详细描述。订单表是核心关联用户 ID 和车辆 ID存租用天数、每日租金、订单金额、下单时间、取车时间、还车时间、租赁状态和备注。还车记录表我建议单独建而不是把还车信息合并进订单表。原因是“还车”是一个包含操作时间、还车里程、额外费用、备注的独立事件单独建表方便做历史追溯页面展示也更灵活。公告表就简单了标题、内容、发布时间、发布人 ID。管理员表单独存管理员账号和用户表分开权限控制时逻辑更干净。2.2 订单计费字段设计拆清楚才不会报表都算不明白订单金额的计算是很多人容易糊涂的地方。我设计的订单表里保留了单价快照字段也就是下单那一刻的日租金防止以后车辆涨价了历史订单的价格变乱。订单金额字段存的是系统自动计算出的“预计总费用”用租用天数乘单价快照前端显示给用户看的是这个值。重点在还车环节。用户实际还车时间可能和预计还车时间不一致我在还车记录表里设计了实际还车时间、实际租用天数、超时金额、总费用四个字段。实际天数不满一天但超过一小时按一天计算这个规则是租车行业里常见的做法。后端在确认还车时做一次结算总费用 日租金快照 * 实际租用天数若超时再加超时费最后回写到订单表的“实际支付金额”字段。这里要特别提醒一点所有金额字段在 MySQL 里都用 decimal(10,2)不要用 float 或 double否则容易出现 0.1 0.2 0.30000000000000004 这种精度问题。Java 后端对应的是 BigDecimal前端展示时直接用后端返回的字符串形式避免精度丢失。这是我踩过坑以后才改掉的。2.3 索引、外键与字段类型的设计心得正式做毕业设计的人很少关注索引但这个问题面试官可能会问。我在订单表的用户 ID 和车辆 ID 上建了普通索引因为查询用户订单列表和车辆租赁历史是最频繁的操作。状态字段值变化频繁且区分度低不建议单独加索引联合索引可以考虑但单表量级不大时意义有限。简单说表数据行数少于十万级别普通索引足够用了。关于外键我的经验是尽量不用物理外键只在逻辑层面保留关联关系。原因有两个一是物理外键会限制删除操作顺序开发过程中调试麻烦二是毕业设计阶段数据量小物理外键的性能保障完全体现不出来反而徒增复杂度。我的方案是在 SQL 脚本里不写 FOREIGN KEY但表和表之间通过业务字段关联E-R 图里照常画出关系线文档里说明逻辑外键设计思路这样反而更容易自圆其说。MySQL 的字段类型也值得多说一句。密码等定长字符串用 char(32) 存 MD5 值车辆名称这种会变长的用 varchar(50)文本介绍用 text。时间字段统一用 datetime别用 timestamp否则 2038 年的坑到时候还得有人填。逻辑删除字段 deleted 用 tinyint(1)默认值 0所有查询条件后面都带 deleted 0这个习惯可以从项目一开始就养成。3. 后端 SpringBoot 核心功能实现3.1 项目分层结构与包路径规划后端项目结构直接影响代码可读性和后续维护成本。我的包路径是这样的entity 放数据库实体类mapper 放 MyBatis Plus 的接口service 放业务逻辑接口和实现类controller 放接口路由config 放配置类common 放统一返回结果和异常处理utils 放工具类。这样划分之后改需求的时候基本知道去哪个包里找文件不需要全局搜索。实体类我统一用 MyBatis Plus 的注解做映射表名下划线转驼峰在配置文件里开启实体字段如 userId 自动映射到 user_id。每个实体类继承一个 BaseEntity把创建时间、修改时间、逻辑删除这三个通用字段放进去避免每个类都重复写同样的代码。Service 层的接口继承 IService实现类继承 ServiceImpl这是 MyBatis Plus 的标准用法基础 CRUD 方法直接继承自己专注写业务方法。Controller 层只做参数接收、权限校验调用、结果响应不写业务逻辑。比如 PlaceOrderController 接收 userId、carId、days、remark 后直接调用 OrderService.placeOrder()真正的库存检查和金额计算全部下沉到 Service。这种写法的好处是接口层薄、业务层厚遇到事务处理时方便统一加 Transactional。3.2 登录认证与权限拦截毕业设计够用的方案登录认证有很多方案JWT、Spring Security、Shiro、最简单的是 Session 拦截器。我的建议是如果论文想讲安全设计用 JWT 拦截器的方式最合适代码量不大但能讲出令牌校验、无状态认证、前端存储 token 这些亮点。Spring Security 功能强大但学习曲线陡峭答辩时容易被追问深了反而不划算。实现思路是这样用户输入账号密码后端校验通过后生成一个 token把 userId、角色、过期时间封装进去返回给前端。前端把 token 存在 localStorage 里每次 axios 请求时通过请求拦截器在 header 里带上 token。后端写一个拦截器拦截所有需要登录的接口从 header 里取出 token 并校验签名和过期时间通过后把 userId 放入 ThreadLocal 供业务代码取用。角色权限控制我做得比较简单拦截器里拿到角色字段如果是 /admin 开头的接口且角色不是管理员直接返回无权限。这种基于路径前缀的权限控制虽然简单但很好用前端的菜单显示也按角色区分非管理员根本看不到后台管理入口。如果你想再加亮点可以用注解 切面做一个自定义权限校验但我觉得对毕业设计来说没那么必要。3.3 租车与还车的核心业务逻辑状态机的落地租车下单是整条业务链里最需要细心的地方。用户提交订单时后端要做三步校验车辆是否存在且状态为可租、用户是否正常状态、租用天数是否在合法范围内。校验通过后先更新车辆状态为已租出再插入订单记录状态为待审核。这两步操作必须在同一个事务里否则可能出现车已经租出去但订单没生成的情况。我用 Transactional(rollbackFor Exception.class) 保证异常时两个操作一起回滚。接下来说还车结算。用户发起还车后管理员在后台确认还车后端计算实际租用天数规则是取车时间到实际还车时间按天计算不足一天超过一小时按一天算否则按一天算。然后判断是否超过原来填写的预计还车日期超出的天数计算超时费用超时费用我是按日租金快照的 1 倍计算。最后更新订单状态为已完成车辆状态重置为可租同时插入一条还车记录。这里有一个很多人会忽略的细节计算费用时要使用下单时的日租金快照也就是订单表里存的 rent_price不能去车辆表再查一次当前价格。虽然这个项目里几乎不会出现车辆租出去期间改价格的情况但逻辑上快照更严谨论文里也更好陈述。我还额外做了一步还车确认时校验车辆确实处于租用中状态防止订单状态混乱导致重复结算。3.4 全局异常处理与统一返回格式前后端分离项目里统一返回格式是标配。我定义了一个 Result 类包含 code、message、data 三个字段。成功的响应是 Result.success(data)失败的是 Result.error(code, message)。Controller 层所有接口都返回这个类型前端 axios 的响应拦截器里对 code 不等于 200 的情况统一弹出错误信息不需要每个页面单独写 try catch。全局异常处理用 RestControllerAdvice 实现。业务异常我自定义了 BizException比如车辆已被租走、订单状态不允许操作等情况直接 throw由全局异常处理器统一转为 Result.error参数校验异常、数据库异常也分别处理返回对应的友好提示。这样做的好处是代码干净Controller 里不会到处是 try catch出错信息也一致规范。全局异常处理最大的价值体现在答辩演示的时候。演示过程中操作到不该操作的状态系统不会抛出那一大串英文报错而是弹出“当前订单状态不允许该操作”的人话提示。这种细节评审老师的印象分会差别很大。4. 前端 Vue 页面开发与接口联调4.1 前端环境准备与项目初始化Vue 2 Element UI前端开发从环境准备说起。需要先装 Node.js版本建议 14.x 或 16.x太新的 Node 与旧版 Vue CLI 可能出现兼容问题。然后全局安装 Vue CLI 脚手架用 vue create 命令创建项目选择 Vue 2 的预设。进入项目目录后安装 Element UI、axios、vue-router、vuex 这几个必备依赖。Element UI 只支持 Vue 2如果你创建项目时选了 Vue 3就要用 Element Plus语法和组件用法有差异容易看视频教程时对不上号所以创建前确认好版本。项目的目录结构我按页面模块拆分views 下面分 user 和 admin 两个大目录分别放用户端和管理员端页面。components 目录放复用组件比如车辆卡片组件 VehicleCard 在首页和车辆列表页都会用到。router 目录里配置路由和导航守卫store 目录里存登录状态和用户信息。api 目录是重点每个后端接口都封装成一个 api 方法页面里调用 api 方法而不是直接拼 axios 请求这样后端接口路径改了只需改一个文件。初始化环境时新手最容易卡在依赖安装阶段。npm install 经常因为网络原因慢或者报错我的经验是镜像源切换到国内镜像在项目根目录建 .npmrc 文件写入 registry 地址。还有 node_modules 目录千万别手动删删了以后重新安装耗时很长。4.2 页面结构与路由设计用户端和管理员端分开用户端页面包括首页、车辆列表、车辆详情、我的订单、个人中心、登录注册。首页展示轮播图和推荐车辆车辆列表页支持按品牌和价格区间筛选详情页展示车辆图片、参数和租车表单。我的订单页面列出当前用户的所有订单根据订单状态显示不同的操作按钮待审核的显示“等待取车”租用中的显示“申请还车”完成的显示订单详情。每个操作按钮点击后调用对应 API刷新列表。管理员端页面包括后台首页、车辆管理、订单管理、还车管理、用户管理、公告管理。车辆管理是一个表格 对话框表单的组合支持新增、编辑、下架和删除。订单管理表格里每条订单后面根据状态渲染不同操作按钮待审核的显示“确认取车”和“拒绝”租用中的显示“确认还车”点击后弹出确认框。所有后台页面都包在一个后台布局组件里左侧是菜单栏右侧是内容区。路由守卫是前端权限控制的关键。我在 router.beforeEach 里做两件事一是判断当前路由是否需要登录需要但没有 token 就跳登录页二是判断当前路由是否是管理员专属是但当前用户角色不是管理员就跳回首页。前端守卫虽然可以被绕过但配合后端拦截器做双重校验实际效果已经完全满足毕业设计场景。4.3 Axios 封装与跨域问题处理Axios 请求封装直接影响前后端联调体验。我在 api 目录下建了 request.js创建一个 axios 实例设置基础 URL 为 /api超时时间 10 秒。请求拦截器里从 localStorage 取 token 并放到 header 的 Authorization 字段。响应拦截器里统一处理返回的 Result 对象code 等于 200 就返回 data 部分否则用 Element UI 的 Message 组件弹出错误信息后端返回 401 则清除本地登录信息跳转登录页。跨域问题在前后端分离开发时几乎必然遇到。前端跑在 8080 端口后端跑在 8088 端口浏览器直接发请求会报跨域错误。我的做法是在前端 vue.config.js 里配置 devServer 的 proxy把所有 /api 开头的请求代理到 http://localhost:8088同时后端也配置了跨域过滤器作为双保险。生产环境打包后部署到 NginxNginx 里同样配置 /api 反向代理到后端服务这样前后端之间不存在跨域问题。这里有个容易被忽略的细节配置 proxy 后前端 axios 请求的 baseURL 要写成 /api 而不是完整的后端地址。如果你写完整地址 http://localhost:8088/api请求就不会经过代理跨域问题依旧存在。我见过不少同学卡在这地方好几天。联调阶段还有一个小技巧打开浏览器开发者工具的 Network 面板看请求的 URL如果显示的是 8088 端口说明代理没生效检查 vue.config.js 有没有重启项目改完配置必须重新 npm run serve。4.4 车辆列表筛选、日期选择与表单校验前端页面最常出体验问题的是车辆列表页和租车表单。车辆列表页我实现了按品牌和价格区间的筛选直接在方法里对当前展示的车辆数组做 filter不用每次筛选都请求后端数据量不大时这种前端筛选手感更流畅。筛选条件变化时重置分页器到第一页这个细节不做的话用户容易误以为出了 bug。租车表单放在车辆详情页的右侧卡片里需要选择租车天数、填写联系人电话和备注信息。租车天数用 Element UI 的 InputNumber 计数器最小值设为 1最大值根据车辆表里配置的单次最长租期。表单提交前做校验天数不能为空、电话格式要符合 11 位手机号规则、用户必须已经登录。校验逻辑用 Element UI 的 rules 配置在 data 里声明校验规则对象表单提交时调用 validate 方法。日期选择这里我额外说明一下。租车业务里“租用天数”和“起止日期”有一个是冗余的我在系统里选择用天数字段不选日期因为日期选择组件涉及日期禁用逻辑和跨天计算对毕业设计来说徒增复杂度。如果你想做得更真实可以选开始日期和结束日期后端计算天数差但要注意边界情况比如结束日期不能早于开始日期当天取车当天还车算一天。5. 项目部署实施与数据库导入5.1 部署前需要准备的环境清单部署文档是毕业设计交付物里评分占比不低的一部分很多同学项目写得不错部署文档里没有写清楚环境要求老师在自己电脑上跑不起来印象分直接打折扣。我的部署文档第一部分就是环境清单JDK 1.8、Maven 3.6、Node.js 14、MySQL 5.7、Nginx 1.18同时注明所有软件都是开源免费版本方便老师复现。后端打出 jar 包之前需要先检查 application.yml 里的数据库连接配置。我习惯把数据库地址、端口、库名、用户名、密码单独放在一个地方部署时只需要改这一个文件。数据库脚本文件 init.sql 中要包含建库建表和基础数据的完整语句基础数据要准备好测试账号和示例车辆这样部署完成后马上能登录体验不需要手动一条条插入数据。部署方式上我推荐两种一种是本地 IDEA 里直接启动后端加前端 npm run serve适合课程设计老师当场看效果另一种是打 jar 包和前端 dist 包部署到服务器适合想展示完整的线上部署能力。我在部署文档里两种方式都写了把服务器部署放到最后作为进阶内容。5.2 数据库导入与后端配置连接数据库导入的坑主要在 MySQL 版本差异上。如果下载的是 MySQL 8.0连接驱动要用 com.mysql.cj.jdbc.Driver连接 URL 要加 serverTimezoneAsia/Shanghai 和 useSSLfalse。如果用的是 MySQL 5.7驱动类名可以保持 com.mysql.jdbc.Driver但为了兼容建议统一用 8.0 的驱动写法因为 5.7 也能连。导入数据库的方式可以选命令行、Navicat 或者 IDEA 自带的 Database 面板。命令行方式最通用打开终端执行 source 命令导入 SQL 脚本。导入后检查一下三张基础表里有没有数据管理员表至少要有一个 admin 账号车辆表至少有五条以上示例车辆用户表可以留两三个测试账号。没有这些数据的话前端页面打开一片空白很容易误判断系统有问题。后端启动前要确认 Maven 依赖下载完整。第一次加载项目时右下角会提示引入 Maven 项目点导入后等待依赖下载完成。如果 pom.xml 文件所在的依赖报红优先检查网络和 Maven 仓库配置配置阿里云镜像一般能解决问题。启动后端看到 SpringBoot 的启动日志出现 Started Application 且没有红色报错就是成功了然后访问 http://localhost:8088 测试接口是否连通再启动前端 npm run serve 访问页面。5.3 前后端打包发布到 Nginx 的全过程打包的步骤其实不复杂但每个环节都有易错点。后端打包前先执行 mvn clean package跳过单元测试用 -DskipTests 参数打出来的 jar 包在 target 目录下。前端打包前先改 vue.config.js 里的 publicPath 配置这个字段决定静态资源引用的基础路径我一般改成 ./ 相对路径这样 dist 目录下的文件不管放在哪个子目录访问都不会白屏。前端打包执行 npm run build生成 dist 目录。把 dist 目录整个上传到服务器的 html 目录把 jar 包上传到任意目录用 java -jar 命令启动。同时 Nginx 配置里添加一个 location /api 的代理规则把接口请求转发到本地 8088 端口。配置文件改完执行 nginx -s reload 生效。这一步做完浏览器直接访问服务器 IP 就能看到完整系统。整个部署过程中最容易出问题的环节是端口被占用。第一次启动后端提示端口被占用时在 cmd 里用 netstat -ano 查到占用进程的 PID然后到任务管理器结束进程或者直接修改 application.yml 里的端口号。前端如果出现页面能打开但接口报 404优先检查 Nginx 的代理路径是不是写对了在 Network 面板能看到完整的请求 URL逐一核对路径就行。5.4 部署文档里必须写清楚的核心内容很多同学的部署文档就是把启动步骤列一遍我建议你的部署文档至少包含五个部分环境准备、数据库导入、后端启动、前端启动、常见问题。环境准备里不仅要写软件名称还要写具体版本和下载地址最好把 JDK 环境变量配置截图放进去。数据库导入部分要写明账号和密码默认值、初始数据脚本说明。常见问题这个板块我强烈建议保留是体现你确实踩过坑的最有力证据。比如 MySQL 连接报错时的解决方案、前端 npm install 慢的解决方案、端口占用解决方案。我在部署文档里把这些场景按“问题现象 原因分析 解决步骤”的格式写清楚老师在帮你调试的时候看到这种文档会省很多力气心里对你的认真程度也会高看一眼。还有一个细节是文档版本号。我在部署文档开头写清楚适用版本比如“适用于 SpringBoot 2.7.5、Vue 2.6.14、MySQL 8.0”。这样以后代码有变动别人看完也知道怎么对应。这份文档你自己三周后就可能忘更别说老师同学写清楚一点对自己也是一种帮助。6. 常见问题与排查技巧实录6.1 SpringBoot 版本太高导致项目无法启动最开始我图省事直接用了 SpringBoot 3.x结果项目一启动就是一堆报错核心原因有两个一是 SpringBoot 3.x 要求 JDK 17 及以上二是原来的 javax.servlet 包变成了 jakarta.servlet很多老版本依赖不兼容。MyBatis Plus 和部分工具类在没有适配 SpringBoot 3 的版本时会出现找不到类的异常。我的建议很简单不要为了用新版本而用新版本。SpringBoot 2.7.x 在功能上完全满足这个项目的需求而且资料丰富、兼容性好。如果你的 pom.xml 里已经用了 3.x把版本号改回 2.7.5同时确认 JDK 是 1.8然后 Maven 重新导入基本能解决绝大多数启动问题。还有个常见现象是 Lombok 版本和 JDK 版本不兼容导致编译失败。解决方法是把 Lombok 版本升级到 1.18.22 以上JDK 1.8 搭配 Lombok 1.18.22 以上一般不会出问题。如果 IDEA 里无法识别 getter 和 setter记得在设置里安装 Lombok 插件并开启注解处理。6.2 Vue 打包后布局异常和白屏开发模式下页面正常打包部署后出现样式错乱或者白屏这个问题几乎每个用 Vue 做过部署的人都会遇到。原因一般是 publicPath 配置不对。默认情况下打包后的静态资源路径是绝对路径 /如果前端文件不是放在服务器根目录而是放在子路径下资源就会 404页面自然白屏。解决方法是把 vue.config.js 里的 publicPath 设为 ./这样生成的 index.html 里引用的 JS 和 CSS 都变成了相对路径。改完配置后重新执行 npm run build 并替换服务器上的 dist 文件。如果用的是 Vue CLI 4 以上版本publicPath 字段在 vue.config.js 里如果直接用的 create-react-app 这类工具替代方案是修改 package.json 里的 homepage 字段原理是一样的。还有一个低级但常见的坑打包前没有把接口地址改成生产环境的域名或 IP。开发时 baseURL 是 /api依赖代理转发到本地后端生产环境如果 Nginx 代理配置好了没问题但如果后端接口地址变了要在 request.js 里调整 baseURL 或者在后端网关层面做转发。这个检查清单我建议每次都走一遍。6.3 MySQL 连接不上和驱动报错MySQL 连接不上是部署阶段影响最持久的问题。报错信息分几种Access denied for user 表示账号密码错误Public Key Retrieval is not allowed 表示连接方式需要调整Communications link failure 表示数据库服务没启动或 IP 端口不对。我排查的顺序是先用命令行工具测试能否连上数据库再检查配置文件里的连接 URL 有没有写错数据库名和时区参数。MySQL 8.0 的连接 URL 里建议加上 allowPublicKeyRetrievaltrue 和 useSSLfalse 两个参数前者解决部分客户端认证失败问题后者避免安全证书相关的警告。驱动依赖用 mysql-connector-java 8.0.28 以上版本如果用的是 spring-boot-starter-parent 统一管理依赖版本一般不需要单独写版本号。开发调试时建议在 application.yml 里把 MyBatis Plus 的日志打印打开map-underscore-to-camel-case 设为 true这样执行 SQL 时可以在控制台看到完整的语句出了问题也容易定位。正式部署时将日志级别调到 warn避免刷屏。6.4 跨域请求被拦截的排查思路前端页面能打开接口调用报跨域错误这在前后端联调阶段很常见。报错信息里一般会出现 CORS 字样。我的排查思路是先看清楚请求是发到哪个端口如果直接发到 8088 而后端没有配置 CORS就补一个跨域配置类。如果发到 8080 端口说明代理没有生效重点查 vue.config.js 的 proxy 配置有没有写对。后端 CORS 配置我用了 WebMvcConfigurer 的 addCorsMappings 方法允许所有来源、所有方法、所有请求头开发环境够用。生产环境尽量限制具体来源防止无关网站调用你的接口。如果你用了 Spring Security还要注意 CORS 配置和 Security 的过滤器顺序否则配置了也可能不生效。还有一点容易误导人浏览器报的跨域错误不一定真的是后端拒绝有可能是请求已经发出去但后端返回了 500然后浏览器把它包装成了 CORS 错误。遇到这种情况先看 Network 面板里这个请求的 HTTP 状态码如果是 500优先处理后端接口异常而不是纠结跨域配置。7. 写在最后的个人建议搞完这套系统前前后后我大概用了两个多星期第一周写后端接口第二天到第三天集中把前端页面搭起来剩下时间全花在联调和部署文档上。实际体验下来最大的经验是不要想着把系统做得多复杂把核心租车流程做干净、异常处理做好、文档写明白就已经超过大半数的毕业设计了。答辩时重点是讲清楚技术选型原因和核心业务流程别背概念老师一问到具体实现能答上就行。如果你拿到的就是这套源码我建议你拿到手以后第一件事不是直接跑起来而是把数据库脚本里的表结构挨个看一遍把 order 表的字段和状态含义搞清楚然后顺着“用户下单 - 管理员处理 - 还车结算”这条链路把代码走一遍。这个过程中你会发现自己能改的地方特别多比如加一个押金字段、做一个车辆评价功能任何一个小的功能扩展都可以写进论文的创新点里。最后还有一个很实用的小技巧写论文的时候把数据库设计部分放在前面重点写E-R 图、表结构说明、状态流转图这些内容老师特别爱看。代码部分不用大段贴把你认为最核心的订单状态流转代码和计费逻辑放上去配合文字说明就够了。祝大家都能顺利通过答辩。