微信小程序积分商城购物跑腿系统实战：统一订单与积分账本设计

1. 拆解标题里的三块业务，先定模型再写代码

刚做完这个项目时，需求单上写的还是“java微信小程序积分商城购物系跑腿配送系统_09ok4”，看起来像三套互不相干的系统硬拼在一起。真把后端代码和数据库落下去之后才发现，这个项目最有价值的地方，恰恰不是功能多，而是要让积分兑换、现金购物、跑腿配送三件事共用同一套用户体系、订单体系和账务体系。一个学生用户可能今天签到拿到积分，明天去积分商城换一杯奶茶，后天又下单让别人帮取快递。整条链路如果每块业务各搞一套登录、各建一套订单表，项目不仅工作量翻倍，后期维护时状态同步、数据统计都会变成灾难。

1.1 三类角色背后是同一个核心

既然项目标题里有“微信小程序”，那面向用户的主入口就是小程序，这是第一端。用户在商城浏览商品，可以选纯积分兑换，也可以选积分加现金混合支付，还可以在跑腿频道发布代取快递、代送文件的任务，之后能在“我的订单”里看到所有订单的进度。第二端是后台管理，它不一定是小程序，通常直接用 Web 管理端来维护商品分类、积分规则、订单发货、配送员审核和基础数据配置。第三端是骑手端，可以复用小程序做一套角色切换，也可以单独做成 H5 或另一个轻量小程序。我在这个项目里把配送员端做成了同一个小程序内的角色入口，用户登录后能看到自己的身份菜单，避免多维护一个安装包。

这三个角色表面分得很开，底层其实共享同一个会员主数据。积分商城里的用户、购物用户、发跑腿订单的用户，在数据库里全是 member 表里的同一条记录，积分账户、收货地址、订单记录都挂在这个主键下面。这样设计之后，运营活动也更好做。比如用户每天签到得积分，积分兑换的商品又需要配送员送到宿舍楼下，整个积分增长、消耗、履约的闭环天然打通。对后端工程师来说，真正要花心思的不是给每个业务单独建一张订单表，而是把统一的账务和状态机设计好。

1.2 一次签到到一次配送的完整链路

我习惯先“倒着”走一遍业务。一个用户打开小程序，第一次进来会触发微信登录，后端通过 wx.login 返回的 code 去换 openid，数据库里没有这条会员就自动注册。之后用户每天签到，积分账户余额增加一笔，同时积分流水表里会多一条 type = 签到奖励 的记录。接着用户去积分商城看到一款商品，标价 1999 积分，积分余额足够，点兑换之后系统扣减可用积分、冻结部分库存并生成一条待支付订单。如果商品库存在线下自提点，但用户希望配送到宿舍，那么这笔兑换单就再派生出一条配送任务，配送员抢到任务后按照订单信息取货、送达，用户确认收货，整单流转结束。

这里有个很容易出错的地方：跑腿配送并不只服务积分商城。用户在购物频道现金买了零食，同样可以选择“需要跑腿配送”；用户也可以纯粹发一条“帮我到东门取个快递”的任务。所以在设计订单模型时，我一开始就把普通购物单、积分兑换单、跑腿任务单这几种类型做了统一抽象，让配送模块是独立的履约层，而不是购物模块的一个附属功能。后面所有接口、列表、统计都因为这一步设计省了很多事，这也是我强烈建议不要按标题字面意思把三个业务拆成三个工程的原因。

1.3 功能矩阵与角色菜单的设计

具体功能划分上，我按角色整理了一份功能矩阵，开发时照着它切菜单和接口：

权限这块不要只在前端做菜单隐藏，后端必须配套做角色拦截。我的做法是用户表里存 role_type 字段，后端所有接口按角色校验，用拦截器统一处理。早期的简陋版本只在页面上判断角色，结果有人直接手动调接口把商品库存改了，这类问题一旦出现，基本都是从权限校验只做前端开始的。这一类问题后面第6章会再重点讲到。

2. 从订单表到积分流水：数据库设计最值得推敲的部分

整个系统在代码上可以后面再慢慢调，但表结构一旦定下来，改动成本非常高。我当时被需求里的三块业务带着走，第一版设计想建三张订单表：商城订单表、兑换订单表、跑腿订单表。后来推演到“我的订单列表”时发现要写三次查询再合并排序，后台统计销售额要对三张表做汇总，配送模块还要维护和业务订单的关联关系，明显不合理。于是推翻重来，把所有订单收拢到一张主表。

2.1 一张交易订单如何同时装下三种业务

