每年到了毕设启动的时间点私信里问得最多的题目之一就是“基于微信小程序的校园顺路代送平台”。这个题本身不算冷门但真正把它做出完整闭环的人其实不多绝大多数只做到“能下单、能显示”就停了答辩时被老师问两句就露馅。今天我就拿这个题目出来从需求拆解、技术选型、数据表设计到核心接口再到调试发布过程中踩过的坑完整走一遍。我会把方案分成两条路线一条是快速成型型用uni-app加云开发另一条是通用型uni-app写小程序前端后端用Java Spring Boot或Node.js。两条路线都会讲到并且会告诉你什么情况下该选哪条。如果你正在准备这个题目或者已经在做了但卡在某个环节这篇内容可以直接拿来当参考。1. 项目整体设计与思路拆解1.1 校园顺路代送到底在解决什么问题校园代送平台本质上是把“跑腿”这件事拆成了“发单”和“接单”两个动作。用户把小件物品的配送需求发出来比如从宿舍楼送个文件到实验楼、从快递点代取一个包裹、从食堂捎一份饭然后有空闲时间或者正好顺路的同学接单完成后获取一笔佣金。这个场景跟外面商业跑腿平台最大的区别在于“顺路”这个词。商业平台是专人专送成本高校园平台用户高度集中宿舍区、教学楼、食堂之间的距离短行为轨迹相对固定。所以不需要复杂的LBS调度只需要按地理位置、楼栋或者校区做简单筛选就能把订单匹配给合适的人。技术上要解决的真正核心不是“地图有多准”而是订单状态流转是否清晰、用户身份是否可信、以及发单人和接单人之间的沟通是否通畅。很多同学把这个项目做成一个简陋的“发布信息墙”没有状态机、没有接单权限控制这在答辩时特别吃亏。1.2 技术选型原生小程序、uni-app还是云开发先说结论如果前端你自己更熟悉Vue语法就选uni-app如果完全没接触过跨端框架直接用原生微信小程序也行。但从我带过项目的经验看uni-app对毕业设计更友好原因有三个。第一uni-app的组件和API基本封装了微信小程序的底层能力你只需要写一套Vue风格代码H5端和App端也能顺带跑起来演示的时候在浏览器里也能预览很方便。第二uni-app的插件市场里有大量现成组件比如下单、地图选点、图片上传等等能省下很多重复造轮子时间。第三搜索热度里大量出现“uniapp微信小程序”相关的关键词说明当前市场上这套方案的使用率已经非常成熟遇到问题很容易找到答案。后端方面时间真的不够用可以考虑微信云开发。云开发直接提供云数据库、云函数和云存储省掉了服务器、域名备案和HTTPS证书配置对纯前端功底的同学非常友好。但如果你对自己的简历有要求或者考研复试需要体现后端能力还是建议用Java Spring Boot MySQL的经典组合这个组合在毕业设计里性价比最高导师也认可。方案前端后端优点适合人群方案A原生微信小程序云开发全栈一体无服务器成本时间紧、无后端基础方案Buni-app云开发跨端方便组件丰富熟悉Vue、时间中等方案Cuni-appSpring Boot MySQL技术完整答辩加分有Java基础、想体现技术深度方案D原生小程序PHP/Node.js上手快有脚本语言基础即可我个人推荐方案C。理由很简单毕设核心考核的是工程能力和逻辑闭环不是框架炫技。Spring Boot写RESTful接口、统一返回结构、JWT或token鉴权、表关联查询这些技能以后找实习也会用到。而且数据库设计本身也是答辩时高频提问点。1.3 功能模块怎么划分才完整一个合格的校园顺路代送平台至少要包含三个端面的功能用户端、接单端、管理端。用户端负责发单、看订单状态、取消订单、确认完成、评价。接单端面向“有空闲时间的人”核心是查看顺路单大厅、抢单、标记配送中、确认送达。管理端是很多同学忽略的部分但毕设题里只要有“平台”二字导师默认你要有基本的管理功能。管理端不需要做得花哨能看用户列表、订单列表、处理用户反馈就足够。后端还要单独拆出三个模块用户鉴权模块、订单模块、消息与通知模块。鉴权包括微信登录的code2session换取openid以及自定义token的颁发与校验。订单模块是核心负责订单CRUD、状态流转、接单者匹配。消息模块在实现上不需要上WebSocket用微信订阅消息就够了做到“订单被接单时通知发单人”这个效果就算达标。2. 核心功能与流程拆解2.1 订单状态机与权限控制订单状态是这个项目最核心的逻辑也是我建议在答辩PPT里画得最清楚的一张图。状态不能多多了用户看不懂也不能少少了订单流转说不清楚。推荐用六个状态待接单、已接单、配送中、已完成、已取消、退款中。待接单是订单刚创建时的状态。用户下单后订单进入单大厅。接单者看到并点击接单订单状态变为已接单这时候要锁定订单其他接单者不能再接。这是一个非常容易漏掉的校验点——很多同学的代码里没有做并发控制导致多个人同时接同一单出现数据覆盖问题。已接单之后接单者去取件然后标记为配送中。真正的完成动作必须由发单人来确认也就是用户点击“确认送达”后订单才进入已完成状态。为什么这个动作一定要在发单人手里而不是接单人手里因为平台要保证用户的钱花得放心。如果允许接单人自己点完成那接单人拿了钱不办事也没人知道。这个设计细节在答辩时说出来老师会很认可。取消和退款是另一个并列分支。待接单状态下用户或接单方都可以取消这没有争议。难点在于已接单之后的取消。校园场景下更合理的方案是如果接单者已经接单用户要取消需要接单者同意接单者主动取消则记录一次“爽约率”超过阈值限制接单。这个逻辑不复杂但能体现你考虑问题比较全面。2.2 数据库表设计数据库表设计建议至少五张用户表、订单表、订单状态记录表、反馈表、评价表。如果你的用户端还要做余额支付就再加一张余额流水表。用户表最简单字段包括uid、openid、nickname、avatar_url、phone、role、create_time。这里role字段要区分普通用户和接单者吗我建议不分开一个用户既能发单也能接单通过订单当前的user_id和courier_id来区分正在承担的角色。这样实现起来更简洁也符合真实平台的设计习惯。订单表是整个系统的重心我给出一个参考字段结构字段名类型说明idbigint主键order_novarchar(32)业务订单号user_idbigint发单人IDcourier_idbigint接单人ID可空pickup_locationvarchar(64)取件地点pickup_detailvarchar(128)取件详细说明delivery_locationvarchar(64)送达地点goods_descvarchar(255)物品描述reward_amountdecimal(10,2)小费金额statustinyint状态0待接单1已接单2配送中3已完成4已取消5退款中create_timedatetime创建时间accept_timedatetime接单时间finish_timedatetime完成时间cancel_reasonvarchar(255)取消原因订单状态记录表用来记录每次状态变更的时间、操作人、旧状态、新状态、备注。这张表的价值在于可追溯。答辩时如果你能说清楚“每一个状态变更都有日志记录方便管理员后台追踪订单是否异常”那就比单纯写完订单增删改查的同学高一个层次。2.3 微信登录与昵称头像获取“小程序登录”很多人写了一大堆其实核心就三步wx.login拿到临时code把code传给后端后端用code调微信接口换取openid和session_key。openid要存到数据库作为用户的唯一标识。注意这里session_key千万不要返回给前端存着它涉及后续解密手机号等敏感操作必须保持在服务端。昵称和头像这块是个大坑。微信官方早就调整了规则直接用wx.getUserProfile弹出的授权弹窗已经拿不到真实昵称和头像返回的全是“微信用户”和默认灰色头像。热搜词里大量出现“java 微信小程序 怎么获取用户昵称和头像”说明这个问题确实困扰了很多人。正确做法是使用微信的“头像昵称填写能力”。在小程序里放一个button设置open-typechooseAvatar用户点击后可以选择自己的微信头像昵称则用input typenickname组件获取。uni-app里这两种组件也都有对应封装。我把示例代码写在实操部分到时候直接抄就行。2.4 支付与结算怎么取舍校园代送平台适合接入微信支付吗答案是不建议直接上微信支付。原因有两点。一是微信支付对商户类目审核严格很多学生个人没有营业执照即使借了资质也容易因为交易场景不清晰被拒二是在当前风控规则下如果小程序因支付场景触发了风控会出现“支付功能暂时无法使用”的红色警告这类问题处理起来非常耗费时间。更稳妥的做法是在平台上设计“余额体系”。用户先通过线下方式如当面转账充值或者干脆设成“完成后线下支付”。订单状态到已完成时系统展示应付金额由用户与接单者线下结算。这个方案虽然不如在线支付“高级”但胜在安全稳定。如果导师明确要求必须有支付闭环再考虑接入微信支付v3并提前准备好营业执照和商户号把退款流程也要做进去。3. 实操过程与核心环节实现3.1 前端页面的核心实现发布代送单uni-app页面结构上发布代送单是用户最常用的功能页面字段包括取件地点、取件详细描述、送达地点、物品描述、小费金额、期望送达时间。这里有个细节取件和送达地点不要用文本输入框建议做成固定楼栋选择器加载校园楼栋列表。这样用户可以盲选不出错后续做附近订单筛选也方便。关键代码如下这段是页面模板的核心部分放在了Popup弹窗里template view classpublish-page view classform-item text classlabel取件地点/text picker modeselector :rangebuildingList changeonPickupChange view classpicker-value{{ form.pickupLocation || 请选择取件楼栋 }}/view /picker /view view classform-item text classlabel送达地点/text picker modeselector :rangebuildingList changeonDeliveryChange view classpicker-value{{ form.deliveryLocation || 请选择送达楼栋 }}/view /picker /view view classform-item text classlabel物品描述/text textarea v-modelform.goodsDesc placeholder例快递包裹约3kg代取后放宿舍楼下 / /view view classform-item text classlabel小费金额/text input typedigit v-modelform.rewardAmount placeholder0.00 / /view button typeprimary :loadingsubmitting clicksubmitOrder发布订单/button /view /templatesubmitOrder的脚本逻辑需要做两件事先校验表单是否填完整然后调用后端创建订单接口。注意code这部分不能只调一个接口就完事要在成功回调里跳转到订单详情页并且实时更新发布列表。表单校验要考虑到rewardAmount如果是字符串类型转换成数值再提交。3.2 顺路单大厅与接单逻辑订单大厅就是当前所有“待接单”状态订单的列表。实现上做成分页列表每页10到20条滑动到底部自动加载下一页。不要一次性把全表数据都查出来那样数据量大以后页面会又卡又慢。接单的核心操作是点击“立即接单”。这个操作必须做两件事一是调用接单接口二是把按钮置灰并显示“已被接单”。这里的难点在并发锁后端接单接口里一定要用“原子更新”来防并发比如SQL语句写成UPDATE order SET courier_id ?, status 1 WHERE id ? AND status 0通过受影响行数是否为1来判断是否抢单成功。这是这个项目里技术含量最高的一个点面试时讲出来绝对是亮点。前端列表渲染可以这样组织async loadOrders() { const res await request({ url: /api/order/list, method: GET, data: { page: this.page, size: 10 } }); this.orderList this.page 1 ? res.data.list : this.orderList.concat(res.data.list); this.hasMore res.data.list.length 10; }另外在scroll-view或者onReachBottom里接上加载更多逻辑就行。如果发现列表里图片太多导致加载卡顿就把图片懒加载打开或者减少卡片里非核心元素的渲染。3.3 后端接口与联调要点后端接口设计建议遵循RESTful风格返回统一结构比如{ code: 0, msg: success, data: {} }。关键接口我列一下创建订单、查询订单列表、订单详情、接单、开始配送、确认送达、取消订单、获取楼栋列表、登录。Spring Boot实现创建订单接口的Controller大致如下RestController RequestMapping(/api/order) public class OrderController { Autowired private OrderService orderService; PostMapping(/create) public ResultOrderVO create(RequestBody Validated OrderCreateRequest req) { // 1. 获取当前登录用户 id通过拦截器从 token 中解析 Long userId UserContext.getUserId(); // 2. 组装订单实体初始状态设为待接单 Order order new Order(); BeanUtils.copyProperties(req, order); order.setUserId(userId); order.setStatus(OrderStatus.WAITING_ACCEPT.getCode()); order.setOrderNo(generateOrderNo()); order.setCreateTime(new Date()); orderService.save(order); // 3. 写一条状态流转日志 orderLogService.log(order.getId(), null, order.getStatus(), 用户发布订单); return Result.success(OrderVO.from(order)); } }顺序上要注意日志一定要在订单保存成功之后再写否则可能出现订单成功但状态日志缺失的问题。很多同学在写这种代码时把日志功能省掉了其实状态日志功能就是在这种场景里体现价值的。联调阶段建议直接用Apifox或者Postman先打后端接口确认每个接口的出入参都正确再连小程序前端。微信开发者工具里可以勾选“不校验合法域名”方便在本地联调。3.4 头像昵称填写能力的代码实现前面提到的头像昵称获取问题这里放上可直接用的uni-app写法。页面里放两个组件button classavatar-wrapper open-typechooseAvatar chooseavataronChooseAvatar image v-ifavatarUrl :srcavatarUrl classavatar / text v-else选择头像/text /button input typenickname v-modelnickname placeholder请输入昵称 classnickname-input /对应的脚本部分methods: { onChooseAvatar(e) { this.avatarUrl e.detail.avatarUrl; }, async saveProfile() { if (!this.avatarUrl || !this.nickname) { uni.showToast({ title: 请完善头像和昵称, icon: none }); return; } // 先上传头像到云存储或后端存下文件路径 const uploadRes await uni.uploadFile({ url: baseUrl /api/upload, filePath: this.avatarUrl, name: file }); // 再调用更新用户信息接口 const res await request({ url: /api/user/updateProfile, method: POST, data: { nickname: this.nickname, avatarUrl: uploadRes.data.url } }); if (res.code 0) { uni.showToast({ title: 保存成功 }); } } }需要特别注意的是chooseAvatar拿到的avatarUrl是一个本地临时文件路径必须先把图片上传到服务器拿到正式URL再保存到用户表里不能直接把临时路径存进数据库否则下次打开小程序头像会裂。4. 常见问题与排查技巧实录4.1 真机预览时接口请求不通这是最常遇到的问题。开发工具里一切正常一真机预览就全部请求失败。主要原因基本是域名校验没过。微信小程序要求所有request的域名必须配置在后台的request合法域名里而且必须是HTTPS。本地开发阶段可以在开发者工具的“详情-本地设置”中勾选“不校验合法域名”但体验版和正式版必须要配置真实HTTPS域名。如果只是拿后端同学电脑做演示用局域网IP加端口虽然能真机预览但也要在手机开启调试模式否则还是会被拦截。这里有个经验尽量早点去买一个便宜的域名简单的HTTP搭建好之后再申请一个免费的HTTPS证书。整个过程半天能搞定别拖到答辩前一天才弄。4.2 “获取不到昵称头像”的旧方案失效问题很多老教程还在用wx.getUserProfile配合button open-typegetUserInfo来拿用户信息但这个方案从2022年10月之后就全面失效了。现在的正确打开方式就是上文说的头像昵称填写能力。如果你接手的是别人之前写的代码看到页面上还挂着getUserProfile不要犹豫直接换成chooseAvatar和input typenickname。顺带提一句用户上传的头像最好做一次压缩微信临时文件路径下的图片可能很大直接上传会浪费服务器流量和存储。4.3 微信小程序抓包调试HTTPS请求联调时如果你和后端对接发现数据对不上最直接的办法是抓包看实际请求和响应。用Charles或Burp Suite抓取PC端微信小程序的HTTPS请求核心步骤是安装并信任Charles的根证书然后在Charles里配置SSL Proxying并设置好代理端口将PC端微信小程序的代理指向Charles。抓包能看到请求头、请求体、响应体方便排查token是否丢失、参数是否错位等问题。但有两个注意事项一是证书信任这步不做正确看到的全是乱码或Unable to verify certificate二是抓包工具会把HTTPS证书替换为自己的证书微信开发者工具可能会出现安全提示这时需要把工具里的证书校验关掉或者在Charles里把相关域名排除掉。抓包只用于自己开发的调试环境不要在小程序正式环境里使用。4.4 页面渲染与滚动相关的几个坑热词里有人提到uni-datetime-picker放在scroll-view里会出现滚动异常这个问题我也踩过。原因主要是日期选择器内部使用了弹层组件和scroll-view的滚动事件冲突表现形式是弹层关闭后列表还在惯性滚动或者选择器位置偏移。解决思路有三个第一用原生picker替代uni-datetime-picker校园代送场景只需要选日期和时段原生picker完全够用第二把日期选择器放到页面根节点不嵌在scroll-view内部让弹层挂载到body层级第三如果一定要用就给picker设置position: fixed定位。我实践下来最简单靠谱的方案还是用原生picker代码量反而少。另一个常见报错是saveImageToPhotosAlbum:fail多发生在用户拒绝过相册权限后。解决方法是先调用uni.getSetting检查权限状态如果已经拒绝要用uni.openSetting引导用户去设置页打开相册权限然后再执行保存操作。权限逻辑别偷懒否则审核时会因为隐私信息收集不合规被拒。4.5 提交审核时容易被拒的几类问题第一次提交小程序审核最容易遇到几个问题。第一类目不符。校园代送如果涉及“快递代取”或“跑腿服务”需要选择对应的生活服务类目否则审核人员可能直接以“未选择正确类目”为由驳回。第二必须有完整的用户协议和隐私政策隐私政策要明确写明你收集了用户的昵称、头像、位置等信息及用途。第三如果只是演示用可以把功能限制在固定的测试校区里避免被认定为信息发布平台而没有相关资质。审核周期通常1到7天不等建议至少留出两周时间来走审核。小程序从开发版到体验版体验再到提交审核是一个完整流程。不要踩着答辩DDL去提交大概率会翻车。最后说点实在的我带人做这个项目最大的体会是毕设的重心不是功能表拉得有多长而是整个业务能不能自洽。发单人、接单人、管理员三者之间的操作边界有没有理清订单状态在每个节点由谁推动、是否可以回溯这两个问题想明白了写代码只是时间问题。如果你正在做这个题目建议先把订单状态机和数据库表设计写出来拿给导师看一眼确认逻辑没问题再动工。这个步骤看上去浪费时间实际上能帮你避免至少三次返工。希望这篇内容对你有用。
