SpringBoot+微信小程序的智能包裹配送系统设计与实现

快递驿站门口堆了一地的包裹，取件码发出去没人拿，快递员电话打到爆也送不完；另一边用户天天催“我的件什么时候到”，问客服也问不出个所以然。这是我在做校园快递配送系统调研时最常见的场景，也是这个 springboot 基于微信小程序的智能包裹配送服务管理系统 想解决的问题——把包裹从“到了自己找”变成“配送全流程可追踪、可调度、可评价”。

这个项目同时踩了 Java 后端和小程序前端两条线。后端以 SpringBoot 为核心搭 REST API，前端跑在微信小程序里，中间通过微信生态的登录、订阅消息、支付能力打通用户和配送员。整套系统做下来，很适合两类人看：一类是正在做毕设，想找一个功能闭环完整、技术栈常规但又不缺亮点的选题；另一类是校园、园区、小型社区里真的想做包裹代收代发和跑腿配送的开发者，想把业务流程先理顺再动手开发。

下面我按自己实际从零开发这个系统的顺序，把业务拆分、技术选型、后端设计、小程序端实现、最容易翻车的配置点，以及怎么把这个项目做得比普通管理 demo 更“能打”，一条一条讲清楚。

1. 一个包裹配送系统，业务边界先要画清楚

很多人在动手写代码前就急着建表，结果做着做着发现角色对不上、状态流转乱掉。我建议先花半天把业务角色和流程画出闭环，尤其是配送类系统，它的核心复杂度不在 CRUD，而在“一单多状态、多人协作”。

1.1 谁在用这个系统：三类角色一条主线

智能包裹配送服务管理系统涉及的核心用户其实可以分成三类：寄收包裹的用户、配送包裹的配送员、管理全局的管理员。简单说就是“用户下单要配送——配送员接单去送——管理员看全局数据、处理异常”。

用户端是小程序，主要做的事大概是：收到包裹到达通知、填写收货地址或选择代收点、发起配送请求、查看配送轨迹、确认收货、对服务打分。这个流程看着简单，但它决定了小程序页面要至少拆出首页、订单列表、订单详情、个人中心这几个主模块，外加一个消息中心用来看推送。

配送员端可以复用小程序，只是不同角色进来看到不同 tab。配送员核心动作是：接单、取件、开始配送、送达拍照、订单结算。如果你的场景里有“多个配送员抢单”，那还要引入抢单或派单逻辑，这就比普通增删改查有意思多了。

管理员端我会直接做成 Web 管理页面，用 SpringBoot 提供接口，前端用 Vue 或者直接 Thymeleaf 都行。管理员关心的是：用户管理、配送员审核与调度、订单查询、异常处理、以及最基础的包裹入库统计。很多时候管理员还要承担“包裹入库”的录入动作，这个可以做成扫码录入，也可以做成手动录入，取决于你有没有打印包裹条码的条件。

1.2 核心业务闭环：包裹从入库到签收的八步走

我把整个流程压缩成了八个状态，这是整个系统最值得先设计清楚的部分：入库、待配送、配送中、待签收、已签收、异常、退单、已完成。

• 当快递到达站点，管理员或系统导入包裹信息，此时状态为“待配送”。
• 用户看到包裹到达后，可以发起“配送到门”或“配送到代收点”的订单。此时产生一条配送订单，等待配送员接单。
• 配送员接单后去取件，包裹状态变为“配送中”。
• 送达位置后，配送员通过小程序拍照或让用户输入取件码，状态进入“待签收”。
• 用户确认收货，订单完成；如果配送过程中有问题，比如用户不在、包裹破损，则进入“异常”状态走人工处理。

需要注意的是“包裹状态”和“配送订单状态”是两套东西。包裹入库后有包裹主状态，配送订单有自己的子状态。我第一次做的时候把两个揉在一张表里，结果退货、转寄、重新配送这些场景一出现就乱了。

1.3 系统边界：第一版别贪大

如果你是自己做毕设或者做社区小规模落地，第一版我建议不要把支付、积分、多个驿站、自动分单这些都塞进去，否则两个月都上不了线。第一版要做到的是“包裹有迹可循，订单状态可流转，角色权限清晰”——先把这个闭环走通，再看情况加功能。这也是为什么这个项目选 SpringBoot + 微信小程序而不是更重的中台方案的原因。

