简介：这是一套基于Vue3与Spring Boot3技术栈开发的网约车平台小程序完整源码，面向前端、后端及全栈开发者，适用于毕业设计、课程实训、企业原型快速搭建等场景，解决出行类应用前后端协同开发与高并发架构落地的实际问题。压缩包共37个文件，涵盖10个Java后端核心业务类、4个CSS样式文件、4个JS交互逻辑脚本、2个HTML页面模板、2个YML配置文件及数据库设计说明PDF、算法实现Java文件等，结构清晰，模块划分明确，便于理解订单调度、用户管理、司机接单等关键流程。资源包大小为2.87MB，轻量易部署。目前已有48人学习下载，配套必读文档与配置说明PDF，提供从环境搭建、接口调用到数据库初始化的完整实施路径，代码采用Composition API与Spring Boot 3响应式特性，兼顾可读性与工程实践性，是掌握现代Web全栈开发的典型参考案例。 做全栈开发这几年，我经手过的项目少说也有二十来个，但像“网约车平台小程序 + Vue3 + Spring Boot 3”这样一套完整的实战源码，确实值得专门写一篇长文来拆解。不论你是准备做毕业设计、想接私活赚点外快，还是打算认真搞一个自己的出行类产品，这套技术组合基本覆盖了当前中小型全栈项目的主流玩法。今天我就从项目架构、前端小程序、Vue3 管理后台、Spring Boot 3 后端四个维度，把这里面的核心设计思路、关键技术选型和实操细节全部盘一遍，最后再把源码跑起来的步骤和排坑经验分享出来，尽量让你拿着这篇文章就能把项目玩明白。
1. 项目背景与技术选型拆解
1.1 为什么是“小程序 + Vue3 + Spring Boot 3”这个组合
先说一个很多新手容易忽略的点：一个网约车平台，本质上是三个端的问题，分别是对着乘客的小程序端、对着平台运营人员的后台管理端、以及最核心的服务端。三端技术选型如果各自为政，开发和维护成本会成倍上涨。
这个项目选择微信小程序作为乘客端，原因很直接：微信生态的流量红利还在，用户不需要额外下载App，扫码即用，而且微信支付、位置授权、地图组件这些能力都是现成的，正好覆盖网约车最核心的“叫车 - 定位 - 支付”闭环。小程序的开发成本相比原生App低很多，一套代码同时跑在iOS和Android上，对初创团队来说是非常务实的起点。
管理后台选择 Vue3，我也是举双手赞成的。Vue3 的 Composition API 让代码复用和逻辑组织变得非常清晰，尤其是在后台管理系统这种大量表单、表格、弹窗交互的场景下，用<script setup>配合自定义 hooks，能比 Vue2 时代的 Options API 少写至少三成样板代码。而且 Vue3 的响应式系统基于 Proxy 重构之后，性能和对新特性的支持都更好，配合 Element Plus 这类现成的组件库，后台页面的开发速度非常可观。
后端选择 Spring Boot 3 则是稳定性和生态的考量。Java 在微服务、安全框架、事务管理这些方面的沉淀是很深厚的，Spring Boot 3 基于 Spring Framework 6，默认使用 Jakarta EE 9+ 规范，支持 Java 17 以上的长期支持版本，性能和安全都有保障。虽然相比 Go 或 Node.js 重一些，但中小型团队如果要兼顾业务迭代和系统稳定，Spring Boot 依然是我个人最推荐的后端框架。
1.2 项目整体架构与核心业务闭环
一套完整的网约车平台程序，业务闭环大概是这样的：乘客在小程序端发起叫车请求，后台根据乘客的出发地和目的地进行路径规划，将订单推送给附近匹配的司机端（在这个项目里司机端可以先复用管理后台的角色管理做一个简化版），司机接单后按照导航去接送乘客，行程结束后根据计费规则算出费用，乘客在线支付，平台从中抽成。
从架构上看，这个项目分成了三层：
- 小程序端：面向乘客，负责用户注册登录、发单叫车、行程展示、支付订单、订单评价等。
- Vue3 管理后台：面向平台运营方，负责司机审核与管理、订单监管、计费规则配置、数据看板等。
- Spring Boot 3 后端：提供统一的 RESTful API，负责业务逻辑处理、数据持久化、鉴权、支付对接等。
这个架构其实是目前市面上非常经典的前后端分离模式。小程序和后台都只通过 HTTP 接口跟后端通信，彼此不直接依赖，这样不管是后续要加独立的司机App，还是要把后端拆成微服务，都有足够的扩展空间。
1.3 这套源码覆盖了哪些核心场景
我拿到这套源码之后，先把核心模块跑了一遍，发现它覆盖的范围相当完整。除了最基础的注册登录、叫车接单，还包括了乘客端的历史订单查询、常见地址管理、发票信息填写，管理后台的司机审核、订单管理、优惠券管理、计费参数配置等模块。
说实话，市面上很多打着“网约车源码”旗号的项目，其实就是个简单地图打点加一个订单表，这套源码的完成度比那些高出一大截。如果你是想学习完整业务闭环的开发者，这套代码里关于订单状态流转、价格计算、接口鉴权这几个模块，含金量是相当高的，值得反复研究。
2. 小程序端核心实现细节
2.1 目录结构设计与分包异步化实践
打开小程序端代码，第一眼看上去最舒服的不是页面多漂亮，而是目录结构非常规整。我建议你在动手改代码之前，先把目录结构看一遍：
miniprogram/ ├── pages/ # 主包页面 │ ├── index/ # 首页（地图 + 叫车入口） │ ├── login/ # 登录页 │ ├── order/ # 订单页 │ └── mine/ # 个人中心 ├── packageDriver/ # 司机相关分包 ├── packageOrder/ # 订单详情分包 ├── components/ # 公共组件 ├── utils/ # 工具函数 └── app.js # 小程序入口为什么要把部分页面放进分包？这里涉及微信小程序的包体积限制。小程序的整个主包默认上限是 2M，如果地图 SDK、图表库、所有页面全部塞进主包，很容易超限，而分包可以把一些非首屏需要的页面拆出去，让主包保持精简。
这里特别说一下“分包异步化”这个点。我在packageOrder分包里看到了基于异步化的组件和页面引用写法。当用户从订单列表跳转进入订单详情页时，使用异步化可以不用等整个分包加载完毕才跳转，而是页面加载的同时用占位组件过渡，体感上会明显快很多。这部分代码不多，但很值得学习，是微信基础库 2.20.2 之后比较推荐的性能优化手段。
2.2 乘客端的核心页面与交互逻辑
通常进入小程序之后的首页就是地图页，整个用户动线大概是：打开页面自动定位到当前位置，点击“要去这里”选择目的地，确认后展示预估价格和距离，点击确认叫车，系统寻找附近司机，司机接单后展示司机距离和预计到达时间。
代码里首页的核心逻辑集中在pages/index/index.js，有三个关键点值得专门说一下。
第一个是定位。现在的做法是先调wx.getLocation拿到经纬度信息，再通过后端接口做逆地址解析，把经纬度换算成具体的地址文本。注意，wx.getLocation接口需要在app.json里声明permission，并且还需要在微信公众平台后台开通“地理位置接口”的权限，否则线上会报错。
第二个是单选框的处理。订单页面里选择了“现在叫车”还是“预约叫车”时，用的就是微信小程序的radio-group组件。这个小细节有坑：radio-group的bindchange事件里，e.detail.value是字符串而不是对象，所以你不能直接拿去当布尔值用。我见过不少新手在这边判断if (e.detail.value)然后怎么都跑不对，要记得先转换成布尔值或者直接和字符串常量做比较。
第三个是地图选点。微信小程序官方现在有wx.chooseLocation可以直接拉起微信自带的地图选点，不用自己引入第三方地图SDK。在项目里目的地的选择用的就是这个接口，省掉了大量地图交互的开发工作。唯一要注意的是用户拒绝授权后的降级处理，正常点“取消”不代表拒绝授权，需要区分fail回调里的errMsg是chooseLocation:fail cancel还是chooseLocation:fail auth deny，前者直接忽略，后者需要引导用户去设置页打开权限。
2.3 地图选点与行程轨迹的实现思路
在这个项目中，地图相关的功能主要是乘客起终点选择和司机位置展示。这里有一个关于天地图组件的点，有些开发者会在技术选型时纠结“微信小程序可以使用天地图画地图组件吗”这个问题。
我的答案是可以，但要分情况。如果你只是展示静态位置、画折线轨迹，天地图的 Web 服务 API 完全可以配合小程序的map组件用，只需要在天地图官网申请一个浏览器端 key，然后用它的接口做逆地址解析、路径规划，把结果数据塞给小程序原生的 map 组件去渲染就行。但如果你需要小程序原生 map 组件那样的手势交互、marker 动画、控件覆盖，那还是直接用 SDK 类方案更省心，因为原生 map 组件是一个原生组件，层级和普通组件的覆盖关系不太一样，调整起来比较折腾。
在这个项目里，路径规划和里程计算走的是后端接口，前端负责把拿到的坐标点数组通过polyline属性画到 map 组件上。这里要注意polyline的points数组不能为空，否则地图会渲染异常，而且坐标顺序必须是连续的，不能把乱序点传进去，不然画出来的线会非常奇怪。
2.4 小程序端表单与常见样式细节
关于表单，项目里乘客填写乘车人信息、发票抬头等模块，用的是小程序自带表单组件。微信小程序的表单没有像 Vue 里那种双向绑定，每个input都需要自己监听bindinput事件，然后把值存到data里。代码里封装了一个通用的handleInput函数，通过><script setup> defineProps({ modelValue: { type: Object, default: () => ({}) } }) const emit = defineEmits(['update:modelValue', 'search']) function onChange(field, value) { emit('update:modelValue', { ...props.modelValue, [field]: value }) } function handleSearch() { emit('search') } </script>
父页面这样用：
<template> <FilterBar v-model="filters" @search="loadOrderList" /> </template> <script setup> const filters = ref({ status: '', startTime: '', endTime: '' }) const loadOrderList = () => { // 根据 filters 请求后端接口 } </script>v-model在组件上的原理其实就是:model-value加上@update:model-value，代码里通过defineEmits定义事件类型，可以保证组件通信的类型安全，也方便后续维护。我在实际开发过中通常建议把所有组件通信的事件名都集中在一个常量文件里或者用 TypeScript 的接口约束住，不然项目大了很容易出现事件名拼写不一致、怎么都触发不了回调的情况。
3.3 computed 的使用场景与依赖追踪
在管理后台的订单金额统计、司机评分计算这些场景中，computed几乎是绕不开的。Vue3 的 computed 是基于副作用函数和依赖追踪机制实现的，当 computed 读取了响应式数据，它就会自动把这些数据注册为依赖，依赖变化时 computed 会重新求值，而模板里使用了这个 computed 的部分也会自动重新渲染。
举一个实际案例。在订单管理页面，需要根据当前选中的订单状态，动态计算出“预计平台抽成金额”：
<script setup> import { ref, computed } from 'vue' const orderTotal = ref(58.6) const commissionRate = ref(0.15) const currentStatus = ref('completed') const estimatedCommission = computed(() => { if (currentStatus.value !== 'completed') { return 0 } return (orderTotal.value * commissionRate.value).toFixed(2) }) </script>这个计算属性比直接在模板里写{{ currentStatus === 'completed' ? (orderTotal * commissionRate).toFixed(2) : 0 }}要清晰得多，最重要的是它有了名字，后续要改逻辑只需要改这一处。
依赖追踪的细节这里多说一句，Vue3 对 computed 的依赖收集是惰性的，只有 computed 被读取时才会触发求值，这跟watch的主动监听不同。所以如果你在 computed 里做了一些异步请求，那是反模式的，computed 应该是纯同步计算，异步逻辑交给watch或事件回调。
3.4 Tabs 标签页样式定制与常用后台页面结构
Vue3 管理后台里还有一个比较常见的需求是“Tabs 标签页样式”的定制。网约车管理后台的订单模块，通常需要按“全部 / 待接单 / 进行中 / 已完成 / 已取消”这些状态来分页签切换。Element Plus 的el-tabs默认样式比较基础，一般都会做一些定制。
<el-tabs v-model="activeStatus" @tab-click="handleTabClick"> <el-tab-pane label="全部" name="all" /> <el-tab-pane label="待接单" name="pending" /> <el-tab-pane label="进行中" name="ongoing" /> <el-tab-pane label="已完成" name="completed" /> <el-tab-pane label="已取消" name="cancelled" /> </el-tabs>定制样式的核心思路是覆盖 Element Plus 暴露的 CSS 变量。现在 Element Plus 的主题定制已经做得比较成熟了，你可以用 CSS Vars 直接覆盖--el-tabs-header-height、--el-color-primary等变量。如果你用的是 scss，还可以在引入 Element Plus 样式之前定义$colors里的 primary 色值来全局统一主题色。
这背后其实是一个更通用的后台管理系统开发思路：页面结构往往是“顶部筛选器 + 中间表格 + 右下角分页器”，再加上弹窗、抽屉、表单。代码里订单管理页面就遵循了这种结构，它把不同状态下的订单列表逻辑收敛到一个loadOrders方法里，通过切换 tab 时传入的 name 来重置分页参数并拉取对应数据。这种方法虽然不花哨，但很实用，稳定，也容易排查问题。我在之前的项目里也见过有人为了“优化交互体验”把每个状态单独拆一个页面，结果光是维护列表状态就花了两倍的精力，所以我个人还是推荐这种单页面多状态切换的方案。
4. Spring Boot 3 后端核心设计与实现
4.1 后端分层架构与模块划分
Spring Boot 3 的代码组织方式我认为比较标准，也是推荐大家照抄的。按照常见的分层架构，整个后端基于标准的 Controller - Service - Mapper 三层，外加 config、common、entity、dto、vo 等支撑包。
com.example.ridehailing/ ├── controller/ # 接口层：接收请求、返回响应 ├── service/ # 业务层：核心业务逻辑 ├── mapper/ # 数据访问层：MyBatis-Plus 的 Mapper 接口 ├── entity/ # 数据库实体 ├── dto/ # 入参对象 ├── vo/ # 出参对象 ├── config/ # 配置类：WebMvc、拦截器、CORS等 ├── common/ # 通用类：统一返回结果、异常处理、常量等 └── RidehailingApplication.java # 启动类这个分层结构的核心价值在于职责分离。Controller 只做参数接收和响应包装，不写任何业务逻辑；Service 层承载业务规则和事务控制；Mapper 层只负责数据库操作。这样一旦出现线上问题，你很快就能定位到问题在哪一层，而不用在一堆面条代码里翻找。
如果你是第一次看 Spring Boot 3 的项目，可以先从pom.xml开始，看看它引入了哪些依赖。这个项目用到了spring-boot-starter-web、mybatis-plus-spring-boot3-starter、mysql-connector-j、spring-boot-starter-validation、jjwt等。既然项目是 Spring Boot 3，要注意之前用的javax.*的包名已经换成了jakarta.*，这会导致一部分老的教程代码直接编译不过去，网上搜代码的时候要注意过滤版本条件。
4.2 核心业务表设计与订单状态机
网约车最核心的业务数据就是订单。我把这套源码的数据库表结构梳理了一遍，发现订单表order_info设计和常规电商订单有比较大的差异，主要体现在它必须记录位置相关的字段。粗略看一下，核心字段大概有：
| 字段 | 说明 |
|---|---|
| id | 订单ID |
| order_no | 订单编号（业务唯一） |
| passenger_id | 乘客ID |
| driver_id | 司机ID |
| start_lng / start_lat | 起点经纬度 |
| end_lng / end_lat | 终点经纬度 |
| start_address / end_address | 起终点地址文本 |
| status | 订单状态码 |
| amount | 实付金额 |
| estimate_amount | 预估金额 |
| create_time / finish_time | 创建与完成时间 |
其中status字段是最值得关注的设计。代码里把订单状态定义为字符串常量，常见的有：PENDING（待接单）、ACCEPTED（已接单）、ONGOING（进行中）、COMPLETED（已完成）、CANCELLED（已取消）。不同状态间的流转不是任意发生的，比如已取消的订单不能变成已完成，已完成订单也不能回到进行中。
我建议你把这段状态机逻辑画成这样的对照关系后，硬编码到 Service 层里：
PENDING->ACCEPTED司机接单ACCEPTED->ONGOING乘客上车ONGOING->COMPLETED乘客到达目的地，行程结束PENDING/ACCEPTED->CANCELLED司机或乘客取消
代码实现时通常是在updateStatus方法里用 switch 或 if 判断当前状态和目标状态是否满足流转条件，如果非法流转就抛异常。这个做法虽然看着土，但能避免非常多的并发和脏数据问题，比单纯开放一个updateStatus接口要可靠得多。我之前做过一个外卖平台的订单模块，就是因为早期图省事没做状态校验，结果出现了用户取消订单后又“被完成”的诡异 bug，排查了整整两天。
4.3 安全认证与 JWT 鉴权
后端目前有面向小程序乘客和管理后台运营方两拨用户。这两个角色权限不同，需要不同的鉴权策略。小程序端用的是微信登录wx.login拿 code，然后后端调微信接口换 openid，接着签发 JWT token。管理后台则是传统的账号密码登录，登录成功后同样发 JWT token。
JWT 的实现思路我在这里展开讲一下，因为这是很多新手最容易踩坑的地方。
// 生成 token String token = Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", userRole) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 60 * 60 * 1000L)) .signWith(secretKey) .compact(); // 解析 token Claims claims = Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(token) .getBody();这里面有三个比较关键的注意点：
- 过期时间：项目里设置的是 7 天过期，在实际运营中建议把 access token 的过期时间缩短到 2 小时左右，再配合 refresh token 做续期，安全性和体验都能兼顾。
- 签名密钥：一定不要写死在代码里然后提交到 Git，我倾向于放到
application.yml里，或者是环境变量中。密钥泄露意味着任何人都可以伪造 token，整个鉴权体系就形同虚设了。 - 解析异常：JWT 解析时的
ExpiredJwtException、SignatureException必须做统一异常处理，否则 Spring 默认返回的是 500 错误，前端很难区分是 token 过期还是 token 非法。
拦截器方面，项目里有一个JwtInterceptor实现了HandlerInterceptor，在WebMvcConfig里配置了拦截路径。这里要留意，/api/auth/**、/api/callback/**这类白名单路径记得配 excludePathPatterns，不然用户还没登录就被拦截了，会白白浪费排查时间。
4.4 支付与地图服务的对接思路
支付功能在网约车项目里是核心流程的一环，但这套源码里支付部分是有意做成了“模拟支付”的模式，不会真实调用微信支付。为什么这样做？原因很现实：真正跑通微信支付需要企业资质、商户号、证书等一系列前置条件，个人开发者很难具备这些条件。
代码里支付模块的做法是，当订单状态到达完成节点，用户在支付页面调用pay/payOrder接口，后端在payOrder方法中生成一个模拟的支付流水，随机生成一个支付单号，把订单状态改为已支付，然后返回支付成功的结果。这样就把整个业务流程给串起来了。
如果你要接真实支付，替换逻辑其实很清晰，核心就是在PayService中把mockPay方法替换为微信支付 V3 的 JSAPI 下单，前端拿到支付参数后调wx.requestPayment拉起收银台，然后通过回调通知把支付结果回写到订单上。这里我建议首次接入时先把微信支付的证书序列号、商户号、APIv3密钥三个配置项整理好，提前把后端回调地址配到内网穿透工具上调试，这样前后端联调会顺畅很多。
地图服务方面，项目用的是高德地图 Web 服务 API 来做路径规划和距离计算。如果你也想用这个方案，需要先去高德开放平台申请 Web 服务 key，然后在业务代码里通过RestTemplate或HttpClient调用https://restapi.amap.com/v3/direction/driving接口，拿到路径距离和预计耗时。
5. 源码本地运行与部署指南
5.1 环境准备与项目初始化
我把整套源码从零跑通大概花了半天时间，主要是中间有几个配置坑。先把环境要求列出来：
- JDK 17 或以上（Spring Boot 3 的最低要求是 Java 17）
- Maven 3.8+
- MySQL 8.0+
- Redis 6.0+（如果有用到缓存和 session）
- Node.js 16+（Vue3 管理后台）
- 微信开发者工具（最新稳定版）
我的建议是按下面这个顺序来初始化，能少走很多弯路：
- 先建好数据库，名字随意，比如
ride_hailing，然后执行源码里的sql/init.sql脚本导入表结构和初始数据。 - 打开后端代码，在
application-dev.yml里修改数据库连接信息、Redis 配置、高德地图 key。 - 启动后端，确认能访问
http://localhost:8080/api/ping这类健康检查接口，能通说明环境没问题。 - 打开小程序目录，在
app.js里修改baseUrl为本机地址，用微信开发者工具导入并开启“不校验合法域名”选项。 - 打开 Vue3 管理后台目录，安装依赖
npm install，然后npm run dev启动开发服务器。
5.2 前后端联调的常见配置
联调是小程序开发里最容易出问题的环节。微信开发者工具对网络请求有比较严格的限制，当你在工具里调试时，需要在右上角“详情 -> 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，否则请求直接失败。
如果你是用真机预览，那就麻烦一些：真机上不校验域名这个选项没有用，必须用 HTTPS 接口。对于本地开发阶段，我建议用内网穿透工具把自己的电脑映射成一个公网 HTTPS 地址，把小程序端的baseUrl改过去，这样真机也能正常联调。
另一个容易踩的坑是本地开发时小程序的域名白名单。即使你开发的是体验版小程序，也需要在微信公众平台把请求的域名配置到“开发设置 -> 服务器域名”里。如果你只是本地调试，用“不校验合法域名”选项遮蔽一下即可，但上线前一定要记得配置真实域名。
5.3 实际部署中的踩坑记录
部署的时候有几个问题几乎每次都会遇到，这里整理下：
第一个是跨域问题。如果你把 Vue3 管理后台和后端分开部署，或者本地开发时后端没有配置 CORS，浏览器会直接拦截跨域请求。项目里在WebMvcConfig已经配置了CorsRegistry，允许的 origin 是*，这在开发阶段够用。但生产环境我建议把*改成实际的前端域名，否则任何网站都能往你的后端发请求，容易出现恶意刷接口的问题。
第二个是 HTTPS 证书问题。小程序正式版要求所有接口必须走 HTTPS，且 TLS 版本不能低于 1.2。如果你用的是 Nginx 做反代，要注意配置ssl_protocols TLSv1.2 TLSv1.3。如果证书配置完还是报 SSL 错误，大概率是证书链不完整，需要把中间证书也放到ssl_certificate配置里。
第三个是图片和静态资源存储。管理后台如果涉及上传司机头像、证件照片，默认是保存在本地磁盘的，这在单机部署下没问题，但如果你后续想上多台服务器或者容器化部署，一定得把文件存储切到 OSS 或其他对象存储方案。这个项目目前没有做分布式存储设计，算是一个可以后续优化的点。
第四个是端口和进程管理。后端如果用的是java -jar直接启动，SSH 断开之后进程可能跟着死掉，最好用systemd管理服务或者用nohup后台运行。线上环境我建议加一个-Xms512m -Xmx1024m的 JVM 参数限制内存占用，不然小内存服务器很容易被撑爆。
6. 常见问题与开发经验总结
6.1 我在实际开发中踩过的坑
这里集中整理几个最有代表性的问题，方便你遇到的时候快速定位。
小程序定位失败
症状：页面一直转圈，提示“获取定位失败”。原因排查顺序：先看app.json有没有配置permission.scope.userLocation，再看微信公众平台是否开通了位置接口，最后查wx.getLocation的调用时机，不要在onLoad里太早调用。如果以上都没问题，检查授权状态，用户拒绝过一次之后你需要引导他重新授权，否则每次都会失败。
订单状态错乱
症状：已取消的订单突然变成了“进行中”。几乎可以断定是 Service 层没有做状态流转校验，或者并发情况下两个请求同时读到了旧状态。解决办法就是我在 4.2 节说的状态机校验，最好再加一个乐观锁版本号字段。后端加状态判断看起来多写了几行代码，但实际上是在保护你的业务数据，这笔投入特别值得。
管理后台列表页白屏
症状：控制台报Cannot read properties of undefined (reading 'xxx')。原因通常是后端接口返回的数据结构和前端tableData绑定不一致，比如后端返回了{ code: 0, data: { records: [...] } }而前端直接用了res.data.rows，自然取不到值。我的排查习惯是先在控制台打印接口返回，确认字段名，再加一个空数据兜底条件。
Vue3 响应式数据不更新
症状：页面上的数字变了，但视图没变。这类问题绝大多数是因为改了普通对象而不是 reactive/ref 包装的对象。比如在script setup里直接声明let count = 0，然后count++，视图当然不会刷新。要改成const count = ref(0)，再用count.value++。这个对刚从 Vue2 转过来的开发者尤其容易踩，我见过很多次了。
Spring Boot 接口返回 500 但不打印日志
症状：Postman 请求接口显示 500，控制台看不到堆栈。大概率是全局异常处理把异常吃掉后只返回了错误码，没有在服务端打印日志。解决方法是给全局异常处理类加上log.error("xxx", e)，把堆栈打印出来。如果你用的是@RestControllerAdvice，记得给每个方法加上日志输出，不然排查问题会非常痛苦。
6.2 这套源码可以怎么继续扩展
从我的视角看，这套网约车项目源码已经具备了实际运营的基础能力，但仍然有几个方向可以扩展：
第一个是增加司机端独立小程序或者 App。目前司机角色是在管理后台里操作，体验上不如司机端 App 好，后续可以做司机专属的小程序，功能包括接单推送、导航、实时语音等。
第二个是增加消息推送。现在订单状态变化靠轮询，用户需要不断刷新页面才能看到订单状态。可以接入 WebSocket 或者小程序订阅消息，把“订单被接受”“司机已到达”等事件实时推给用户，体验能上一个台阶。
第三个是完善支付和发票系统。虽然代码里有模拟支付逻辑，真实对接微信支付之后还需要处理退款、对账、发票申请等流程。这些是商业化网约车平台绕不开的后端工程。
第四个是加入实时定位追踪。当前的位置更新主要靠前端主动上传，生产环境建议用 MQTT 或者 WebSocket 来做端到端的实时位置同步，否则司乘之间的位置传递有几十秒的延迟，体验比较糟糕。
最后再分享一点个人的体会
这套网约车平台小程序源码的技术栈比较经典，代码结构也规整，它不是那种只为了演示某个功能而东拼西凑的 demo 项目，而是按照真实业务流程做出来的。如果你是想学习全栈开发，我建议按“小程序 -> Vue3 后台 -> Spring Boot 后端”的顺序去读源码。小程序端能看到前端交互的执行细节，Vue3 后台能看到中后台通用能力是怎么封装的，后端的订单状态机和 JWT 鉴权值得你反复推敲。等把这三块都摸透，再尝试加一个新功能模块，比如优惠券或会员体系，这套代码就能变成你自己的项目了，面试时也拿得出手。从我个人的经验来看，读源码最重要的是不要浮于表面，要动手改一改、跑一跑，把遇到问题的过程记录下来，这种实战积累比看十篇文档都管用。
本文还有配套的精品资源，点击获取
