不靠谱的糖饼1. 项目概述与业务场景定位
1.1 为什么看好“好物回收”这门生意
这两年我一直在观察二手闲置交易市场，发现一个很明显的趋势：大家手里不是没有好东西，而是“卖不掉、懒得卖、不知道怎么卖”。闲鱼和转转解决了“C2C撮合”的问题，但交易流程长、信任成本高，很多用户拍个照挂上去半年都卖不出去，最后还是扔了或者压在角落里吃灰。
于是我想做一个更重服务、更重线下的模式：用户在小程序上提交回收订单，回收员按预约时间上门，当面完成质检、估价、打款，整个流程在一个平台上跑通。这个模式本质上不是电商，而是“O2O上门服务”，核心壁垒在线下履约能力，而不是流量分发。
我把它定义为一个“好物回收系统”，从用户端、回收员端、管理后台三条线同时设计，用 Java 技术栈做了完整实现。整套系统从下单、派单、上门、质检、估价、支付、结算到数据统计，业务闭环全部打通。代码量不小，但模块边界清晰，拿来改改就能套用到其他上门服务场景，比如上门维修、上门保洁、上门回收旧衣，底层逻辑基本一致。
这篇文章我会把整套系统的架构设计、核心流程、关键表结构、部署方案和踩坑记录都拆开讲。既适合想用这套代码快速起盘的创业者，也适合正在做 Java 后端开发、想学习真实项目怎么落地的朋友。
1.2 这套系统到底解决了什么
先想清楚一个原始问题：用户为什么不自己把闲置物品卖给回收站？因为传统回收站有几个痛点——价格不透明、距离远、需要自己搬运、担心被压价。而好物回收平台把回收动作搬到了用户家门口，用户只需要拍照上传、预约时间，剩下的交给回收员，这就把交易门槛降到了最低。
从平台运营的角度看，这套系统的核心价值在于把非标品的回收流程标准化。旧手机、旧电脑、旧书籍、旧家电、旧衣物，每一类的估价逻辑、质检标准、回收价格都不同。系统用“品类 + 品牌 + 型号 + 成色 + 功能检测”五个维度做动态估价，配合后台可配置的价格策略，让回收员在现场有据可依，减少人为定价的随意性。
再从创业启动的角度看，这套系统最实在的地方是不需要自建仓储物流。回收员以兼职或众包的模式接入平台，平台只做订单分发和管理，属于典型的轻资产运营。前期只需要一个小程序和一个管理后台，就能跑通整个业务流程，非常适合小团队冷启动。
之前我把这套系统放到社区技术群里分享过一次，不少朋友看完源码后问得最多的问题是：这套系统能不能直接换成上门维修的业务逻辑？我的回答是能，因为订单流转、人员派单、服务评价这套中台逻辑是通用的，只需要替换商品类目和估价规则。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体架构设计与技术选型
2.1 为什么选 Java 技术栈，而不是 PHP 或 Node.js
说实话，做这类业务系统我基本不会犹豫，直接选 Java。原因有三点：
第一，生态成熟。支付对接、短信服务、对象存储、微信小程序登录，这些第三方 SDK 的 Java 版本往往是最先更新、文档最全的。少踩一个坑，上线时间就提前一周。
第二，团队招人容易。Java 开发者的基数大，无论是招全职还是找外包，都相对好找。你创业项目跑起来了，后面要扩团队，Java 的后备力量明显更充足。
第三，性能和稳定性有保障。回收平台的订单量在早期不会很大，但涉及资金结算和敏感的用户信息，JVM 的内存管理和成熟的连接池方案能提供更可靠的底层保障。
技术栈的具体选型如下：
| 技术组件 | 选型 | 说明 |
|---|---|---|
| 核心框架 | Spring Boot 2.7 | 稳定版本，社区资料多，出问题好排查 |
| 持久层 | MyBatis-Plus | 单表操作不用写 SQL，复杂统计用 XML |
| 数据库 | MySQL 8.0 | 主库，存储订单、用户、商品等核心数据 |
| 缓存 | Redis 6.x | 验证码、Token、热点数据、分布式锁 |
| 接口文档 | Knife4j | 基于 Swagger 增强，调试方便 |
| 任务调度 | XXL-JOB | 处理分账结算、订单超时未支付关闭 |
| 部署方式 | 单机 Docker | 早期阶段不做集群，省成本、够用 |
这里有一个很关键的决策，就是早期坚决不用微服务。我见过太多小项目一上来就拆订单服务、用户服务、支付服务，结果开发效率低、排查问题难，最后业务没跑起来技术栈先把自己拖死了。单体应用什么都能干，等单量真正上来了再拆也不迟，这是经历过项目失败后总结出来的教训。
2.2 三端一后台的整体业务结构
整套系统在逻辑上分成四个端，每个端对应的使用人群和核心功能非常清晰：
用户端小程序：用户通过微信小程序进入，完成手机号登录、查看回收品类、提交回收订单、预约上门时间、实时查看订单状态、确认收款、查看回收记录和评价回收员。
回收员端 App：回收员通过 App 接收平台派单或自行抢单，按订单联系用户、上门质检、录入检测结果、确认估价、引导用户确认收款、完成订单。
管理后台 Web：运营人员管理用户、回收员、商品类目、价格策略、订单、优惠券、财务结算等，同时查看核心运营数据看板。
定时调度任务：处理下单后超时未接单自动取消、回收员结算单自动生成、大额订单对账等无用户交互的后台动作。
以一次完整的回收订单为例，整个调用链路大致是：用户提交订单 -> 系统根据区域和回收员在线状态派单 -> 回收员接单 -> 按预约时间上门 -> 录入质检结果 -> 系统根据质检项计算估价 -> 用户确认 -> 回收员支付款项 -> 用户完成服务评价 -> 平台生成结算单。
这四个端在技术上是同一个后端提供 API，通过不同的角色权限控制访问范围。小程序端走用户登录态，App 端走回收员登录态，Web 后台走管理员登录态。用一个后端同时支撑三端，能最大化减少重复代码，也方便统一维护业务逻辑。
2.3 数据库表设计中的几个关键决策
这套系统一共设计了 20 多张业务表，其中几张核心表的结构直接影响业务流程能否跑通，值得单独拿出来说。
回收订单表（recycle_order），这是全系统的核心表。主要字段包括：订单编号、用户ID、回收员ID、品类ID、预约时间段、状态、用户地址快照、质检结果JSON、最终估价金额、支付状态、创建时间、完成时间。地址不关联地址表而是直接存快照，是因为地址后续可能被用户编辑，但订单关联的下单地址必须保持下单时的原样。
**品类估价配置表（category_price