2. 技术选型的真实理由：从 SpringBoot 自动装配到小程序端原生还是 uniapp

技术选型这部分如果只是写“SpringBoot 好、微信小程序用户多”就太空了。我要把做选择时实际考虑的几个关键点讲透，因为选型直接决定后面开发的顺利程度。

2.1 为什么后端用 SpringBoot，而不是 SSM 或 Python

如果你经历了 SSM 时代，一定忘不了那一堆 XML 配置。SpringBoot 最大的价值是把“自动装配”这件事做到了极致。你在 pom 里引入 spring-boot-starter-web，它通过 spring.factories（新版本是 AutoConfiguration.imports）和大量 @ConditionalOnClass、@ConditionalOnMissingBean 注解，自动把内嵌 Tomcat、DispatcherServlet、Jackson 转换器装配好。换句话说，你只要写业务代码，不用再操心容器怎么启动。

对智能包裹配送这样的系统来说，SpringBoot 生态里现成的轮子也足够丰富。比如要用 JWT 做登录态，引入 jjwt；要做参数校验，直接用 spring-boot-starter-validation；要操作 MySQL，用 MyBatis-Plus 可以省掉大量单表 CRUD 的重复劳动。接口开发速度比 SSM 时代快一倍是保守说法。

2.2 版本选择的教训：SpringBoot 版本太高同样会出问题

这里必须提一个热搜词里很多人都在踩的坑——“springboot版本太高”。我一开始图省事直接在 Spring Initializr 里选了 3.x 最新版，结果遇到的第一个问题就是 javax 包名改成了 jakarta。如果是新项目其实还好，但很多教程、网上的老代码还是基于 javax，你复制过来直接编译报错。另外 SpringBoot 3.x 对 JDK 版本要求是 17+，如果你本机是 JDK 8，那就更是一连串的坑。

所以我的最终选择是 SpringBoot 2.7.x 搭配 JDK 1.8，这几乎是目前中文社区教程覆盖度最高、坑最少的一套组合。如果你的目标环境是 Docker 部署，想用 jdk1.8 镜像打包成 docker desktop 镜像，这个版本也省心。下表是我项目里用的关键版本，可以直接抄：

2.3 小程序端：原生、uni-app 还是 HBuilderX + uni-app

这是前端路线里最纠结的问题之一。很多人第一次接触小程序项目会听到“HBuilderX 开发微信小程序”的说法，其实 HBuilderX 是 DCloud 出的编辑器，它主要用来跑 uni-app。uni-app 的好处是一套代码能编译到微信、支付宝、H5 等多个端，而且它的语法接近 Vue，如果后端是 SpringBoot 但你之前写过 Vue 后台，上手会很快。但坑也有：uni-app 的编译链路长一层，遇到小程序原生 bug 时你不太容易定位是 uni-app 的问题还是微信基础库的问题。

我这次没有用 uni-app，而直接用“微信开发者工具 + 原生小程序语法”。原因很简单：我这个项目不打算跨端，原生小程序虽然啰嗦，但调试时定位问题最快，比如自定义 tabbar、订阅消息这些原生能力，官方文档写的是什么，你在代码里就能直接对应上。如果你要做多个端，可以考虑 university-app，但要注意 HBuilderX 运行到微信开发者工具时提示“不是开发者”之类的问题，通常需要在微信公众平台里把小程序的开发者工具设置为已绑定项目，并且在微信开发者工具的安全设置里开启服务端口。

2.4 数据表怎么划分：一张包裹表撑不起状态流转

我最终设计的核心表大概分成这几类：用户表（含角色字段或独立角色表）、配送员信息表、包裹表、配送订单表、地址表、消息通知表、操作日志表。

• 包裹主表：对应快递公司、运单号、包裹状态、入库时间。
• 配送订单表：关联用户 ID、配送员 ID、包裹 ID，记录订单状态、下单时间、接单时间、送达时间、签收时间、评价内容。
• 地址表：通常一个用户会有宿舍地址、家里地址多个，要支持设置默认地址。

有一次我图省事不想建地址表，把地址直接写成字符串存在订单表里，结果用户改了一次地址之后，历史订单里的地址也全变了。后来才明白配送类系统的订单地址必须做“快照”，也就是下单那一刻的地址要原样保存，不能动态关联用户当前地址。

