做计算机毕业设计最怕的不是题目太难而是选了个看起来简单、写起来全是坑的题目。我当年选课题的时候一眼就看中了“基于Spring Boot和微信小程序的代驾服务平台”这个方向原因很简单代驾这个业务天然适合小程序用户不需要装App、扫码即用司机端也能复用同一套小程序做角色切换再加上Spring Boot在后端生态里的成熟度整个项目的技术线条非常清晰。但真正动起手来我才发现这个题目要想做得“像样”远不止一个CRUD那么简单——订单状态流转、司机匹配、计费规则、位置上报每一个模块都能看出设计功底。这篇博文就是把我做这个毕设的全过程复盘一遍从选题动机、数据表设计、后端核心链路、小程序端落地到联调阶段踩过的坑、答辩现场的演示技巧全部摊开来讲。如果你也在做类似的毕设或者想用Spring Boot 微信小程序做一个带LBS属性的服务平台这篇内容可以直接当你的“避坑参考”。1. 为什么代驾平台是毕设的“黄金选题”业务闭环与技术覆盖双赢先说选题。很多人做毕设喜欢挑“图书管理系统”“学生选课系统”这类题目代码量少、查重容易过但答辩的时候老师问两句就露馅了——因为这类系统没有真正的业务复杂度。代驾服务平台不一样它有一个完整的业务闭环用户下单 → 系统匹配司机 → 司机接单 → 到达起点 → 服务开始 → 到达终点 → 费用结算 → 评价。这中间任何一个环节都可以展开成独立的功能模块无论是写论文还是做系统演示内容都非常饱满。更关键的是代驾业务的“场景感”极强。用户端需要地图选点、查看司机位置、实时跟踪行程司机端需要接单广播、导航到起点、开启服务、上报位置管理后台要能查看订单流转、司机状态、营收统计。三个角色、三种视图、一套数据模型这种结构天然适合做一个“前后端分离 多端适配”的演示项目放在答辩现场非常抓眼球。从技术覆盖的角度看这个题目几乎把Java后端的主流知识点都串起来了Spring Boot作为基础框架整合MyBatis-Plus做数据访问Redis做会话缓存和司机位置缓存WebSocket做订单状态实时推送微信小程序原生开发处理地图、定位、支付后台管理系统可以用Vue或Thymeleaf模板实现。对比一下其他选题你会发现这个题目的技术栈“性价比”极高——不会难到做不出来但足够让你在论文里写满三个章节的技术分析。选型的时候还有一个点需要想清楚为什么是小程序而不是H5或者App我的判断是代驾是典型的“低频但刚需”的LBS服务用户不可能为了叫一次代驾专门装一个App小程序“用完即走”的形态和这个场景完全匹配。而且微信小程序的地图组件、定位接口、支付流程都有官方成熟方案对毕设来说比原生App开发省心得多。技术评审老师问起来你只要把“LBS服务适合轻应用形态”这个逻辑讲清楚对方自然会认可。2. 需求拆解与数据表设计先算清楚业务账再写代码很多同学上手就建表建完表就写Controller结果写到一半发现字段不够用、状态对不上又要回头改表。我的习惯是先用“用户故事”把业务捋一遍把每个角色的操作路径画出来再落到表结构上。2.1 角色与核心业务流程代驾平台的核心角色有三个每一个角色的诉求都很明确用户乘客发布代驾需求 → 等待司机接单 → 查看司机位置 → 服务结束后付款 → 评价司机开启接单状态 → 获取附近订单 → 接单 → 到达起点 → 开始服务 → 结束服务 → 收款管理员审核司机资质 → 查看订单流水 → 处理异常订单 → 统计平台数据。把这三个角色的操作串起来系统的核心流程就是“订单生命周期”。这里必须先定死一个东西——订单状态机。我定义的状态流转是待接单(0) - 已接单(1) - 司机已到达(2) - 服务中(3) - 待支付(4) - 已完成(5)另外还有两个终态已取消(6)和异常单(7)。用户可以在待接单状态下取消司机在接单后也可以因为突发情况申请取消需要管理员审核或者记录取消原因。为什么要把“已到达起点”单独拆出一个状态因为从商业逻辑上讲司机到达起点后如果用户未出现会产生“等候费”从技术上讲这个状态也是司机端“开始服务”按钮的前置条件。不拆出来后续计费逻辑就会变得很混乱。2.2 核心表结构设计基于上述流程我建了这些核心表表名说明关键字段user用户表openid, nickname, phone, balance, credit_scoredriver司机表user_id, real_name, license_no, car_no, car_brand, statusdriver_location司机位置表driver_id, longitude, latitude, update_timeorder_info订单表order_no, user_id, driver_id, start_addr, end_addr, start_lat, start_lng, end_lat, end_lng, status, distance, amount, create_timepayment_record支付记录表order_id, payment_no, amount, pay_type, status, callback_timedriver_review评价表order_id, user_id, driver_id, rating, content, create_time这里我特别想说一下order_info表的设计。有三个字段容易被忽略第一订单号order_no要独立于自增主键。业务上用户和司机都要拿订单号去沟通、查询自增ID太容易猜而且一旦分库分表就会冲突。我的方案是用“时间戳 随机数”生成20位以内的订单号Redis里用SETNX保证唯一。第二起终点经纬度必须冗余到订单表。申请好订单后前端会把经纬度传上来如果只存文字地址后面做路线回放、距离统计全都要重新调地图API非常被动。我在表里直接存了start_lat、start_lng、end_lat、end_lng四个浮点字段精度调到6位小数足够满足日常定位需求。第三金额字段用DECIMAL(10,2)绝不用FLOAT。Java后端用BigDecimal对应前端展示时再转换为字符串避免浮点精度误差。代驾平台涉及到钱这一点是底线答辩时老师很可能会问“金额精度怎么处理”完全可以直接答上来。2.3 计费规则的建模代驾的计费是一个容易埋雷的点。不同城市、不同时段的规则不一样但如果毕设里做一个灵活的规则引擎就过设计了。我的做法是把计费规则做成一张静态配置表fee_rule字段示例值city_code330100start_fee19.00start_distance_km5.0per_km_fee3.50night_start_time22:00night_end_time06:00night_surcharge1.20订单完成后计费逻辑可以这样算先判断是否在夜间时段如果在就按夜间单价上浮系数计算基础里程内收起步价超出部分按里程单价累加最后再加等候费可选。这套逻辑在代码里用一个FeeCalculator类封装输入订单和规则输出费用明细。答辩的时候把这张表拿出来解释评审老师一眼就能看懂你的计费模型是完整的。3. Spring Boot后端核心链路从微信登录到订单引擎后端是整个系统的“心脏”。这一章我会按核心功能模块拆开讲挑那些真正影响项目成败的点来说。3.1 项目初始化和依赖清单我用的是Spring Boot 2.7.x版本配合JDK 8原因很务实这是目前网上的教程、博客、毕设参考资料最成熟的版本组合踩坑的时候搜到的解决方案最多。不建议你为了“追新”用Spring Boot 3.x除非你已经对Jakarta命名空间的变更非常熟悉。核心依赖包括dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdredis.clients/groupId artifactIdjedis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependencyMyBatis-Plus的意义在于单表CRUD完全不用写SQL把精力集中在订单流转、匹配算法这些核心业务上。Redis在这里有两个用途一是做JWT Token的失效管理登出、强制下线场景二是存司机实时位置用GEO数据结构支持“附近司机查询”。WebSocket用于向司机端推送新订单、向用户端推送司机状态变更。3.2 微信登录与JWT会话管理微信小程序的登录逻辑是小程序端调用wx.login()获取临时code把code传给后端后端再拿着code AppID AppSecret 去微信接口服务换openid和session_key。后端拿到openid之后先去user表里查这个用户是否存在不存在就自动注册存在就直接发登录凭证。这里有一个毕设新手容易犯的错误直接把openid返回给前端当登录态。这是不安全的做法因为openid相当于用户的永久身份证号一旦泄露任何人都能伪装成这个用户。正确的姿势是后端签一个JWT返回给前端JWT的payload里放userId和role并设置过期时间。前端每次请求把Token放在Header里后端用一个拦截器统一解析。String token Jwts.builder() .setSubject(userId.toString()) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() 7200 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();需要注意后端调用微信jscode2session接口时要加一个HttpUtil封装并且对errcode做判断不是0就要打日志报警。微信接口偶尔会抖动一旦失败用户就登录不上所以这里还要加一个简单的重试机制。3.3 附近司机匹配从MySQL到Redis GEO代驾平台的核心功能之一就是“把订单派给附近的司机”。这个功能看起来简单实则是整个系统里最能体现技术深度的地方。第一种方案用MySQL实现。订单创建时拿着用户的经纬度到driver_location表里查“距离小于5公里且on_duty1”的司机。距离计算可以用球面距离公式6371 * 2 * ASIN(SQRT( POWER(SIN((lat1 - lat2) * PI() / 180 / 2), 2) COS(lat1 * PI() / 180) * COS(lat2 * PI() / 180) * POWER(SIN((lng1 - lng2) * PI() / 180 / 2), 2) ))这个方案对毕设来说完全可用司机数量在几千级别时MySQL的查询时间在几十毫秒完全能接受。但如果司机量级上来全表扫描就会成为瓶颈需要引入地理索引。第二种方案用Redis GEO。Redis 3.2之后提供了GEOADD、GEORADIUS等命令专门用来处理地理位置数据。我把每个在线司机的经纬度存成一个GEOSetkey是driver:onlinemember是driverId经纬度作为坐标。订单创建时GEORADIUS driver:online 120.1521 30.2811 5 km ASC COUNT 20一次查询就能拿到5公里内最近的20个司机性能远优于MySQL。我最终在系统里用的是Redis GEO方案因为实现成本并不高而且答辩时可以顺理成章引出“为什么用Redis做地理位置查询”这个亮点。Redis的集群部署、数据淘汰策略这些知识点都可以在论文里展开写。3.4 抢单并发控制乐观锁是毕设的最优解司机端是“抢单”模式一个订单推送给附近的司机后可能同时有多个司机点击“抢单”。如果没有并发控制数据库里就会产生脏读、覆盖更新的问题。业界一般有两种解法悲观锁SELECT FOR UPDATE和乐观锁版本号。我推荐毕设用乐观锁理由很简单实现简单不会因为事务持有时间过长导致死锁。具体做法就是在order_info表加一个version字段更新订单状态时带上条件UPDATE order_info SET status 1, driver_id #{driverId}, version version 1 WHERE id #{orderId} AND status 0 AND version #{oldVersion}如果更新影响的行数是0说明订单已经被别的司机抢走了就返回“手慢了”的提示。这是一个典型的CAS比较并交换思路能保证同一时间只有一个司机能抢单成功。这个点在答辩时是必问的“高并发场景是如何处理的”把乐观锁的原理和代码讲清楚分数直接上一个台阶。3.5 订单状态推送WebSocket的落地姿势代驾是强实时业务用户下单后司机端要马上收到接单广播司机接单后用户端要立刻感知到状态变化。HTTP轮询当然能实现但体验太差而且带宽浪费严重。我引入了WebSocket做实时推送。前后端的交互协议上我定义了一套简单的消息体{ type: NEW_ORDER, orderId: 1001, startAddr: 西湖区文三路138号, startLat: 30.2811, startLng: 120.1521, distance: 1.2 }每个司机建立WebSocket连接时后端会在Session字典里注册driverId - Session的映射。新订单创建后系统把订单ID列表推送给附近的司机司机抢单成功后后端会关闭这个订单的广播并给绑定司机发送ORDER_ACCEPTED给用户发送DRIVER_ASSIGNED。这里要注意一个问题也是我自己踩过的坑小程序原生WebSocket在切到后台一段时间后会被系统断开所以前端必须在onShow里重新建立连接后端也要做好断线重连时的状态补偿——司机重连后主动把当前正在进行的订单状态同步下来。4. 小程序端架构与页面落地角色切换、地图联动和请求封装小程序端是整个系统的“门面”老师演示的时候第一眼看到的不是后端逻辑而是页面效果。所以前端部分不能做得太糙但也不必过度复杂。4.1 原生小程序还是uni-app我做毕设时选的是原生微信小程序没有用uni-app。原因是原生文档齐全、社区问答多、调试工具稳定而且毕设只需要跑在微信一个平台上uni-app跨端的优势根本用不上。如果你打算以后把项目改成H5或者App可以换uni-app否则原生就是最省事的选择。这个选型逻辑在论文里也可以写一段体现你在做技术对比和思考。4.2 请求封装统一处理登录态和错误码小程序端所有网络请求我都封装在一个request.js里核心逻辑是请求前检查Token是否过期请求时自动带上Header响应后统一处理业务码遇到401自动重新登录。const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Authorization: Bearer wx.getStorageSync(token) }, success: (res) { if (res.data.code 401) { wx.removeStorageSync(token) login().then(() { request(url, method, data).then(resolve).catch(reject) }) } else if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg, icon: none }) reject(res.data) } }, fail: reject }) }) }封装的核心目的是把“业务逻辑”和“网络细节”分离页面里只需要调用const order await request(/order/create, POST, formData)这样写的好处是小程序每个页面都不会出现重复的登录判断和错误处理代码结构也清晰Code Review和答辩答辩都很体面。4.3 地图与定位模块代驾离不开地图。我使用的是微信小程序原生map组件 腾讯位置服务JavaScript SDK。腾讯位置服务是微信官方推荐的方案提供的qqmap-wx-jssdk可以直接在小程序里调用reverseGeocoder逆地址解析、direction路线规划等接口。用户端下单页面的核心体验是地图上选起点和终点使用wx.chooseLocation让用户直接选点比手动输入地址体验好得多。选好之后调用逆地址解析拿具体地址文字同时把经纬度传给后端。司机端的核心体验是接单后在地图上展示“从当前位置到用户起点”的规划路线服务开始时开启定时上报位置每5秒调用一次后端接口更新driver_location用户端就能在自己的地图上实时看到司机的移动小图标。这里有一个比较关键的细节定位权限必须在用户授权后才能获取。wx.getLocation和wx.chooseLocation都需要在页面里声明requiredPrivateInfos和permission。我当时因为忘了在小程序管理后台配置“位置接口”的说明文案提交审核时被拒了一次这也算是一个印象深刻的教训。4.4 用户端与司机端的角色切换我并没有做两个独立的小程序而是用同一个小程序根据登录身份来动态渲染页面。这个设计在业务上很合理一个用户既可以叫代驾也可以通过入驻申请成为司机。前端在登录后请求/user/info接口拿到role字段然后根据角色渲染不同的底部TabBar。这里要提醒一下微信小程序的TabBar是用配置文件静态声明的不同角色显示不同的TabBar不能通过配置实现只能自己用自定义TabBar组件来做。我最终是写了一个custom-tab-bar组件根据角色渲染不同的菜单项虽然代码量多一些但效果比固定TabBar好得多也显得项目更完整。4.5 支付流程与模拟支付的取舍代驾服务的支付环节标准做法是后端调用微信支付统一下单接口生成预支付单小程序端拿到wx.requestPayment所需的参数拉起支付面板支付成功后微信服务器异步回调后端通知支付结果。但毕设场景下我建议你认真考虑一下“模拟支付”的方案。原因有两个一是微信支付商户号申请需要营业执照等资质学生个人基本拿不到二是就算接入了真实支付涉及资金操作调试和安全性都会带来很多额外的麻烦。我的方案是后端预留了PaymentService接口正式环境下走微信支付但在配置里增加一个mock.paytrue开关模拟模式下支付接口直接返回成功并生成支付记录。这样既演示了完整的业务流程又不会卡在资质申请上。答辩时如果老师问“支付怎么实现的”你可以坦然地说“已实现支付接口对接的抽象层因商户资质受限演示环境使用模拟支付”这个回答反而体现了你对真实业务的理解。5. 联调阶段最容易踩的坑我替你把雷趟了一遍联调是整个项目最折磨人的阶段。前端、后端、微信平台三端配合任何一个环节出了问题呈现出来的现象都可能是“页面白屏”或“接口报错”。下面这几个坑是我实际踩过的每一个都写清楚现象、根因和解决方式。5.1 微信小程序域名白名单开发环境必须关闭校验小程序真机预览和模拟器请求后端接口时默认会校验“请求的域名是否在小程序管理后台配置过”。本地联调时后端地址是http://localhost:8080这显然不可能配置成合法域名。解决办法是在微信开发者工具的“详情 → 本地设置”里勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”。这个坑大多数人都知道但问题是模拟器上关掉校验之后真机预览时是不生效的。真机预览需要在“开发版”的调试模式下才能绕过校验而且每次开发者工具有更新这个设置可能会被重置掉要重新勾选。我建议你把这个设置项写在项目README的第一行——别问我是怎么想起来的。5.2 wx.login的code有效期只有5分钟登录流程里的wx.login()返回的code有效期极短5分钟之后就失效。如果你在获取code之后没有及时调用后端接口换openid重新拿起代码调试的时候就会拿到“invalid code”的错误。这个问题的难点在于排查路径容易走偏。我当初看到401错误后先是怀疑JWT解析问题、Token签发问题查了很久才发现是code过期。建议你在后端日志里把每次jscode2session调用的入参和返回值都打印出来排查效率会高很多。5.3 小程序模拟器精度差定位不准先别怀疑后端微信开发者工具的模拟器定位默认是“腾讯大厦”经纬度是写死的。如果你查看附近的司机列表时发现数据不对先看看调试工具模拟的是哪个位置。我当时做一个“按距离排序”的功能在模拟器上测试死活排不对折腾了半个小时才发现是模拟器位置和数据库里面的测试司机位置完全不在一个城市。解决方案很简单在模拟器的“传感器”面板里手动设置一个经纬度或者在代码里留一个调试模式允许手动输入经纬度。建议直接用后者因为真机调试时也需要这个开关来模拟不同地点。5.4 WebSocket连上又被断开小程序的生命周期管理小程序WebSocket连接最大问题是“不稳定”用户把小程序切到后台再回来连接基本就断了。我一开始没有做重连导致司机接单后用户端一直不刷新状态只能靠手动点击页面刷新按钮才看到“司机已接单”的提示。后来我的做法是onShow生命周期里检查WebSocket连接状态断开就重新连接同时后端在建立连接时把该用户当前正在进行的订单状态全量推下来保证重连后界面状态和服务器一致。千万不要只做增量推送不做全量状态同步否则重连后用户看到的就是一个“假死”的页面。5.5 MyBatis-Plus分页不生效少了分页插件用MyBatis-Plus做分页查询时如果直接写PageUser这样的参数会发现查出来的数据永远是全量的——这不是SQL写错了而是没有配置分页插件。MyBatis-Plus的分页功能是基于拦截器实现的必须在配置类里显式注册Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }这个坑非常典型几乎每个第一次用MyBatis-Plus的人都会踩。我是在做后台订单列表分页时发现的列表页一直显示全部数据一度还以为是前端分页组件的问题。所以如果你也用了MyBatis-Plus第一件事就是检查这个配置类在不在。5.6 跨域问题开发环境的CORS策略前端H5页面在联调时可以配置代理但小程序wx.request没有CORS的概念原生请求不会像浏览器那样预检跨域。如果你的后台管理系统也是用Web页面开发比如Vue项目请求Spring Boot接口那就必须处理跨域。我的做法是在后端写一个CorsConfig统一放行所有来源和请求方法Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns(*)和allowCredentials(true)不能同时直接使用allowedOrigins(*)某些Spring版本会报错用Patterns就不会。6. 从代码到答辩现场演示脚本与加分项设计最后聊一聊代码都写完、项目能跑通之后怎么在毕设答辩里把项目的价值完整展示出来。很多同学代码写得不错但演示时手忙脚乱或者讲不到重点上最终分数反而不如那些“项目简单但讲得清楚”的人。6.1 数据准备是演示的胜负手正式演示前一定要准备一批“演示数据”不要用空的数据库。我当时的方案是预置3个司机分别设置在不同的小区附近且都在接单状态预置2个用户账号一个用来下单一个用来记录历史订单再准备一条异常订单用于演示管理员处理流程。演示时最尴尬的场景就是“下单之后等了半天没有司机接单”因为附近根本没有司机在线。所以下单前一定要确认至少有一个司机处于空闲可接单状态并且它的位置真的就在用户附近。6.2 演示脚本的设计思路我的演示流程是严格按“一条完整业务线”走的打开用户端小程序登录定位到测试位置输入起点和终点发布代驾订单切换到司机端视角退出登录换账号看到新订单推送点击接单切回用户端看到“司机已接单”地图上显示司机实时位置模拟司机到达起点点击“开始服务”用户端进入服务中状态展示路线轨迹司机点击“结束服务”系统自动计算费用用户端付款模拟支付评价司机打开管理后台查看这笔订单的完整记录和统计图表。这条线走完几乎覆盖了系统的所有核心功能而且是一个真实的服务闭环。演示时不要倒腾无关功能越聚焦越好。6.3 答辩高频问题与应对思路做完演示老师通常会追问这几个问题“你这个系统的订单状态是怎么管理的”——把状态机图和状态流转的条件讲清楚这是一个标准答案。“如果两个司机同时抢单怎么办”——乐观锁的CAS更新逻辑影响到行数为0即抢单失败。“怎么确保司机位置是最新的”——Redis GEO定期上报 离线超时清理机制我说的是司机每5秒上报一次超过30秒没上报就从在线集合中移除。“为什么用Redis不用数据库存司机位置”——Redis GEO天然支持距离查询且是内存操作性能远超MySQL还能便捷做过期清理。6.4 高分扩展点给系统再加点“味道”如果你的时间允许我建议在基础功能之上做下面任意一到两个扩展会让项目完成度明显提升优惠券模块新用户注册送代驾券下单时抵扣涉及券的发放、核销、过期管理业务逻辑完整且常见微信订阅消息下单成功后推送一条订阅消息告知用户“司机已接单”比单纯的WebSocket消息更贴近真实场景管理后台数据可视化用ECharts展示每日订单量趋势、各时段订单分布、热门代驾区域这些是评委会觉得“有意思”的功能司机资质审核流司机注册后上传驾驶证和行驶证照片管理员在后台审核通过后司机才能开始接单这个功能能体现你对业务合规性的思考。写在最后回头看我做这个毕设的整个过程最难的不是某个技术点而是把整条业务链路完整跑通。写代码前一定要先把状态机画清楚、把数据表设计定下来、把角色边界理明白后面写起来就顺很多。如果你正在做这个题目我建议你先别急着敲代码花一个晚上把“用户下单到司机接单到服务完成”的流程在纸上走出来标注每个环节涉及的表和字段这会帮助你在后续开发中少走很多弯路。祝你的毕设顺利过关也希望你在这个项目里学到的“从业务出发设计系统”的思维能在以后的工作里继续发挥作用。