先说核心设计思路：订单主表用 order_type 字段区分业务来源，比如 1 表示普通现金购物，2 表示积分商城兑换，3 表示跑腿任务。每个订单有自己的订单号、用户 ID、总金额、总积分、收货信息、支付状态、物流状态等公共字段。业务差异放到扩展表里，比如兑换订单需要冗余展示兑换的商品描述，配送单扩展表会记录配送员、取件码、送达时间这些信息。用这样的方式，一个订单主表可以托管所有业务类型。

可能有人会担心，不同类型订单字段差异太大，硬塞进一张主表会让表变得很宽。我的处理原则是“公共字段上主表，差异字段扩展表”。普通现金订单需要商品快照明细，兑换单需要积分明细，这些可以放到 order_item 表，通过 order_id 关联；跑腿任务需要配送地址、期望送达时间、配送费，这些放到 delivery_task 扩展表。后面查询订单详情时，根据 order_type 决定是否 join 扩展表，逻辑清晰，也不会出现大量为 NULL 的列。

2.2 order_master 核心字段清单

这里给出我实际使用的订单主表简化结构，可以为参考：

订单号一定要带上业务日期和随机因子，比如 20240612 + 用户ID后四位 + 随机数，避免单纯用自增 ID 暴露业务量。用户端“我的订单”列表直接查这张主表，然后用 order_type 渲染不同的卡片样式，前后端联调效率很高。

2.3 积分账本为什么必须单独建流水表

积分和余额一样属于用户资产，不能只在一个字段上加减，必须有流水账。我建了两张表：member_points 记录用户当前积分余额和累计获得积分，point_log 记录每一次积分变动。point_log 的关键字段包括 user_id、change_points、remain_points、type、biz_id。type 用于区分签到、消费奖励、兑换扣减、退款退回等；biz_id 用来关联业务单据，比如签到记录 ID 或订单号。这样一旦用户说“我积分怎么少了”，后端可以直接拉出每一条流水跟他对账。

积分扣减还须考虑冻结机制。用户在积分商城点击兑换时，系统先把积分锁定到冻结额度，订单支付成功才真正扣减；如果用户一直不支付或者主动取消，冻结积分原路退回。这个方案移植了电商的库存冻结逻辑，一开始觉得啰嗦，等实际遇到用户下单后不付款、积分却被扣光的情况才发现冻结机制是必需品。

2.4 状态字典统一在常量类里维护

订单状态、积分流水类型、配送状态这些枚举值，前后端必须用同一套数字编号。我在后端用常量类或枚举类统一定义，同时生成一份接口文档给小程序端，前端代码里也写一份相同的常量映射表。常见的坑是后端改了状态编号但前端没有同步，导致用户看到的订单卡片文案错乱。这里建议测试用例里至少覆盖一遍主流状态流转，后面第5章讲状态机时会细化。

3. 微信小程序端与 Java 后端的登录、请求、权限打通

小程序端的基建工程看起来不难，实际上有几个点很容易被忽略。权限管理和请求封装如果前期不设计好，后面每接一个新页面都要返工。我用的后端框架是 Spring Boot 2.x + MyBatis-Plus，前端就是原生微信小程序加一点点自定义组件。相比引入重型前端框架，原生小程序在打包体积和调试速度上更省心，而且这类商城项目的页面复杂度根本不至于上重框架。

3.1 微信登录 code2Session 换取 openid 的正确姿势

用户打开小程序后，前端调用 wx.login 拿到 code，然后把 code 传给后端接口 /api/auth/login。后端拿着 code 去请求微信官方接口 code2Session，换取 openid 和 session_key。需要注意，code 只能用一次且 5 分钟有效，所以每次登录都要重新调 wx.login，不能在前端缓存 code。openid 是微信用户在小程序内的唯一标识，它应该作为会员表的唯一索引，通过 openid 判断是新用户还是老用户。

下面是简化后的登录代码：

java复制@PostMapping("/api/auth/login")
public Result<String> login(@RequestBody WxLoginDTO dto) {
    String openid = wxService.code2Session(dto.getCode());
    Member member = memberMapper.selectOne(
        new LambdaQueryWrapper<Member>()
            .eq(Member::getOpenid, openid));
    if (member == null) {
        member = Member.builder()
            .openid(openid)
            .nickname("微信用户")
            .roleType(1)
            .build();
        memberMapper.insert(member);
        pointsService.initAccount(member.getId());
    }
    String token = jwtUtil.createToken(member.getId(), member.getRoleType());
    return Result.success(token);
}