3. 后端核心设计：登录态、订单状态机与消息推送

这个项目后端真正有含金量的地方，不是简单的 Controller 加 Service，而是下面这几块：小程序的登录态怎么和 SpringBoot 对接、配送订单的状态怎么控制得不容易出错、以及包裹状态变化了怎么主动触达用户。这三块如果做好了，系统才有“智能”的样子。

3.1 小程序登录与 JWT：code2session 换 openid，后端发 token

微信小程序不像传统网页那样用账号密码登录，而是通过 wx.login() 拿到一个临时 code，把 code 传到后端，后端再拿 code 去微信的接口换 openid 和 session_key。这个 openid 是用户在微信生态里的唯一标识，正常情况一个用户对应一个 openid，应该用它来关联自己数据库里的 user_id。

SpringBoot 后端的处理流程是这样的：

java复制@PostMapping("/login")
public Result login(@RequestBody LoginRequest req) {
    // 1. 拿 code 调微信接口，获取 openid
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" 
        + appid + "&secret=" + secret + "&js_code=" + req.getCode() 
        + "&grant_type=authorization_code";
    String result = restTemplate.getForObject(url, String.class);
    JSONObject obj = JSON.parseObject(result);
    String openid = obj.getString("openid");

    // 2. 查本地用户表，如果不存在就自动注册
    User user = userService.findByOpenid(openid);
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setNickname("微信用户" + openid.substring(openid.length() - 6));
        userService.save(user);
    }

    // 3. 生成 JWT 返回给小程序
    String token = JwtUtil.createToken(user.getId(), user.getRole());
    return Result.success(token);
}

生成 JWT 后，小程序端把 token 存到 storage 里，之后每个请求都在 header 里带一个 Authorization: Bearer xxx。后端需要一个拦截器或者 Spring MVC 的 HandlerInterceptor 统一解析 token，把当前用户信息放到 ThreadLocal 里，Controller 里通过 UserContext.getUserId() 就能拿到当前用户。我第一次写时漏了 ThreadLocal 的清理，导致高并发下用户 A 的请求读到了用户 B 的用户 ID，排查了很久才发现是线程复用导致数据串了。用完之后一定要在 afterCompletion 里 remove。

3.2 订单状态机的设计逻辑：用枚举把状态变化管死

配送订单是整个系统的核心。如果我们放任代码里到处都是 if (status == 0) status = 1; 这种写法，等状态一多就必然出乱子。我推荐把所有状态变化收敛到一个枚举 + 一个状态流转管理器里。

订单状态枚举大概是这样的：

java复制public enum OrderStatus {
    WAIT_ACCEPT(0, "待接单"),
    ACCEPTED(1, "已接单"),
    DELIVERING(2, "配送中"),
    WAIT_SIGN(3, "待签收"),
    SIGNED(4, "已签收"),
    EXCEPTION(5, "异常"),
    CANCELED(6, "已取消");

    private final int code;
    private final String desc;
}

关键点是维护一张“允许流转表”：哪些状态可以变成哪些状态。比如待接单可以变成已接单，也可以变成已取消；但已签收绝不能再变成待接单，已取消也不能被配送员接单。我在代码里用了一个 Map<OrderStatus, Set<OrderStatus>> 来维护合法流转路径，更新状态前先检查一次：

java复制public void changeStatus(OrderStatus target, Order order) {
    Set<OrderStatus> allowed = TRANSITIONS.get(order.getStatus());
    if (allowed == null || !allowed.contains(target)) {
        throw new BizException("非法的订单状态流转: " + order.getStatus() + " -> " + target);
    }
    order.setStatus(target);
}

很多人觉得这是多此一举，但实际项目里如果没有这层约束，后面每次增加新功能，总会有人随手改个状态，测试也很难发现。有了这层就只能走你规定的转发规则。同时操作日志表，每次状态变化都记录下操作人、操作时间、旧状态、新状态，这样无论是排查问题还是答辩时展示，都很有说服力。

3.3 订阅消息推送：就算用户没打开小程序，也知道包裹到哪了

