企业官网建设流程全解析

简介：面向毕业设计与课程设计的基于微信小程序的校园跑腿生活服务平台项目，围绕用户微信一键登录、个人资料管理、服务分类展示、在线下单与实时报价、订单跟踪、跑腿员申请与订单管理等业务模块，完整呈现了从需求分析到编码实现的闭环思路，可作为计算机专业学生完成同类校园生活服务系统时的功能范本与流程参考。资源包共2000个文件，前端以JavaScript、HTML、CSS为主，包含大量jQuery Mobile页面与样式文件，后端由46个Java源文件、SQL数据库脚本及JSON/XML等配置组成，覆盖前后端数据交互、数据库建表与系统配置，整体压缩包约17.93MB，目录结构清晰，便于按功能检索。随包附带的markdown说明、图片与GIF素材，有助于理解微信小程序调用接口、订单状态流转及跑腿员管理的关键细节。已有62人学习下载，面向需要完成Java Web或小程序课程设计、毕业设计的学生，可直接对照源码和文档进行二次开发与论文撰写。

1. 微信小程序校园跑腿平台在解决什么问题

校园里的"最后一公里"配送需求，比外卖平台覆盖的还要琐碎：代取快递、代买零食、打印店带资料、下雨天帮带饭。这些订单单价低、距离短、即时性强，用传统外卖平台的派单模型做不划算，但用一个基于 LBS 的抢单/发单小程序就能跑通。这篇内容不会替你写论文，而是把这个毕业设计题目拆成一个前后端分离的订单交易系统：小程序端负责发单、抢单、支付，服务端负责订单状态机、用户身份和支付回调。你跟着把架构、表结构、接口和支付链路理清，就能得到一个能演示、能写进论文、也能应对答辩追问的完整方案。

2. 校园跑腿平台的技术选型与微信小程序端架构设计

2.1 原生微信小程序与 uni-app 的取舍

校园跑腿这个场景，客户端承担的核心交互是发布订单、浏览订单流、抢单、查看我的订单、支付、确认收货。页面层级浅，没有复杂动画，也没有跨端硬需求，原生微信小程序完全能覆盖。但如果你之前的主力技术栈是 Vue，用 uni-app 开发再用 HBuilderX 打包成微信小程序，学习和调试成本反而低很多。判断标准很简单：项目里有没有"未来必须上 App 或支付宝小程序"的规划。如果只是交付一个可运行、可演示的微信小程序，原生框架少一层编译转换，定位问题更直接。

选型之外还有第二层：请求封装与状态管理。原生小程序里，wx.request的并发控制、token 注入、错误码统一处理，最好抽成一个request.js工具模块，而不是在每个页面里散落调用。uni-app则用uni.request配合拦截器实现。无论走哪条路，请求层必须先把 baseURL 和 token 过期刷新逻辑处理好，否则后续调试支付回调时会被 401 反复打断。

2.2 服务端技术栈与数据表设计

服务端我建议用Spring Boot 2.x + MyBatis-Plus + MySQL 8.0。理由很直接：学生毕业设计答辩时，这套组合参考资料最多，面试时也容易被认可。更关键的是微信支付 v3 的 Java SDK（wechatpay-java）对 Spring Boot 适配成熟，对接官方接口时可以直接用 SDK 处理签名和证书轮换，省掉手写 RSA 签名的低级错误。

数据库层面，核心表不建议只设计一张订单表，否则订单状态和支付状态耦合在一起，后续退款对账会被动。我一般拆成以下几张表：

pay_order单独拆出来是关键决定。微信支付回调、主动查单、退款回调都要更新支付状态，如果直接写在orders表里，订单读操作会被频繁的支付状态更新拖累。独立表之后，订单表只需要冗余一个pay_status字段供列表查询，真正的支付快照以pay_order为准。

2.3 微信登录态与用户身份打通

小程序的登录流程网上资料很多，但容易忽略一个点：wx.login拿到的code只能用一次，有效期只有 5 分钟。标准做法是前端在app.js的onLaunch里调wx.login，把code传给后端，后端再拿code去微信的auth.code2Session接口换取openid和session_key，最后签发自己的 token。