这段代码里我最想强调的就是 initAccount。新用户注册时最好同步初始化积分账户，否则会出现用户信息有了、积分账户还没有的脏数据。会员积分账户采用单条记录加流水表的设计，登录成功后 token 串存到小程序 storage，之后每个请求都带上放在 header 的 Authorization 字段。

3.2 小程序端请求封装与状态码设计

小程序把 wx.request 封装成 promise 是很必要的，我一般建一个 request.js，公共逻辑只需写一次：请求前带上 token；返回体中 code 为 0 时 resolve，code 为 401 时清掉本地登录态并跳转登录页；其他情况弹出错误提示。这里每个后端接口都建议用统一响应体 Result，包含 code、message、data 三个字段，避免接口返回结构五花八门。前端拿到任何非 0 的状态码都应该走统一错误处理，不能一个页面一个处理方式。

后端还要做好全局异常兜底，用 @RestControllerAdvice 处理参数校验异常、业务异常和系统异常，保证返回给前端的信息永远是统一结构。生产中见过太多后端返回字符串或者直接抛 Spring 默认错误页，前端解析起来非常痛苦，所以响应体规范应该作为联调前的第一约定。

3.3 角色之间如何通过 token 区分权限

上一节做的 token 里已经包含了会员 ID 和角色类型，后端拦截器拿到 token 后解析出角色。如果是后台商品管理相关接口，要求 role_type 必须是管理员；如果是配送员抢单接口，要求必须是骑手身份。写一个 WebMvcConfigurer 注册拦截器，然后给自己的接口路径加权限注解或者按路径规则匹配即可。

这里要注意，小程序端用户发布跑腿任务和骑手抢单时，登录态可能是同一个会员，只是角色切换。我的处理方式是在登录时直接返回 token，并在 member 表额外存 current_role，切换角色时调一次接口更新后端会话角色。对于这种偏单机的项目，这个方案完全够用，比引入 Spring Security OAuth2 那套重框架性价比高。控制台看到的效果就是同一个微信用户既能作为普通用户下单，也能在“切换为骑手”后进入骑手工作台。

4. 积分商城与购物模块：从商品模型到交易闭环

积分商城和普通购物频道在界面上长得像，核心差别在支付方式。普通商品用人民币支付，积分商品可能要消耗积分，也可能支持“积分 + 人民币”的混合支付。如果只支持纯积分兑换，系统会少很多灵活度。比如一件商品标价 800 积分 + 6 元配送费，这种场景用混合支付才解释得通。

4.1 商品表中的金额与积分如何表达

我在商品表里加了两个价格维度的字段：sale_price 代表现金价，point_price 代表积分价。sku 主表用 goods_type 区分是现金商品还是积分商品，如果是纯积分商品，下单时 sale_price 可以为 0；如果是混合支付商品，下单时会同时算现金和积分。同时还需要一个积分抵扣比例或抵扣上限，比如用户可以拿积分抵一部分钱，剩下的用微信支付。抵扣比例写到系统配置表里，运营想改的时候不需要发版。

商品库存要考虑积分兑换与现金购买的共享库存。比如同一款蓝牙耳机，既能现金购买也能积分兑换，库存只有一个 pool，两种渠道卖的都是同一批货。下单减库存时要把业务渠道也加入防超卖条件，避免现金用户把库存买光后积分用户无法下单，或者反过来积分兑换瞬间把库存冲掉导致现金订单缺货。为了避免这种互相打架的问题，我在商品表里增加了一个 stock_type 字段，0 表示共享库存，1 表示积分专享库存。运营配置商品时心里更清楚。

4.2 防超卖不能只靠查库存再 update

很多初学者写商品下单时会先查询库存，判断数量大于 0，再执行 update 扣减。这个流程在低并发下没问题，一旦有用户同时点兑换，可能两个请求都查到库存还剩 1 件，然后各自生成订单，超卖就发生了。正确的做法是用数据库行锁和乐观锁思路，把判断与扣减放在一条 update 语句里完成：

sql复制UPDATE goods
SET stock = stock - 1
WHERE id = #{goodsId}
  AND stock >= 1;

如果你的商品允许积分用户和现金用户同时抢购，where 条件还可以拼上 stock_type。受影响行数为 1 表示扣减成功，为 0 则说明库存不足或商品已下架，立刻抛出业务异常。把库存校验放到事务里后，再结合 Spring 的 @Transactional，可以确保业务流程中途失败时库存回滚。

4.3 下单事务里先扣积分还是先建订单