包裹配送系统里比较加分的功能就是消息通知。传统做法是用短信，但短信要钱；小程序里有订阅消息，不需要额外费用。流程是：用户在小程序里主动授权订阅一次“配送状态通知”，之后你的后端就可以在相应时机给用户推送一次微信服务通知。

有个很容易踩的坑：微信小程序的订阅消息分为“一次性订阅”和“长期订阅”。默认大部分账号只能用一次性订阅，用户点一次“允许”只能让你推一条。如果你要做整个订单从接单到签收的多次通知，就要在每个环节分别让用户授权，或者做成引导用户每次点击时订阅下一次通知。这在产品设计上要提前想好，不然到后面发现消息只能推一次，就可能考虑用多次订阅或者在上一次通知中带上“继续订阅”的引导。

后端推送其实很简单，就是组装一个消息体调微信的 subscribeMessage.send 接口，模板 ID、接收用户的 openid、跳转的小程序页面路径都不能错。最好把模板内容抽象成一个配置类，不要每个地方拼 JSON。

3.4 权限控制：管理员接口不能裸奔

系统里用户的身份可能是普通用户，也可能同时是配送员，管理员则是一小撮。我在实际项目里用的是在 JWT 里附加 role 字段，然后在拦截器或 AOP 里做角色判断。

