在毕业设计选题里基于微信小程序的校园跑腿系统是出现频率很高的一类项目。它把用户下单、跑腿员接单、订单追踪、消息通知和结算流程串在一起涉及小程序前端、后端接口、数据库设计和部署联调已经超过单个页面 Demo 的范畴。更重要的是这个题目既有清晰的业务主线又有足够的技术深度适合从零开始完整实现也适合在毕业设计论文和答辩中讲出层次感。这篇文章会围绕一套可运行的校园跑腿系统按照业务拆解、环境准备、登录链路、订单模块、小程序端开发、后端联调、真机验证、排错清单和论文材料整理的顺序展开。文中给出的表结构、接口设计、代码片段和排查思路都可以直接作为课程设计或毕业设计项目的基础。碰到具体报错时建议先对照“错误现象、常见原因、检查方式、处理建议”四步走不要看到网络错误或登录失败就直接改代码。1. 校园跑腿系统的核心拆解先想清楚业务再写代码1.1 这个项目到底在做什么校园跑腿系统面向的是校园内部的生活服务场景。使用者主要分成两类一类是需要有人帮自己取快递、带饭、送文件的学生另一类是愿意接单赚取报酬的跑腿员。系统要解决的核心问题是让这两类人能够快速匹配并且订单全程可追踪、可确认、可评价。从功能上看至少需要包含用户登录、发布订单、订单列表、抢单接单、订单详情、取消订单、确认完成、消息通知和个人中心。从数据上看核心实体是用户、订单、订单状态记录。从流程上看一笔订单从发布开始到被接单再到完成或取消状态不能跳变必须按规则流转。先梳理清楚业务再开始搭项目。很多毕业设计代码写不下去不是因为技术难而是因为业务边界没定清楚。比如“取消订单”在接单前和接单后的规则不一样“评价功能”是否必须存在这些都要在需求阶段明确。1.2 角色、权限与登录模型系统在权限上要区分普通用户和跑腿员但底层的用户账号体系是同一个。用户通过微信登录后后端拿到 openid再根据 user_type 字段判断角色。普通用户发布订单后可以查看自己发布的订单列表跑腿员可以浏览待接单池并承接订单两者都能查看与自己有关的订单详情。权限校验不能只依赖小程序端隐藏按钮。后端接口必须判断当前登录用户是否有权操作某个订单。例如 A 用户发布的订单B 用户不能直接标记完成跑腿员接单时订单必须处于待接单状态且接单人不等于发布人。在实际毕业论文里这段要写成“基于角色的访问控制”相关章节重点不是实现多复杂的权限框架而是说明用户角色划分、接口鉴权逻辑和越权防护思路。1.3 用状态机管理订单流转订单状态是整个系统的核心。建议在一开始就定义好有限状态集合而不是在代码里散落魔法数字。常见状态定义如下状态值含义触发条件后续允许状态0待接单发布成功1 已接单、4 已取消1已接单跑腿员接单成功2 配送中、4 已取消2配送中跑腿员开始配送3 已完成3已完成用户确认或跑腿员提交完成无4已取消发布人取消或接单后协商取消无状态机的好处是让订单流转可预期。代码里应该在每次状态变更时做前置校验并且把状态变更记录到订单日志表方便论文里展示追溯能力也方便后续排查问题。2. 环境准备与项目骨架毕业设计项目最容易忽略的是基础环境2.1 开发环境与工具清单校园跑腿系统至少需要三个部分微信小程序前端、后端服务、数据库。下面是常见开发环境落地前需要对照自己电脑上的实际版本确认组件建议工具说明代码编辑器Visual Studio Code / WebStorm小程序端和后端代码都可以使用微信开发者工具微信开发者工具稳定版用于小程序预览、调试、上传微信小程序账号注册小程序账号并获得 AppID测试阶段可使用测试号但真机完整验证建议使用正式 AppID后端框架Spring Boot / Node.js Express毕业设计常见选型为 Spring Boot 系列数据库MySQL 8.x存储用户、订单、日志等数据接口调试微信开发者工具 Network 面板 / Apifox观察请求和响应版本管理Git Gitee 或 GitHub 私有仓库提交日志也是论文支撑材料如果原始项目使用的是其他技术栈例如 uni-app 配合 HBuilderX目录结构会不同但业务模块、表设计和接口思路仍然可以复用。2.2 微信小程序端初始化在微信开发者工具里创建项目时选择“小程序”填入 AppID前端目录建议按业务功能组织miniprogram/ ├── app.js ├── app.json ├── app.wxss ├── utils/ │ ├── request.js │ └── util.js ├── pages/ │ ├── index/ │ ├── publish/ │ ├── order-list/ │ ├── order-detail/ │ └── profile/ └── components/ ├── order-card/ └── empty-tip/app.json 中需要注册页面、配置窗口样式和 tabBar。示例配置如下{ pages: [ pages/index/index, pages/publish/publish, pages/order-list/order-list, pages/order-detail/order-detail, pages/profile/profile ], window: { navigationBarTitleText: 校园跑腿, navigationBarBackgroundColor: #4F8FFF, navigationBarTextStyle: white }, tabBar: { list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/order-list/order-list, text: 订单 }, { pagePath: pages/profile/profile, text: 我的 } ] }, style: v2, sitemapLocation: sitemap.json }注意 tabBar 的 list 至少 2 项最多 5 项。如果页面使用了自定义导航栏还需要在对应页面的 json 中设置navigationStyle: custom这时 tabBar 仍然可以在 app.json 中配置但每个页面的顶部样式需要自行适配。2.3 后端项目结构后端使用 Spring Boot 时建议按模块拆分包结构避免把所有代码堆在一个 Controller 里。示例结构如下src/main/java/com/example/campuserrand/ ├── CampusErrandApplication.java ├── config/ │ ├── WebConfig.java │ └── WxConfig.java ├── controller/ │ ├── AuthController.java │ ├── OrderController.java │ └── UserController.java ├── service/ │ ├── AuthService.java │ ├── OrderService.java │ └── SubscribeMessageService.java ├── mapper/ │ ├── UserMapper.java │ ├── OrderMapper.java │ └── OrderLogMapper.java ├── entity/ │ ├── User.java │ ├── Order.java │ └── OrderLog.java ├── common/ │ ├── Result.java │ └── BizException.java └── utils/ └── JwtUtils.java启动类、配置类、控制器、服务、Mapper、实体、工具类分开后论文中的“系统设计”部分可以直接按这个结构描述。2.4 技术选型对比原生小程序与 uni-app做校园跑腿系统时可以选择原生微信小程序也可以选择 uni-app 这类跨端框架。两者没有绝对好坏取决于项目的交付目标和后续扩展需求。对比维度原生微信小程序uni-app开发工具微信开发者工具HBuilderX 或命令行跨端能力只支持微信小程序可编译到微信小程序、H5、App 等平台组件与 API直接使用微信原生 API使用 uni 封装的 API底层仍调用微信能力调试体验与微信基础库同步快需要关注编译后平台差异代码迁移换平台要重写页面换平台成本相对低如果毕业设计只要求“微信小程序 后端”原生小程序结构更直观论文里也更容易解释。如果课程设计要求做多端或其他平台演示才建议考虑 uni-app。3. 用户登录链路从 wx.login 到后端会话建立3.1 小程序侧登录流程微信小程序登录和传统账号密码登录不一样。小程序端通过wx.login获取临时凭证 code然后把 code 发送到后端后端再调用微信接口code2Session换取 openid 和 session_key。openid 是用户在当前小程序下的唯一标识session_key 用于解密用户信息或生成其他敏感数据不能直接返回给前端。小程序端简易登录逻辑// pages/profile/profile.js const request require(../../utils/request); Page({ data: { userInfo: null }, onLoad() { this.checkLogin(); }, checkLogin() { const token wx.getStorageSync(token); if (token) { this.getUserInfo(); } else { this.login(); } }, login() { wx.login({ success: (res) { if (res.code) { request.post(/api/auth/login, { code: res.code }).then((data) { wx.setStorageSync(token, data.token); wx.setStorageSync(userId, data.userId); this.getUserInfo(); }); } else { wx.showToast({ title: 登录失败, icon: none }); } } }); }, getUserInfo() { request.get(/api/user/info).then((data) { this.setData({ userInfo: data }); }); } });这里要注意wx.login获取到的 code 是一次性的有效期很短只能使用一次。不要在前端缓存 code也不要把它打印到日志里。3.2 后端 code2Session 换取 openid后端收到 code 后调用微信接口。微信接口地址中需要携带小程序的 AppID 和 AppSecret以及前端传过来的 codeGET https://api.weixin.qq.com/sns/jscode2session ?appidAPPID secretSECRET js_codeCODE grant_typeauthorization_codeSpring Boot 中可以用 RestTemplate 或 Hutool 的 HttpUtil 发起请求。示例实现不考虑第三方工具使用 JDK 自带的 HttpURLConnection 也能完成public String code2Session(String code) { String url https://api.weixin.qq.com/sns/jscode2session?appid wxConfig.getAppId() secret wxConfig.getAppSecret() js_code code grant_typeauthorization_code; String body restTemplate.getForObject(url, String.class); JSONObject json JSONObject.parseObject(body); if (json.getIntValue(errcode) ! 0) { throw new BizException(微信登录失败 json.getString(errmsg)); } return json.getString(openid); }需要注意的是AppSecret 只能保存在后端不能放在小程序代码里。小程序端一旦携带 AppSecret任何人通过反编译或抓取前端包都有可能泄露密钥。3.3 用户表与会话表设计用户表需要满足基本信息和角色区分。示例 DDLCREATE TABLE t_user ( id bigint NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL, nickname varchar(64) DEFAULT , avatar_url varchar(255) DEFAULT , user_type tinyint NOT NULL DEFAULT 0 COMMENT 0 普通用户1 跑腿员, phone varchar(20) DEFAULT , create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;登录成功后后端不要直接把 openid 返回给前端。更稳妥的做法是生成一个自定义登录态 token例如使用 JWT 或随机字符串并把它作为后续接口的身份凭证。JWT 的优点是服务端不需要保存会话记录适合毕业设计演示缺点是刷新和吊销需要额外处理。如果希望控制更严格可以把 token 存到 Redis 并设置过期时间。3.4 登录报错中 wx 开头 AppID 的排查思路有些同学在登录报错里看到类似wx1cb4398e1413dce7这样的字符串第一反应是 AppID 写错了。这个字符串确实很像小程序的 AppID但它出现在错误信息中时更多只是微信把当前小程序的标识带出来。真正的原因要看errMsg或errCode前面的描述而不是看到 wx 开头就修改 AppID。错误现象常见原因检查重点处理建议调用接口提示 appid 不存在AppID 填写错误或使用了其他平台产物检查 app.json 中的 AppID 与微信公众平台一致在开发者工具右上角详情中查看 AppID获取用户信息失败用户拒绝授权或基础库版本过低查看 errMsg 是否包含 auth deny使用按钮触发授权不要一进页面就弹窗code2Session 返回 invalid codecode 被重复使用或过期确认每次登录都重新执行 wx.login前端只传最新 code后端不缓存 code后端请求微信接口超时服务器网络不通或微信接口 access_token 限制观察后端日志和时间段排查服务器外网访问能力并做超时重试这里要记住一个原则凡是登录类错误先看是前端报错还是后端报错。前端报错优先看errMsg后端报错优先看服务端请求微信接口的返回体不要凭经验直接改代码。4. 跑腿订单模块核心业务表与状态机编码4.1 订单表设计要点订单是系统的核心表字段设计必须考虑展示、搜索和状态流转。示例表结构如下CREATE TABLE t_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL, publisher_id bigint NOT NULL COMMENT 发布人用户ID, taker_id bigint DEFAULT NULL COMMENT 接单人用户ID, title varchar(100) NOT NULL COMMENT 订单标题, description varchar(500) DEFAULT COMMENT 详细描述, pickup_address varchar(255) NOT NULL COMMENT 取件地址, deliver_address varchar(255) NOT NULL COMMENT 送达地址, reward decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 跑腿费, status tinyint NOT NULL DEFAULT 0 COMMENT 0待接单 1已接单 2配送中 3已完成 4已取消, contact_name varchar(32) DEFAULT , contact_phone varchar(20) DEFAULT , create_time datetime DEFAULT CURRENT_TIMESTAMP, accept_time datetime DEFAULT NULL, finish_time datetime DEFAULT NULL, cancel_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_publisher_id (publisher_id), KEY idx_taker_id (taker_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT跑腿订单表;奖励金额字段建议使用decimal不要使用浮点类型避免金额计算出现精度问题。订单号建议在生成时加入时间戳和随机数不要直接使用自增主键暴露订单规律。4.2 发布订单接口实现发布订单的核心流程是校验参数、生成订单号、设置初始状态为待接单。Controller 层负责接收请求Service 层负责业务逻辑。PostMapping(/api/order) public ResultLong publish(RequestBody PublishOrderRequest request) { Long userId currentUserId(); Long orderId orderService.publish(userId, request); return Result.success(orderId); }Service 中需要完成参数校验和初始状态写入public Long publish(Long userId, PublishOrderRequest request) { if (request.getReward() null || request.getReward().doubleValue() 0) { throw new BizException(跑腿费必须大于0); } if (StringUtils.isBlank(request.getPickupAddress()) || StringUtils.isBlank(request.getDeliverAddress())) { throw new BizException(取件地址和送达地址不能为空); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setPublisherId(userId); order.setTitle(request.getTitle()); order.setDescription(request.getDescription()); order.setPickupAddress(request.getPickupAddress()); order.setDeliverAddress(request.getDeliverAddress()); order.setReward(request.getReward()); order.setStatus(0); orderMapper.insert(order); orderLogMapper.insert(OrderLog.create(order.getId(), 0, 发布订单)); return order.getId(); }这里的currentUserId()要从登录态中获取不能信任前端传过来的 userId。这是常规项目的底线否则任何人都能冒充他人身份发布或操作订单。4.3 接单并发控制接单功能是订单模块最容易出问题的点。多个跑腿员同时抢同一笔订单时如果没有并发控制可能出现重复接单导致订单被多个跑腿员写入。推荐做法是在数据库层面加状态条件更新把“先查后改”改成“原子更新”UPDATE t_order SET taker_id #{takerId}, status 1, accept_time now() WHERE id #{orderId} AND status 0 AND publisher_id ! #{takerId}在 MyBatis 中执行后根据影响行数判断是否抢单成功。影响行数为 1说明当前用户成功接单影响行数为 0说明订单已被别人接走或状态不允许接单。public boolean acceptOrder(Long orderId, Long takerId) { int rows orderMapper.accept(orderId, takerId); if (rows 0) { throw new BizException(手慢了订单已被接走); } orderLogMapper.insert(OrderLog.create(orderId, 1, 跑腿员接单)); return true; }使用这种方式就不需要引入分布式锁适合课程设计和毕业设计项目承载量。生产环境承载高并发时还要考虑 Redis 预扣库存、接口幂等和消息队列等措施。4.4 订单状态流转的兜底校验后端在每次状态变更时都要校验当前状态是否合法。不要只在前端用按钮控制比如用户点击“确认完成”就把状态改成 3这样会出现很多脏数据。public void finishOrder(Long orderId, Long operatorId) { Order order orderMapper.selectById(orderId); if (order null) { throw new BizException(订单不存在); } if (order.getStatus() ! 2) { throw new BizException(订单状态不允许完成); } if (!order.getPublisherId().equals(operatorId) !order.getTakerId().equals(operatorId)) { throw new BizException(无权操作此订单); } int rows orderMapper.updateStatus(orderId, 3); if (rows 0) { throw new BizException(订单状态更新失败请刷新后重试); } orderLogMapper.insert(OrderLog.create(orderId, 3, 订单完成)); }状态机里的每一个分支都对应一个接口每个接口都要重复做“订单是否存在、权限是否匹配、状态是否允许”三个检查。虽然代码多了些但这就是毕业设计论文里能够写清楚的部分。5. 小程序前端页面与常见适配问题5.1 页面结构与发布订单表单小程序端建议把订单列表、订单详情、发布表单分开。发布表单常见字段包括标题、描述、取件地址、送达地址、跑腿费、联系人、联系电话。表单页面中地址和时间通常使用 picker跑腿费输入框需要限制为数字。发布订单核心代码示意// pages/publish/publish.js const request require(../../utils/request); Page({ data: { title: , description: , reward: , pickupAddress: , deliverAddress: }, onInput(e) { const field e.currentTarget.dataset.field; this.setData({ [field]: e.detail.value }); }, submitOrder() { const { title, pickupAddress, deliverAddress, reward } this.data; if (!title || !pickupAddress || !deliverAddress || !reward) { wx.showToast({ title: 请填写完整信息, icon: none }); return; } request.post(/api/order, this.data).then((orderId) { wx.showToast({ title: 发布成功, icon: success }); setTimeout(() { wx.redirectTo({ url: /pages/order-detail/order-detail?id${orderId} }); }, 1000); }); } });这里有一个常见坑在小程序表单中用户输入内容后必须通过>function getNavBarInfo() { const windowInfo wx.getWindowInfo(); const menuButton wx.getMenuButtonBoundingClientRect(); const statusBarHeight windowInfo.statusBarHeight; const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height; return { statusBarHeight, navBarHeight, menuButtonRight: menuButton.right, menuButtonTop: menuButton.top }; }自定义导航栏的常见问题包括不同机型高度不一致使用固定数值会导致顶部遮挡或空白过大。胶囊按钮在不同机型的位置变化点击区域不要被自定义按钮覆盖。如果页面同时配置了 tabBar自定义导航栏只影响页面顶部不影响底部 tabBar。使用默认导航栏时不需要计算这些数值。只有需要在导航栏右侧放按钮、做下拉背景或沉浸式效果时才值得引入自定义导航栏。毕业设计项目中如果只是展示页面默认导航栏更稳定。5.3 图片上传、列表刷新与分页发布订单通常需要上传物品照片。小程序图片选择使用wx.chooseMedia上传使用wx.uploadFile。wx.chooseMedia({ count: 3, mediaType: [image], sourceType: [album, camera], success(res) { const files res.tempFiles; const tasks files.map((file) uploadImage(file.tempFilePath)); Promise.all(tasks).then((urls) { this.setData({ imageUrls: urls }); }); } }); function uploadImage(filePath) { return new Promise((resolve, reject) { wx.uploadFile({ url: https://your.domain.com/api/common/upload, filePath, name: file, success(res) { const data JSON.parse(res.data); resolve(data.url); }, fail: reject }); }); }列表页需要处理分页和下拉刷新。小程序提供onPullDownRefresh和onReachBottom两个生命周期。首次进入加载第一页下拉刷新重置页码触底后加载下一页。分页参数建议统一使用page和pageSize返回结构里带上总条数或是否有更多。Page({ data: { orders: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onPullDownRefresh() { this.setData({ page: 1, orders: [], hasMore: true }); this.loadOrders().finally(() wx.stopPullDownRefresh()); }, onReachBottom() { if (this.data.hasMore !this.data.loading) { this.loadOrders(); } }, loadOrders() { const { page, pageSize } this.data; return request.get(/api/order/list, { page, pageSize }).then((res) { const list res.list; this.setData({ orders: this.data.orders.concat(list), page: page 1, hasMore: res.hasMore }); }); } });注意onPullDownRefresh需要在当前页面的 json 文件中开启enablePullDownRefresh: true。很多同学配置了生命周期但页面没有下拉效果原因就是没有开启这个配置。5.4 订阅消息与更新检查跑腿订单的状态变化需要通知用户比如跑腿员接单、订单完成。小程序提供订阅消息能力需要先取得用户授权再由后端调用微信接口发送。小程序端申请订阅消息wx.requestSubscribeMessage({ tmplIds: [模板ID1, 模板ID2], success(res) { console.log(用户授权结果, res); } });需要注意wx.requestSubscribeMessage的模版 ID 需要在微信公众平台的“订阅消息”页面创建。一次性订阅消息每次授权只能发送一条不能像短信模板那样反复发送。如果业务逻辑需要在多个时机推送就要申请多个模板或者在关键动作前申请授权。小程序版本更新检查使用wx.getUpdateManagerconst updateManager wx.getUpdateManager(); updateManager.onUpdateReady(function () { wx.showModal({ title: 更新提示, content: 新版本已经准备好是否重启应用, success(res) { if (res.confirm) { updateManager.applyUpdate(); } } }); });这段代码通常放在app.js的onLaunch中。它能帮助用户及时用上最新代码避免反复反馈“我已经改了但客户端看不到”。6. 后端接口联调与安全处理6.1 统一响应体与异常处理接口返回结构最好统一方便前端统一处理。常规响应结构可以设计为{ code: 0, message: success, data: {} }code 为 0 表示成功非 0 表示业务失败。前端 request.js 拦截响应如果 code 不为 0 就弹出错误提示并 reject。前端 request 统一封装示例function request(method, url, data) { return new Promise((resolve, reject) { wx.request({ url: baseUrl url, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail(err) { reject(err); } }); }); }后端同时要处理程序异常。Spring Boot 中可以使用RestControllerAdvice捕获异常并统一返回而不是让前端收到一堆不可读的堆栈信息。6.2 登录态校验的设计登录态校验一般放在拦截器或过滤器里。用户可以放行登录、注册相关接口其他接口都需要校验 token。简单实现思路public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BizException(未登录); } Long userId jwtUtils.parseToken(token); request.setAttribute(currentUserId, userId); return true; }Controller 里通过request.getAttribute(currentUserId)获取当前用户。这样就不需要在每个接口里重复解析 token。需要注意 token 的过期时间不要设置得太长。毕业设计中可以设置 7 天方便演示生产环境通常要根据业务安全要求设置更短的过期时间并引入刷新机制。6.3 私密数据与接口越权订单详情接口很容易出现越权问题。用户 A 创建订单后用户 B 可能通过修改 URL 中的订单 ID 查看或操作订单。后端必须校验当前用户与订单的归属关系。例如查看订单详情的规则可以是public Order getOrderDetail(Long orderId, Long userId) { Order order orderMapper.selectById(orderId); if (order null) { throw new BizException(订单不存在); } boolean publisher order.getPublisherId().equals(userId); boolean taker order.getTakerId() ! null order.getTakerId().equals(userId); boolean normal order.getStatus() 0; if (!publisher !taker !normal) { throw new BizException(无权查看该订单); } return order; }待接单状态下的订单可以公开浏览方便跑腿员抢单但一旦被接单只有发布人和接单人能查看联系方式和操作订单。这种规则要在论文里写清楚。6.4 支付流程在毕业设计里的落地方式校园跑腿系统的付款方式有两种常见设计线上支付和线下支付。线上支付涉及微信支付商户号、统一下单、支付回调、退款等复杂流程。如果只是课程设计或毕业设计没有真实商户号时可以先把支付状态设计成“待支付”、“已支付”、“已退款”的字段并在前端设计“货到付款”或模拟支付按钮。如果确实要接入微信支付需要走这几个步骤小程序端调用wx.requestPayment前先向后端发起下单请求。后端调用微信支付统一下单接口得到paySign等参数。小程序端接收参数后调用wx.requestPayment。微信支付成功后微信服务器回调后端接口后端需要验签并更新订单状态。回调接口要返回成功给微信否则微信会重复通知。支付回调中必须处理幂等不能因为回调重发就重复修改订单状态。毕业设计论文中如果写了支付模块要把支付回调的验签、幂等和异常处理写进去。7. 从开发者工具到真机的联调验证7.1 本地联调与合法域名配置开发阶段小程序可以直接在开发者工具中运行并且可以勾选“不校验合法域名”来访问本地接口。但真机预览时微信小程序要求所有请求必须使用 HTTPS并且域名需要在微信公众平台配置到合法域名列表。本地联调常用方式是在后端机器上运行项目并在开发者工具中填写http://localhost:8080或局域网 IP同时开启不校验合法域名。这里要注意真机没有这个开关真机上访问 localhost 会指向手机自身而不是开发电脑。推荐在联调阶段就把接口地址抽成常量或配置文件区分开发环境和生产环境const config { development: { baseUrl: http://192.168.1.100:8080 }, production: { baseUrl: https://your.domain.com } };切换环境时只需修改一处配置不要在每个页面里硬编码请求地址。7.2 真机调试常见错误ERR_CONNECTION_RESET真机调试中经常出现failed net::ERR_CONNECTION_RESET。这个错误代表小程序与服务器之间的网络连接被重置常见原因如下现象常见原因检查方式处理建议真机请求失败模拟器正常真机使用 4G/5G 网络无法访问内网查看报错是否为连接超时或重置将后端部署到公网服务器或让手机与电脑连同一局域网并配置可信域名HTTPS 方式访问失败证书无效或证书链不完整在手机浏览器访问接口地址观察证书提示配置有效证书或使用支持 HTTPS 的云服务器请求被重置后端防火墙或安全组未放行端口查看后端进程、服务器安全组放行 443 或对应端口并确认监听地址为 0.0.0.0域名未配置小程序请求使用了非白名单域名开发者工具“详情”中查看域名校验信息在微信公众平台配置 request 合法域名毕业设计阶段如果后端部署在云服务器要特别注意服务器安全组是否放行了对应端口。很多问题不是代码写错而是端口没有暴露出去。7.3 模拟器与真机的差异清单模拟器只能作为开发辅助不能替代真机验证。模拟器和真机的常见差异包括差异点模拟器表现真机表现原因与处理网络请求可以访问 localhost通常无法访问 localhost真机没有“不校验合法域名”开关摄像头和定位可能使用模拟数据使用真实设备能力需要真机测试权限流程基础库版本跟随开发者工具基础库用户手机基础库可能较旧使用兼容处理或更新基础库版本字体和导航栏高度固定机型效果型号不同效果不同使用官方 API 计算不要写死高度图片选择相册可选范围不同与系统相册能力一致图片上传逻辑必须真机验证演示前一定要用真机走一遍“登录 - 发布订单 - 接单 - 完成”的完整流程避免答辩时在细节处翻车。8. 常见的报错排查清单8.1 登录与用户信息类登录链路中常见的报错集中在wx.login、code2Session和用户信息授权。排查顺序应该是先看前端是否有 code再看后端是否成功请求微信接口最后看用户表是否写入成功。错误现象常见原因检查方式处理建议小程序端errMsg提示 login fail网络异常或基础库异常查看wx.login的 fail 回调信息重试wx.login后端请求 code2Session 返回 errcodeAppSecret 错误或 code 失效查看后端日志中的返回 JSON确认 AppSecret 正确前端重新执行 login多次登录后用户重复创建没有按 openid 去重查看用户表是否存在重复 openid给 openid 建立唯一索引自定义登录态丢失token 过期或清除缓存查看 token 过期时间在 session 过期后引导用户重新登录8.2 请求与网络类网络类报错大多和域名、证书、端口有关。不要一遇到ERR_CONNECTION_RESET就回滚代码先确认网络链路是否通。错误现象常见原因检查方式处理建议request 请求返回 403域名未配置或请求头缺失查看后端日志和微信公众平台域名配置配置合法域名并检查 token连接超时后端服务未启动或安全组未放行使用浏览器或 curl 访问接口确认后端进程、端口、安全组真机 ERR_CONNECTION_RESETHTTPS 证书或端口问题在真机浏览器访问接口 URL检查证书、域名解析、服务器防火墙小程序白屏页面 JS 报错打开调试器查看 console查看报错堆栈并修复8.3 订单与数据类订单模块报错常常来自状态机不合法、金额精度、越权访问。排查时先看订单当前状态再看接口入参。错误现象常见原因检查方式处理建议接单失败但订单没有变化并发抢单时状态被其他用户更新查看订单状态和 taker_id使用状态条件更新并返回提示金额显示错误使用 float 或 double 存储金额查看数据库字段类型使用 decimal 或 BigDecimal取消按钮点击无反应前端按钮状态与后端状态不一致对比订单状态定义拉取最新详情后再操作订单详情无法打开参数 id 缺失或非法查看页面 URL 和日志使用数字参数并做空值判断8.4 发布与部署类发布和部署阶段的问题更多来自环境差异。代码在本地运行正常一旦部署到线上就出现 404、白屏、请求失败通常要检查路径、域名和配置文件。错误现象常见原因检查方式处理建议接口 404部署路径与接口前缀不一致查看访问 URL 和项目 context-path调整部署配置或统一接口前缀前端打开白屏JS 文件路径错误或域名不可访问使用开发者工具 review 页面检查静态资源 URL图片上传失败上传目录不可写或路径不存在查看后端日志创建上传目录并配置访问映射数据库连接失败数据库地址、账号、密码不匹配查看配置文件使用环境变量管理配置9. 课程设计与毕业设计的材料整理9.1 课程设计交付物课程设计交付时除了可运行项目还需要准备一套完整的说明材料。常见交付物包括源代码压缩包包含小程序端、后端、SQL 脚本和 README。项目运行说明文档写明开发环境、启动步骤和测试账号。数据库初始化脚本让评阅老师能够快速还原表结构和初始数据。关键功能演示录屏方便课程设计验收时快速展示。设计报告包含系统结构图、数据库设计、核心流程说明。源码压缩包要注意不要包含node_modules、target、__pycache__等依赖或编译产物否则包会非常大而且评阅老师也无法直接从代码中看到你的工程层级。9.2 毕业论文结构与写作顺序毕业设计论文可以按以下结构组织章节主要内容写作重点绪论项目背景、研究意义、国内外现状说明校园跑腿的应用需求相关技术微信小程序、后端框架、数据库每一项技术要说明为什么选型需求分析功能需求、非功能需求、用例图明确角色和订单流程系统设计总体架构、数据库设计、接口设计重点画订单状态图和 E-R 图系统实现登录、订单、消息通知等功能模块每个模块给出关键代码和截图系统测试功能测试、接口测试、真机测试用表格列出测试用例总结与展望项目收获、不足、改进方向不要只写“提高了能力”要写具体技术结论写作顺序建议先写需求分析和系统设计再根据设计补代码细节。很多同学先把代码写完再写论文容易出现代码和论文不一致的问题。9.3 答辩演示要点答辩时不要照着论文念要用演示过程引出核心设计点。建议准备一条演示主线展示登录过程说明 openid 如何获取token 如何换发。发布一笔订单说明订单状态为待接单。切换跑腿员账号展示接单过程强调并发控制。展示用户收到订阅消息说明消息模板和发送时机。展示订单完成和评价说明状态机闭环。最后展示数据库表说明订单表和日志表的关系。答辩中的提问通常围绕业务规则展开比如“同一用户能不能接自己的单”、“订单取消后库存如何处理”、“token 过期后前端如何跳转”。提前把这些边界情况写清楚答辩会从容很多。9.4 项目源码管理与说明文档源码提交到 Git 仓库之前先写好.gitignore避免把本地配置和编译产物提交进去。后端示例target/ *.class *.jar .idea/ *.iml application-local.yml数据库初始化脚本建议放到项目根目录的sql/文件夹下并命名为init.sql。README 中要写明后端启动步骤包括 JDK 版本、MySQL 配置、启动命令。小程序运行步骤包括 AppID 替换、接口地址修改。测试账号说明例如普通用户和跑腿员账号如何注册或初始化。关键接口列表方便评阅老师快速定位功能。毕业设计项目最大的陷阱不是技术复杂度不够而是交付材料不完整、运行步骤缺失、代码与文档不一致。把这些基础工作做扎实项目质量会明显提升。最后给一个核心建议校园跑腿系统可以无限扩展但毕业设计的重点是形成一套完整闭环最好把登录、订单、消息、权限这些关键路径全部跑通而不是堆十个残缺页面。把状态机、并发控制和异常处理讲清楚比把界面做得花哨更有价值。