积分兑换下单的时序建议是：开启事务 → 锁定商品库存 → 扣减可用积分并写入积分流水 → 创建订单 → 提交事务。有人会问，如果先扣积分后创建订单，第二个步骤失败怎么办？只要整个流程在同一个事务里，任何一个环节抛异常都会整体回滚，积分和库存都会回到原值。这里最需要注意的是扣减积分的 SQL 必须带上可用积分余额条件，保证余额不足时不会扣成负数。

实际开发中我用 MyBatis-Plus 写积分扣减大概长这样：

java复制@Transactional(rollbackFor = Exception.class)
public Order createPointOrder(Long userId, Long goodsId, Integer quantity) {
    // 1. 扣库存
    int stockRows = goodsMapper.deductStock(goodsId, quantity);
    if (stockRows == 0) {
        throw new BizException("库存不足");
    }
    // 2. 查商品积分价格后算总积分
    Goods goods = goodsMapper.selectById(goodsId);
    int totalPoints = goods.getPointPrice() * quantity;
    // 3. 扣积分
    int pointRows = pointsMapper.deductAvailablePoints(userId, totalPoints);
    if (pointRows == 0) {
        throw new BizException("积分余额不足");
    }
    // 4. 写积分流水
    pointsMapper.insertPointLog(userId, -totalPoints, "POINT_EXCHANGE", orderId);
    // 5. 创建订单
    Order order = Order.builder()...
    orderMapper.insert(order);
    return order;
}

事务粒度上要注意 Controller 层的事务不要开得太粗，把调用远程接口、发送短信这类网络操作放在事务外面。比如支付回调处理时，先基于回传结果更新订单状态，再发模板消息，而不是把发消息放进和数据库更新同一个事务。不然消息服务抖动会导致数据库事务长时间不提交，连接池容易被拖垮。

4.4 订单支付完成后的回调处理

小额商城我接的是微信支付 Native 或 JSAPI 支付。用户先调后端下单接口拿到支付参数，再在前端拉起微信支付。支付成功后微信服务器会异步回调指定地址，这个回调地址必须是公网 HTTPS 域名。后端收到回调后要做的事情包括：校验签名、校验订单金额是否一致、更新订单支付状态、把冻结的积分正式扣掉、给用户增加本次消费产生的返积分，最后返回 success 给微信服务器。

支付回调最忌讳的是直接信任回调内容不校验签名，之前看到有人图方便，前端拿到支付成功的返回就直接显示已支付，后端不做任何验证，结果测试时伪造请求就把订单状态改了。签名校验这步无论如何不能省，而且回调处理必须做到幂等——同一笔订单支付结果通知多次也能安全处理。

5. 跑腿配送模块：抢单并发与状态流转里容易出错的地方

跑腿配送是整个系统里更偏实时性的模块。它要处理的不再是简单的下单支付，而是订单从“用户发布”到“骑手接单”再到“完成送达”的状态流转。这里的核心困难是并发和状态一致性。

5.1 配送任务的数据结构：和业务订单是挂靠关系

我设计配送任务时没有单独再做一套完整订单体系，而是把配送任务作为订单主表之后的扩展。用户在下单页面选择“需要跑腿配送”时，后端先生成主订单数据，再往 delivery_task 表插入一条记录。字段包括 task_sn、order_id、user_id、pickup_address、delivery_address、期望送达时间、配送费、取件码、状态。如果是用户主动发的纯跑腿任务，order_type = 3 的订单本身就是一个任务单，那就没有前面的商品订单，直接由 delivery_task 作为主要数据载体。

这样设计的好处是，骑手端看到的是同一张任务列表，不管订单来自积分兑换还是现金购物，配送履约动作是一样的。任务列表查询主表加配送扩展表的信息，UI 上可以清晰显示“配送费 +X 元”“备注：放宿舍楼下”等。

5.2 抢单场景如何保证只有一个人抢到

多骑手同时盯着一个配送任务，谁先点抢单就应该归谁。这个场景和商品库存超卖很像，可以用一条带状态条件的 update 解决：

sql复制UPDATE delivery_task
SET courier_id = #{courierId},
    status = 2,
    accept_time = NOW()
WHERE id = #{taskId}
  AND status = 1
  AND courier_id IS NULL;

执行后返回受影响行数，1 就是抢单成功，0 说明任务已经被别人抢走或状态已经变更。千万不能先 select 查状态为待接单，再执行 update，那会出现多个骑手同时通过查询、同时更新的问题。抢单成功后，后端再查任务详情返回给骑手。为保证实时性，前端抢单大厅页面可以每隔几秒拉一次任务列表，等任务被抢走后列表自动刷新。

5.3 状态机的定义与推动者