更细的权限控制建议用 Spring Security 或者 Sa-Token，但如果不想引入太重的安全框架，配合 Spring Boot 的 HandlerInterceptor 自己写一套也够用。核心是一个注解加一个拦截器，例如 @RequireRole("admin")，在拦截器里判断当前用户角色不匹配就直接返回 403 JSON。这比在每个 Controller 里写 if 判断要优雅得多。还有一个很多人踩的坑——接口放行。小程序端有大量接口是不需要登录就能访问的，比如登录接口本身；但管理后台的接口必须全部走鉴权。不要嫌麻烦把批量放行做成 /api/** 全部放开，等于把系统脱光放公网上。

4. 小程序前端：自定义 tabbar、取件码与配送页面逻辑

小程序前端表面看着不难，但做起来才知道细节点非常多。从底部 tab 到地图选点，从取件码展示到消息订阅，每个功能都暗藏平台限制。

4.1 自定义 tabbar 为什么那么多人问

“微信小程序自定义tabbar”是热搜词里的高频问题。默认的 tabbar 只能改文字和图标，样式很原生；如果你想做成中间凸起、带红点角标、角色不同看到不同 tab 的效果，就必须用自定义 tabbar。

自定义 tabbar 的原理是：在 app.json 里配置 "custom": true，然后在代码根目录建 custom-tab-bar 目录，里面放四个文件：index.js/json/wxml/wxss。官方要求 tab 页面数量在 2~5 个，每个 tab 页面里的 this.getTabBar() 可以拿到这个自定义组件实例，然后在页面 onShow 里调用 this.getTabBar().setData({ selected: index }) 来切换选中态。

最容易踩的坑有两个：

• 自定义 tabbar 组件里如果用 wx.switchTab 跳转，页面路径必须在 app.json 的 tabBar.list 里配置过。
• 不同角色看到不同 tab 时，逻辑不能写死在每个页面的 onShow，建议在 tab 组件初始化时统一拉取用户角色，然后动态显示或隐藏 tab 项。

4.2 取件码与签名：不是简单随机数

如果是包裹到站自提模式，取件码是给用户到驿站取件的凭证；如果是配送到门模式，取件码更多是作为“签收凭证”。我见过很多人直接把取件码设置成 4 位随机数，结果碰撞概率很高，而且没有时效性。

我的做法是用 Hutool 生成一个 6 位数字，把取件码和订单 ID 绑定，存在 Redis 里设置 24 小时过期。用户点击“确认收货”时需要输入取件码，配送员端展示取件码，两边匹配才能完成签收。如果取件码过期或错误次数超过 5 次，自动转入异常状态，管理员可以人工重置。这里也可以引入更复杂的“配送员拍照证明”——也就是送达时让配送员拍一张照片，上传到后端并和订单关联，方便后续纠纷取证。照片上传使用 SpringBoot 的文件上传接口，需要注意为上传文件配置资源映射目录，不能把文件直接存到数据库；图片访问路径做成 /upload/2025/xx.jpg 这样的静态映射。

4.3 配送范围与地址定位：地图组件选型

小程序里做地址选择，最自然的就是用腾讯位置服务的小程序 SDK。用户在页面里搜索地址或拖动地图选点，拿到经纬度和地址描述，展示给用户确认。后端可以根据站点经纬度和用户的经纬度算距离是否超出可配送范围。

算距离不需要引入地图 SDK 后端版，直接用高德或腾讯的距离计算接口，也可以自己在 Java 里用 Haversine 公式算。公式不复杂，但要注意：如果在数据库层面做范围筛选，要提前把经纬度都存在独立的字段里，方便 SQL 做矩形范围预筛，再精确算距离。

我在做配送范围时还设计了一个开关：超出范围时不允许下单，但提示用户“可改选代收点自提”，这样既控制了配送成本，又把用户损失降到最低。

4.4 HBuilderX 运行调试小程序时常见的联调问题

前面提过，如果走 uni-app 路线就是 HBuilderX + 微信开发者工具。如果你用原生开发，用微信开发者工具直接打开项目就行。联调时最常见的几个问题包括：

• 提示“not a developer”：说明当前微信扫码登录的账号不是这个小程序项目的开发者，需要项目管理员在微信公众平台成员管理里加你。
• 提示“域名不合法”：小程序正式环境要求后端接口必须为 HTTPS 且在公众平台配置合法域名；开发调试阶段可以在开发者工具里勾选“不校验合法域名”。
• 小程序里请求 localhost 不通：模拟器里 localhost 通常指向开发机，但你用真机预览时就指向手机自己了。真机调试时后端地址要改成电脑的局域网 IP，同时后端服务要监听 0.0.0.0 而不能只听 127.0.0.1。另外还要注意小程序对非 HTTPS 请求限制比较严格，本地联调大多要依赖“不校验合法域名”这个开关，演示给老师或客户看的时候要先确认网络环境。

5. 最容易翻车的配置与线上部署排查清单

写代码的阶段很多问题还能忍，真正让人头皮发麻的是环境配置和部署阶段。这里把我实际排查过的问题和最终确认能用的方案列一遍，很多都是热搜词里大家反复搜的。

5.1 SpringBoot 上传下载大文件与资源映射

包裹系统里涉及配送员拍照上传、管理员批量导入包裹，所以文件上传是躲不掉的。SpringBoot 默认最大上传文件大小是 1MB，很容易就超出。需要在配置文件里调大参数：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 50MB

同时要配置静态资源映射，让上传的图片能通过 URL 直接访问。

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        String uploadPath = System.getProperty("user.dir") + "/upload/";
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath);
    }
}

注意这样配置后 JWT 拦截器要放行 /upload/**，否则图片 <img> 加载会因为没带 token 而 401。如果你用 docker 部署，别忘把 upload 目录挂载成宿主机数据卷，不然容器一重建图片全没了。

5.2 JWT 拦截器与 Swagger 放行的正确姿势

接口文档工具我用了 Knife4j（Swagger 的增强版），它生成的页面可以当成给前端同学的接口文档，也可以用来演示接口。但加了 JWT 拦截器后，Swagger 的资源路径如果没放行，文档页面会打不开，所有接口也会 401。

放行规则不要图省事全放行，比较稳妥的做法是放行这些固定路径即可：

java复制registry.addInterceptor(jwtInterceptor)
        .addPathPatterns("/**")
        .excludePathPatterns(
            "/login",
            "/register",
            "/doc.html",
            "/webjars/**",
            "/swagger-resources/**",
            "/v3/api-docs/**",
            "/v2/api-docs/**",
            "/upload/**"
        );

5.3 微信支付 v3 对接的合规提醒

如果这个系统要接“用户下单后在线支付配送费”，比较常规的是接入微信支付 v3。搜索榜里有“小程序微信支付v3对接 由于小程序违规，支付功能暂时无法使用”这类问题，一定要特别提醒：个人主体的小程序很多支付类目无法开通，如果小程序因为类目选择或运营规范问题被限制支付功能，一定要先到微信公众平台查看具体处罚原因，按平台要求整改或申诉，千万别走任何非官方渠道，并且要在开发阶段就把支付开关做成可配置。没有商户号之前，可以先实现模拟支付流程，但代码里要封装 PayService 接口，默认用 MockPayServiceImpl，等商户号下来了再切换到 WechatPayV3ServiceImpl，不要等后期再重构。

5.4 从开发机到 Docker 部署的常见坑

最终交付时为了方便演示，可以把后端打成 Docker 镜像。SpringBoot 2.7 配 JDK 1.8 时，很多人会在 docker desktop 上遇到镜像拉不下来、容器内存不够、MySQL 连不上这类问题。

我的 Dockerfile 比较简单：

dockerfile复制FROM openjdk:8-jdk-alpine
MAINTAINER yourname
COPY target/parcel-delivery.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

注意数据库地址不要写死 localhost，在容器里应该用宿主机 IP 或启动时通过环境变量传入，例如 docker run -e DB_HOST=192.168.1.100 -p 8080:8080 parcel-app。配置文件里用 ${DB_HOST:localhost} 这样的占位符，没有环境变量时还能用默认值。如果你要用 docker-compose 同时启动 MySQL 和 SpringBoot，要让 SpringBoot 容器依赖 MySQL 健康检查通过后再启动，不然很可能 SpringBoot 启动时连不上数据库然后瞬间退出。

5.5 遇到流程类需求，要不要上 Flowable

那如果业务里加了一个“异常订单需要逐级审核”的功能，用 if/else 写状态流转虽然也能实现，但审核层级一多，代码就会变得很乱。这种场景适合引入工作流引擎，比如把 Flowable 和 SpringBoot 整合起来。Flowable 的 BPMN 文件里定义好审核节点和条件分支，业务代码只负责触发流程实例，流程自动往下走。不过第一版建议不要引入，否则光是学习 BPMN 的网关、事件、会签概念就够你喝一壶。我的建议是：主要流程用状态机，把异常处理这种分支流程先做成管理员手动介入，等项目上线稳定后再考虑用 Flowable 替换。

6. 用这个项目打动面试官和答辩老师的几个技巧

在做完基础功能后，还要有一个让项目“看起来不普通”的思路。我这里给三点可以实际操作的技巧，无论后续用来答辩或面试都有帮助。

6.1 准备一套高质量演示数据

一个空荡荡的系统截图和一份“充满真实感”的数据摆在评委面前，观感相差太多了。演示前录入 20 个用户、5 个配送员、50 个不同状态的包裹和订单，并且用脚本让一些订单停留在配送中、一些已经签收。这样在首页看板展示时，能直接看到“今日配送完成率”“待接单订单量”这些指标的变化过程。为了方便演示，可以加一个“重置演示数据”的管理员接口，一键把数据库恢复到初始状态。

6.2 把“为什么”讲出深度

面试官和答辩老师不一定在乎你用了什么框架，他们更关心你有没有想过“为什么”。比如数据库表为什么订单地址要快照？为什么不能用整型做订单状态？为什么 JWT 比 session 适合小程序？这些问题如果每一个都能给出几句原因，项目的含金量就会明显不一样。我前面讲的那些选型理由和踩坑经验，其实就是你这边的完整素材。做一个项目，最重要的是想清楚各种方案背后的代价：使用 SpringBoot 是为了快速开发，保留状态机是为了后续需求扩展不乱套，将 JWT 状态放在客户端是为了小程序这种无 Cookie 环境下好扩展。

6.3 后续可以扩展的几个方向

如果你做完第一版还有精力，可以按这几个方向继续深化：第一，增加统计分析看板，基于 ECharts 展示每日包裹量、配送员工作量、超时订单趋势；第二，引入 Redis 做接单队列，防止多个配送员同时抢同一单造成的超卖问题；第三，增加用户积分或优惠券，用配送积分提升用户粘性；第四，针对包裹破损、用户不在家等异常情况，把异常处理流程做成可配置的规则。这些扩展都不需要更换技术底座，SpringBoot 生态基本都有对应的成熟组件。

我在实际做这类系统后还有一个体会：表面上是做一个包裹配送管理系统，实际上是在练习“如何把线下不透明的服务流程，拆解成线上可追踪的状态流转”。用户看到的是小程序页面，配送员看到的是接单列表，管理员看到的是仪表盘，但这些背后集合的就是一张状态机加几张关联表。技术也许会有更新换代，但这个思考过程相当通用。按这个思路往下做，哪怕以后换一个完全不同的业务，你也知道第一步该干什么。