// miniprogram/utils/request.js const BASE_URL = 'https://your-api.example.com' function login() { return new Promise((resolve, reject) => { wx.login({ success: async (res) => { if (!res.code) return reject(new Error('登录失败')) try { const { token } = await post('/api/auth/login', { code: res.code }) wx.setStorageSync('token', token) resolve(token) } catch (e) { reject(e) } }, fail: reject }) }) } function post(path, data) { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method: 'POST', data, header: { Authorization: `Bearer ${wx.getStorageSync('token')}` }, success: (res) => { if (res.data.code === 0) resolve(res.data.data) else reject(new Error(res.data.message)) }, fail: reject }) }) }

login函数先请求一次性code，再用它换取业务 token 存入本地缓存；post把 token 统一放到请求头。后端拿到code后调用微信接口，openid是用户在微信生态的唯一 ID，不能暴露给前端，否则任何客户端都能冒充身份。服务端返回的应该是自签 token，并缓存openid与 token 的映射关系。

3. 订单模块的状态机设计与服务端接口实现

3.1 订单状态机定义与核心字段

跑腿订单不是简单的"待接单→完成"，支付、取消、退款都会插入中间态。状态机设计得不够细，后期加退款功能时就要回头改表结构。推荐的状态流转如下：

这里有一个常见分歧：是否允许"未支付先发布"。我建议支持"发布后先支付再进入待接单池"，因为跑腿订单金额小、信任成本高，先付款能过滤掉大量无效发布。所以订单主表里status和pay_status要分开：支付状态用UNPAID/PAID/REFUNDING/REFUNDED单独描述，两个字段共同决定订单是否进入接单列表。