配送任务状态我定义为：1 待接单、2 待取货、3 配送中、4 已完成、5 已取消。驱动状态变化的角色要分清楚：用户支付跑腿单后任务进入待接单；骑手抢单成功后进入待取货；骑手点击“已取货”进入配送中；骑手点击“已送达”，如果用户不追究就自动完成。取消操作主要发生在用户付款前或骑手未取货前，管理员也可以介入取消异常单。

为了让用户端能看到实时进度，我在接口层做了一个订单状态查询接口。小程序端使用定时轮询订单详情。早期考虑过 WebSocket 推送，但小程序端的 WebSocket 连接管理比较复杂，而且需要后端维护长连接，对服务器压力、前端切后台重连逻辑都有要求。实际项目我选择了“WebSocket 主动提示 + 轮询兜底”的方案，也就是用户在收到微信订阅消息后进入订单页，此时页面再拉取一次最新状态，实现足够轻量。骑手在关键节点点击操作时，后端调一次微信订阅消息接口，给用户推送一条“你的订单已被骑手接单”之类的消息即可。

5.4 位置查看与配送轨迹

积分商城兑换的商品多数是同城或校园配送，如果要做地图展示，我建议用腾讯位置服务在小程序端做，比较适合微信生态。配送员端开启定位，每隔一段时间上传一次经纬度，订单跟踪页面拉取快递位置。这里如果要求不高，不用做完整的轨迹回放，只要用户能在订单页看到骑手当前经纬度并在地图上展示即可。存储上建一张 courier_location_log 表，保留最近几天的记录即可，不要无限存储，否则单表数据量很快膨胀。

6. 测试与上线阶段的排雷心得

做到这里，系统基本能跑通主线了，但真正上线前还需要处理几个容易踩的坑。这一节列出的都是我在开发过程中踩过或被同事提醒过的经验。因为项目是单体架构，大部分问题集中在状态一致性、接口幂等和数据越权三类问题上。

6.1 微信支付回调必须做幂等处理

支付回调是异步的，同一笔订单微信可能会推送多次。我在回调方法里第一步就是按 out_trade_no 查订单，如果订单 pay_status 已经是已支付，直接返回 SUCCESS 不再往下执行。这样做的好处是即使微信因为网络问题重复回调，也不会给用户重复发放积分。建议不要用“先更新订单状态再写日志”的无序写法，一旦重复回调，积分流水可能记两遍。把支付状态更新和积分发放放到同一个事务方法里，同时用数据库唯一索引约束订单号，可以从底层挡住重复数据。

6.2 超时未支付订单的定时兜底

用户在积分商城下单冻结了库存和积分，却一直不支付，如果系统不处理，占用资源会越积越多。我用 Spring @Scheduled 写了一个定时任务，每分钟扫描超过 30 分钟仍未支付的订单，把订单状态改为已关闭，归还冻结积分、回补库存。当然这类定时任务要幂等：扫描条件要限定 pay_status = 0 且 create_time 小于当前时间减 30 分钟，关闭后再补偿而不是每扫到一次就回补一次。部署时还要注意多实例下定时任务重复执行的问题，简单项目可以加一个分布式锁或直接单实例部署。

6.3 数据越权问题靠网关和鉴权拦住

前端的“我的订单”列表只显示当前用户的订单，但后端查询接口如果只接收 orderId 而不校验这个订单是否属于当前用户，就会产生越权漏洞。一个用户只要遍历订单号就能看到别人的收货地址。所有订单详情接口都应从 token 里解析出 userId，再拼上 userId 作为查询条件，不能只依赖前端传来的参数。同理，骑手端取消任务也只能操作 courier_id 是自己的任务。

6.4 预留的优化空间

如果后续业务量大了，可以在现有架构上做两块优化：一是把热点商品库存和积分账户做 Redis 预扣减，再用消息队列异步同步数据库，应付秒杀场景；二是把后台管理从单体服务中拆出来，避免运营的批量操作拖慢用户主流程。不过对一个课程设计/毕设级别的项目而言，单体架构加上合理表结构已经足够，最重要的还是先把业务流程和数据一致性跑稳。

我是从“拿到题目后急着写代码”的泥潭里走出来的，第一版数据库设计浪费了将近一周。后来我把系统的核心改成“统一的用户、统一的订单、独立的配送履约层”之后，积分商城、购物系统和跑腿配送才真正成为一个可以完整闭环的产品，而不是三个 demo 的拼接。如果再重做一遍，我会把积分流水与订单状态机这层提前画出来，让前端并行开发时也不会返工太多。希望这篇文章能帮你少走一点我先走过的弯路。