-- 订单主表核心结构 CREATE TABLE `orders` ( `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号，对用户可见', `publisher_id` BIGINT NOT NULL COMMENT '发单人用户ID', `taker_id` BIGINT DEFAULT NULL COMMENT '接单人用户ID', `pickup_info` VARCHAR(255) NOT NULL COMMENT '取件信息，如快递柜号/商家位置', `delivery_info` VARCHAR(255) NOT NULL COMMENT '送到哪栋楼哪个宿舍', `tip_amount` INT NOT NULL DEFAULT 0 COMMENT '跑腿费佣金，单位分', `status` VARCHAR(20) NOT NULL DEFAULT 'PENDING', `pay_status` VARCHAR(20) NOT NULL DEFAULT 'UNPAID', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY `idx_status` (`status`), KEY `idx_publisher` (`publisher_id`), KEY `idx_taker` (`taker_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

金额字段一律用"分"存整数，避免浮点误差。order_no建议用"日期+随机数"生成，用户端显示位数不超过 20 位，微信支付的回调查询也依赖它。列表查询要走idx_status索引，订单池刷新时才不会因为大量已完结订单拖慢响应。

3.2 发布订单与抢单接口实现

发布订单接口前端传入商品描述、取件信息、送达地址、跑腿费，后端先生成order_no，落库后生成一条pay_order记录并返回支付参数。如果是"先支付后发布"，那订单初始状态仍是PENDING但带UNPAID标记，不进入公共接单列表。

@PostMapping("/api/order/create") public Result<OrderCreateVO> create(@RequestBody OrderCreateDTO dto) { String orderNo = OrderNoGenerator.generate(); Order order = new Order(); order.setOrderNo(orderNo); order.setPublisherId(UserContext.getUserId()); order.setPickupInfo(dto.getPickupInfo()); order.setDeliveryInfo(dto.getDeliveryInfo()); order.setTipAmount(dto.getTipAmount()); order.setStatus("PENDING"); order.setPayStatus("UNPAID"); orderMapper.insert(order); PayOrder payOrder = new PayOrder(); payOrder.setPayNo("PAY" + orderNo); payOrder.setOrderNo(orderNo); payOrder.setOpenid(UserContext.getOpenid()); payOrder.setAmount(order.getTipAmount()); payOrder.setPayStatus("UNPAID"); payOrderMapper.insert(payOrder); return Result.ok(new OrderCreateVO(orderNo, payOrder.getPayNo())); }

PayOrder和Order在一次事务里创建，避免支付回调到了却找不到订单记录。抢单接口的核心是防止两个人同时抢到同一单，需要借助数据库行锁或者乐观锁：

@PostMapping("/api/order/accept") @Transactional public Result accept(@RequestBody AcceptDTO dto) { // 悲观锁：SELECT ... FOR UPDATE 锁住这行订单 Order order = orderMapper.selectForUpdate(dto.getOrderId()); if (order == null || !"PENDING".equals(order.getStatus())) { return Result.error("订单不可接"); } order.setTakerId(UserContext.getUserId()); order.setStatus("ACCEPTED"); orderMapper.updateById(order); return Result.ok(); }

selectForUpdate在事务内把订单行锁住，第二个请求会等待第一个事务提交，然后发现状态已变而失败。这里不能用先查后更新的普通写法，否则并发下会出现超卖。抢单成功后要异步通知发单人：调微信订阅消息接口，要求发单人在发布页授权过一次消息订阅模板。

3.3 状态变更后的消息触达与超时处理

状态机流转除了改数据库，还要做两件事：写order_status_log审计表、触发消息通知。审计表的作用是在答辩时展示"订单全生命周期可追溯"，也是排查问题的重要手段。

@Component public class OrderEventPublisher { public void publish(Order order, String fromStatus, String toStatus) { OrderStatusLog log = new OrderStatusLog(); log.setOrderId(order.getId()); log.setFromStatus(fromStatus); log.setToStatus(toStatus); log.setOperatorId(UserContext.getUserId()); statusLogMapper.insert(log); // 通知发单人/接单人，用微信订阅消息 wxNotifyService.sendSubscribeMessage(order, toStatus); } }

超时未接单的订单需要定时任务兜底。用@Scheduled每 5 分钟扫描一次超过 30 分钟仍处于PENDING且PAID的订单，将其置为CANCELLED并触发原路退款。这个规则不是固定的，校园跑腿高峰期用户能接受更长的等待，建议做成系统参数，演示时可以直接调短成 2 分钟，展示"超时自动取消并退款"的完整链路。

4. 微信支付 v3 对接与支付流程实现

4.1 微信支付 v3 的证书体系与前置条件

对接微信支付 v3 前，需要在商户平台完成三项准备：申请 API 证书并下载apiclient_key.pem和apiclient_cert.pem；设置 APIv3 密钥（32 位随机字符串）；下载微信支付平台证书。很多同学卡在"证书验签失败"上，本质是混淆了"商户证书"和"平台证书"的用途：

v3 接口的请求签名算法是 RSA-SHA256。请求体先按固定格式拼出待签名串，再用商户私钥签名，Authorization 头里带上mchid、nonce_str、signature、timestamp等信息。如果不想手写，直接用wechatpay-javaSDK 的RSAAutoCertificateConfig能自动完成平台证书下载和轮换。

4.2 统一下单签名与小程序端调起支付

服务端拿到前端传来的orderNo和openid后，调用/v3/pay/transactions/jsapi下单，返回prepay_id。然后后端用prepay_id生成小程序端所需参数并签名返回给前端。关键代码如下：

@Test public void testJsapiPay() { // 初始化配置 RSAAutoCertificateConfig config = new RSAAutoCertificateConfig.Builder() .merchantId("商户号") .privateKeyFromPath("/path/apiclient_key.pem") .merchantSerialNumber("商户证书序列号") .apiV3Key("APIv3密钥") .build(); // 构建请求 String requestBody = JsonUtils.toString(Map.of( "appid", "小程序appid", "mchid", "商户号", "description", "校园跑腿订单", "out_trade_no", orderNo, "notify_url", "https://your-api.example.com/api/pay/notify", "amount", Map.of("total", amountInFen, "currency", "CNY"), "payer", Map.of("openid", openid) )); // 通过SDK发送请求 HttpService httpService = new JdkHttpServiceBuilder().build(); // 响应中的prepay_id用于后续二次签名 String prepayId = jsapiService.payTransaction(...); }

SDK 自动完成了 v3 的请求签名、平台证书下载和时间戳防重放。拿到prepay_id后，后端还需用商户私钥对appId + timeStamp + nonceStr + package + signType做二次签名，把package=prepay_id=xxx传给小程序。小程序端拉起收银台：

// 支付按钮点击 const payRes = await post('/api/pay/jsapi', { orderNo }) wx.requestPayment({ timeStamp: payRes.timeStamp, nonceStr: payRes.nonceStr, package: payRes.package, signType: 'RSA', paySign: payRes.paySign, success: (res) => { // 支付成功，但最终状态以后端回调为准 }, fail: (err) => { if (err.errMsg.includes('cancel')) { // 用户取消支付 } } })

paySign的签名算法必须与signType一致。这里最容易踩的坑是用 v2 的 MD5 签名逻辑去调 v3 接口，导致支付失败，当前商家暂不支持这类报错。回调通知地址notify_url必须是 HTTPS，且域名要与小程序后台配置的 request 合法性域名一致。

4.3 回调验签与订单状态同步

微信支付结果回调是异步通知，需要先验签确认消息来自微信，再更新订单状态。验签分两步：用微信平台证书验证 HTTP 头部的Wechatpay-Signature，再解密resource字段拿到明文支付结果。明文里的out_trade_no是订单号，transaction_id是微信侧交易号。

@PostMapping("/api/pay/notify") public String payNotify(@RequestBody String body, @RequestHeader("Wechatpay-Timestamp") String timestamp, @RequestHeader("Wechatpay-Nonce") String nonce, @RequestHeader("Wechatpay-Signature") String signature, @RequestHeader("Wechatpay-Serial") String serial) { // 1. 用平台证书验签（SDK已封装） // 2. 解密得到支付结果明文 PayResult payResult = decrypt(body); String orderNo = payResult.getOutTradeNo(); // 3. 幂等更新：pay_order 和 orders 都改为已支付 payOrderMapper.updatePaid(orderNo, payResult.getTransactionId()); orderMapper.updatePayStatus(orderNo, "PAID"); orderEventPublisher.publishPaid(orderNo); // 4. 返回成功应答，避免微信重复通知 return "{\"code\":\"SUCCESS\"}"; }

注意回调处理必须做幂等设计，微信对同一笔通知可能发送多次，后端要有"已处理过的transaction_id直接返回成功"的判断逻辑。推荐在pay_order表上加transaction_id唯一索引，重复通知触发 DuplicateKeyException 时 catch 住并返回成功。这个细节答辩时提出来会加分，因为它说明你理解分布式系统的重复消息问题。

5. 调试排错与验收演示的高频技巧

5.1 用抓包工具定位小程序前端请求异常

微信开发者工具的 Network 面板能看常规请求，但在真机上要定位问题，还是得用代理抓包。常见做法是让手机和电脑连同一局域网，电脑上开 Charles 的 SSL Proxying，手机 Wi-Fi 代理指向电脑 IP:8888，安装并信任 Charles 根证书后，就能看到小程序发往服务端的 HTTPS 请求明文。建议在request.js里按环境注入不同的 baseURL，方便切换"开发者工具模拟请求"和"真机抓包请求"，省去反复改配置的麻烦。

抓包时如果发现请求头里的Authorization总是旧 token，先看wx.setStorageSync是否在登录前被其他页面覆盖。另一种情况是使用wx.request默认超时时间太短导致支付回调前连接被掐断，我一般会显式设置timeout: 15000并给对话框加上loading状态，避免用户连续点击重复下单。

5.2 微信支付 v3 的典型报错排查

支付对接阶段要提前准备一张报错速查表，方便演示时从容应对：

一键反编译调试时，即使报了"支付失败"，也要先看微信开发者工具 Console 面板中的 errMsg 和 errCode，很多问题并非代码 bug，而是商户号没开通 JSAPI 支付权限，或者小程序 appId 与商户号没有绑定关联。

5.3 答辩演示环境要准备的验证清单

毕业设计演示最容易翻车的点是把整套环境都跑在本地 IDE 里。我建议演示前准备一个精简的自检流程：先确认服务端进程正常、Redis 连接可用、小程序端用的是演示环境 baseURL；再清理测试订单数据，避免演示时订单池里全是脏数据。如果条件允许，准备一台内网穿透或公网服务器部署后端，因为真机上的微信支付回调要求公网 HTTPS 可达，localHost 只会反复出现回调地址无法访问。

验收演示时先走"发布订单 → 微信支付 → 自动派单 → 接单 → 完成"这条主线，确认每个状态变更都有日志输出；再演示异常链路：发单后不支付直接退出，定时任务会自动取消订单；支付成功后故意让回调超时，用主动查单接口兜底修复状态。把这些链路讲清楚，比一味展示界面有价值得多。

本文还有配套的精品资源，点击获取