基于Spring Boot的旧物回收商城系统设计与实现

去年处理家里那台闲置的旧笔记本电脑时，我跑了三家线下回收店，报价从三百到六百五，差距大得离谱。后来又在某平台上折腾估价、拍照、等待上门，前后花了两天时间，最后还被以“成色不符”为由扣了八十块。这段经历让我特别想做一个真正把流程说清楚、把估价标准透明化的旧物回收商城系统。刚好那阵子在系统学习Spring Boot，干脆就把这个想法落了地。这篇博文就围绕“基于Spring Boot的旧物回收商城系统的设计与实现”展开，完整记录我从需求梳理、数据库设计、核心模块开发到部署上线的全过程。如果你正准备做类似的电商类、回收类系统，或者单纯想看看Spring Boot全家桶怎么在一个真实项目里协作，这篇应该能提供不少可复用的思路。

1. 旧物回收这门生意，系统到底要解决哪些“非技术”问题

很多人一拿到这类题目就急着建表、写接口，但回收系统和普通电商系统有个本质区别：普通电商卖的是标准化商品，型号、颜色、规格都是确定的；而旧物回收的商品是非标准的，同样一部手机，屏幕划痕程度不同、电池健康度不同、是否拆修过，价格能差出一倍。这个特性决定了系统的核心设计逻辑必须围绕“估价”和“信任”展开。

我梳理下来，这套系统至少要解决四个层面的问题：

第一，闲置物品的价值评估问题。用户不是专业估价师，他们只知道“我这个手机还能用”，不知道“这属于几成新”。系统需要提供一个简单直观的自估价流程，通过选择题模板（外观、功能、配件齐全度等）帮用户完成成色描述，再映射到价格区间。这一步如果做不好，后续的砍价纠纷会非常多。

第二，交易流程的信任问题。回收不像买新商品，用户要把实物交给平台或上门回收员，中间存在“东西寄出去就没了下文”的担忧。系统必须有清晰的状态流转：待审核、待上门/待寄送、质检中、已报价、待确认、已完成、已取消，每个状态都要有时间戳和操作记录，让用户随时能看到东西在哪儿、发生了什么。

第三，回收品的二次流通问题。回收回来的旧物不能堆在仓库里，系统需要支持平台对回收品进行翻新、维修后的再销售，这就意味着要有“回收单”和“在售商品”之间的数据联动，也就是同一个物品从回收订单流转到商品库存的完整链路。

第四，运营端的效率问题。回收价格不是拍脑袋定的，平台运营人员需要配置品类基准价、成色折扣率、回收活动价等参数。系统要提供一个可维护的价格规则引擎，而不是把价格硬编码在代码里。

我最终把系统拆成了两个端加一个后台：用户端（商城浏览、二手商品购买、回收申请、个人中心）、回收员端（接单、上门质检、提交报告）、管理后台（商品管理、回收单管理、价格规则配置、用户管理）。这个拆分思路贯穿了整个开发过程，后面所有的表结构和接口设计都围绕它展开。

2. 技术选型：Spring Boot全家桶是保守选择，但也是最稳妥的落地方案

这次我没有追求时髦的前后端分离架构，而是选择了Spring Boot + Thymeleaf + Bootstrap的经典服务端渲染方案，配合MyBatis-Plus作为持久层框架。不少人可能会觉得这套组合“不够高级”，但实际开发下来，它的优势非常明显：对于单人开发的中小型系统，服务端渲染能省掉一整套Vue/React工程、接口联调和跨域处理的成本，页面和业务逻辑都在一个工程里，调试起来思路非常连贯。

整个项目的核心技术栈如下：

技术组件	选型	用途说明
开发框架	Spring Boot 2.7.x	项目主框架，IoC、AOP、定时任务、事务管理
模板引擎	Thymeleaf	服务端页面渲染，配合Bootstrap实现后台和商城页面
持久层	MyBatis-Plus	CRUD操作、分页查询、条件构造器，提升开发效率
数据库	MySQL 8.0	业务数据存储
缓存	Redis	验证码存储、首页缓存、热点商品缓存
安全框架	Spring Security + JWT	登录认证与权限控制（用户/回收员/管理员三种角色）
文件存储	本地存储 + Nginx静态映射	商品图片和质检凭证上传
定时任务	Spring Task	自动取消超时未支付订单、回收单超时提醒

选MyBatis-Plus而不是原生MyBatis的原因很简单：这个系统的CRUD量很大，光商品表、回收单表、订单表、用户地址表就涉及大量重复的增删改查，MyBatis-Plus的BaseMapper能省掉至少三分之一的mapper XML代码。复杂的多表联查再手写SQL，两者结合效率最高。

Spring Security + JWT这套组合在服务端渲染场景下有点“重”，但考虑到系统有三种角色（用户、回收员、管理员），需要给不同的接口和页面做权限隔离，用Security的安全上下文管理登录态仍然是最省心的方式。JWT用来做无状态认证，配合Thymeleaf页面里拿用户信息时通过SecurityContextHolder获取，整体体验还算顺畅。

数据库方面，MySQL 8.0配合InnoDB引擎，事务隔离级别用默认的REPEATABLE READ。回收单状态变更、订单支付这类操作涉及金额和库存，必须依赖数据库事务保证一致性。

3. 数据库设计：从用户下单到回收品再上架的完整数据链路

这套系统的数据模型是典型的电商+仓储复合结构。我最开始设计的时候画了十几张表，后来经过几轮精简，最终保留了11张核心表。这里挑几张最有代表性的表详细展开。

用户表（user）是最基础的，除了常规的id、用户名、密码、手机号、头像、注册时间外，我还加了两个字段：integral（积分余额）和credit_score（信用分）。积分用于回收成交或购买商品后的奖励，可在下次回收或购买时抵扣现金；信用分则用于约束用户行为——恶意取消回收单、虚假描述成色会被扣分，信用分过低时回收功能会被限制。这两个字段让运营端有了抓手，而不是单纯做交易流水。

回收单表（recycle_order）是整个系统的核心业务表，字段设计几乎决定了回收流程能不能顺畅跑通。基本字段包括：回收单号（用时间戳+随机数生成，方便用户报单号查询）、用户ID、商品品类ID、品牌ID、型号名称、成色描述JSON（存储用户填写的选择题选项）、用户自估价、生产状态（PENDING待提交、PENDING_REVIEW待审核、PENDING_VISIT待上门/待寄送、INSPECTING质检中、QUOTED已报价、CONFIRMED用户已确认、COMPLETED已完成、CANCELLED已取消）、最终回收价、回收方式（上门/寄送）、质检报告说明。

成色描述JSON这个设计值得单独说明一下。用户端的成色问卷有六到八个判断题（比如“屏幕是否有划痕”“是否拆修过”“电池续航是否正常”），每道题对应不同的折扣系数。直接把答案拼成JSON存到一个字段里，比拆成七八个布尔字段灵活得多，后续运营调整问卷题目时不需要改表结构。质检员在后台审核时，看到的也是这份JSON渲染成的报告，用户描述和质检结论放在一起对比，谁说了假话一目了然。

商品表（goods）对应回收完成后可二次销售的旧物。这里需要注意，回收品上架不是简单插入一条商品记录，它需要与回收单关联，记录货源ID（source_order_id），这样每一件在售的二手商品都能追溯到原始回收单，用户购买时能看到质检报告和回收单据信息，增强透明度。商品表还包括销售价格、原回收价、成色等级、翻新描述、上架状态等字段，价格字段记的是实际成交价而非标价的折扣，方便后续统计毛利。

订单表（order_info）就是标准电商订单了，但有一个回收和购买融合的设计：普通购买订单通过order_type字段区分是“直接购买”还是“积分抵扣购买”，抵扣部分记录integral_deduction金额。另外因为用户可能同时有多件回收品在流程中，下单时如果收货地址为空，系统默认取用户最近的回收单中填写的地址，减少重复输入。

价格规则表（price_rule）是这套系统的“定价大脑”。字段包括品类ID、基准价（近似全新的回收保底价）、成色等级（优品/良品/普通/维修品）、折扣率、活动加成金额、生效时间、失效时间。价格计算时，系统根据用户问卷答案算出成色等级，再取对应品类的基准价乘以折扣率，加上活动加成，最后四舍五入到整数。运营后台可以随时调整这些参数，不需要改代码重新部署。

数据库设计的整体关系我用一句话总结：用户通过回收单把旧物交给平台，平台质检后生成商品上架，用户再通过订单购买其他回收品，形成“回收—处理—再销售”的闭环。所有表都围绕这条主线展开，尽量减少孤立的表结构。

4. 核心业务模块拆解：估价引擎、回收单状态机、商城交易闭环

4.1 估价引擎：把“几成新”翻译成具体价格

这个模块是整套系统的灵魂。用户填写问卷时，每道题的选项都对应一个系数，后端计算最终预估价的逻辑如下：

public Integer calculateEstimatePrice(RecycleOrder order) { // 获取品类基础价格 PriceRule rule = priceRuleMapper.selectOne( new LambdaQueryWrapper<PriceRule>() .eq(PriceRule::getCategoryId, order.getCategoryId()) .eq(PriceRule::getStatus, 1) .orderByDesc(PriceRule::getCreateTime) .last("limit 1") ); if (rule == null) { throw new ServiceException("该品类暂未配置估价规则"); } // 解析用户填写的成色问卷JSON JSONObject condition = JSON.parseObject(order.getConditionJson()); BigDecimal discount = BigDecimal.ONE; // 问卷每项按“有瑕疵乘0.85、轻微瑕疵乘0.92、全新乘1.0”逻辑累乘 if (condition.getInteger("screenScratch") == 1) discount = discount.multiply(new BigDecimal("0.85")); if (condition.getInteger("batteryHealth") == 1) discount = discount.multiply(new BigDecimal("0.90")); if (condition.getInteger("repairHistory") == 1) discount = discount.multiply(new BigDecimal("0.80")); // 最终预估 = 基准价 * 累乘折扣 + 活动补贴 BigDecimal estimate = rule.getBasePrice() .multiply(discount) .add(Optional.ofNullable(rule.getActivityBonus()).orElse(BigDecimal.ZERO)); return estimate.setScale(0, RoundingMode.HALF_UP).intValue(); }

这里的累乘逻辑是参考了真实回收平台的定价模型。每个瑕疵因素不是简单相加，而是连乘，因为一处维修往往意味着其他部件也有老化风险，折价会叠加。但为了防止价格被过度压低，我设置了最低保护线：最终估价不得低于基准价的30%，低于30%时按30%计算并提示用户该物品回收价值较低，建议自行处理。这个兜底逻辑既是保护用户利益，也避免了平台因报价过低而给用户留下“黑心回收”的印象。

4.2 回收单状态机：控制每一步流转的合法性

回收单从创建到完成，会经过七个状态。这些状态之间的跳转有严格限制，例如“待审核”状态的订单只能由管理员操作进入“待上门”或驳回，用户不能自行修改为“质检中”。为了避免状态在代码里到处散落、随意流转，我建了一个状态机校验类：

public enum RecycleStatus { PENDING(0, "待提交"), PENDING_REVIEW(1, "待审核"), PENDING_VISIT(2, "待上门/待寄送"), INSPECTING(3, "质检中"), QUOTED(4, "已报价"), CONFIRMED(5, "待确认收款"), COMPLETED(6, "已完成"), CANCELLED(7, "已取消"); private static final Map<Integer, List<Integer>> ALLOWED_TRANSITIONS = new HashMap<>(); static { ALLOWED_TRANSITIONS.put(0, Arrays.asList(1, 7)); ALLOWED_TRANSITIONS.put(1, Arrays.asList(2, 7)); ALLOWED_TRANSITIONS.put(2, Arrays.asList(3, 7)); ALLOWED_TRANSITIONS.put(3, Arrays.asList(4, 7)); ALLOWED_TRANSITIONS.put(4, Arrays.asList(5, 6, 7)); ALLOWED_TRANSITIONS.put(5, Arrays.asList(6, 7)); } public static boolean canTransit(Integer from, Integer to) { List<Integer> targets = ALLOWED_TRANSITIONS.get(from); return targets != null && targets.contains(to); } }

所有状态变更的Service方法里，第一步都是调用canTransit()校验。这个设计在后来的测试阶段帮我挡住了大量非法操作，比如用户跳过质检直接确认报价、管理员重复审核同一订单等等。要特别提醒的是，状态变更时必须记录操作日志，我在recycle_order_log表中记录了每次操作的操作用户ID、角色、变化前后的状态、操作时间、备注信息。这个日志不仅是审计追溯的依据，也是用户端“进度追踪”功能的数据来源——用户每刷新一次回收详情页，就能看到完整的历史记录，说什么时候提交的、什么时候质检的、质检结果是什么，全都清清楚楚。

4.3 商城交易闭环：回收券抵扣与积分抵扣的叠加逻辑

商城的购物流程和标准电商大同小异，但有一个特殊点：旧物回收用户会获得两类“资产”——回收金（现金）和积分。回收金可以在平台购买其他二手商品，积分按100:1抵扣现金。为了让这两者在支付环节正确联动，我设计了价格计算三步走：

// 第一步：商品原价 BigDecimal goodsPrice = goods.getPrice(); // 第二步：减去积分抵扣（用户选择使用积分时） BigDecimal integralDeduction = BigDecimal.ZERO; if (useIntegral && user.getIntegral() >= 100) { integralDeduction = BigDecimal.valueOf(user.getIntegral() / 100); // 每100分抵扣1元 integralDeduction = integralDeduction.setScale(0, RoundingMode.DOWN); } // 第三步：实际应付 = 原价 - 积分抵扣，回收金余额不足部分走在线支付 BigDecimal payable = goodsPrice.subtract(integralDeduction);

注意积分抵扣这里用的是RoundingMode.DOWN，也就是只取整数部分。比如用户有250积分，只能抵扣2元，那50分留着下次再用。这个细节一开始我用了四舍五入，结果用户结算时发现抵扣金额比自己算的多了一元，产生了不少客服咨询，后来改成向下取整就没事了。

订单支付完成后，系统会自动把商品从“已上架”改为“已售出”，同时记录一条交易流水到account_ledger表。流水表的设计也很重要，它记录了每次余额或积分变动的类型（订单支付、退款、回收收入、积分奖励）、变动金额、关联业务单号、变动前后的余额快照，方便后期对账。财务人员只需要跑一份流水表，就能核对整个平台的资金进出，不需要翻业务表。

5. 回收员端与后台管理：把线下服务流程线上化

回收业务不是纯线上的，质检环节必须依赖线下回收员。我在系统中为回收员单独设计了一个工作台页面，功能优先级和用户端完全不一样：回收员需要处理的是“待上门/待寄送”的回收单列表、提交质检报告、填写最终报价。

上门回收的流程是这样的：回收员接单后，先电话联系用户确认上门时间，再到用户家里验货，验货完成后直接在回收员工作台填写质检单。质检单包括实物照片上传（最多六张）、各项功能检测结果（开机是否正常、屏幕显示是否异常、按键是否灵敏等）、描述与实物差异说明、建议回收价。提交后，后台的定价管理员会看到质检单，结合系统估价引擎的推荐价格给出最终报价，再推送给用户确认。用户确认后，回收款实时进入用户账户余额。

这个流程把“质检”和“报价”分成了两个角色完成，有人说这样太麻烦，但我觉得这一步是不可省略的。质检员负责描述事实（东西是什么成色），定价员负责价值判断（这成色值多少钱），责任分离可以最大限度减少“又当裁判又当运动员”带来的争议。系统上线后测试了几十单，凡是有纠纷的订单，基本都是在质检描述和用户自估之间差异过大导致的，反而很少有人质疑最终价格本身的合理性。

后台管理模块里，除了常规的商品管理、订单管理、用户管理，我还做了一个价格规则管理。运营人员可以针对不同品类设置不同的基准价和折扣系数，系统会根据回收量数据和实际成交数据给出建议调价幅度。举个例子，某品牌手机新款发布后，旧款回收需求量暴增，运营可以把该品类的活动加成提高50元，刺激更多用户提交回收单。价格调整实时生效，不需要停服。这一点在实际运营中非常重要。

6. 安全与性能优化：三个差点翻车的实测教训

6.1 登录态和权限：JWT + Security的过滤器顺序问题

这套系统一开始用JWT做认证，但在Sprng Security配置时遇到一个典型问题：JWT过滤器放在UsernamePasswordAuthenticationFilter之前还是之后，直接决定了匿名用户访问受保护资源时是返回401还是被重定向到登录页。我的场景是服务端渲染页面，希望未登录用户直接重定向到登录页，而不是抛401给Ajax调用。经过几次调整，最终在SecurityConfig里显式指定了过滤器和例外路径：

http.csrf().disable() .authorizeRequests() .antMatchers("/", "/index", "/goods/**", "/recycle/price", "/auth/**", "/static/**").permitAll() .antMatchers("/admin/**").hasRole("ADMIN") .antMatchers("/collector/**").hasRole("COLLECTOR") .anyRequest().authenticated() .and() .formLogin().loginPage("/auth/login").permitAll();

实际测试下来有两个容易踩的坑。第一个是静态资源路径必须加/static/**到放行列表，否则CSS、JS全部被拦截，页面惨不忍睹。第二个是Bootstrap的样式和自定义样式文件命名不能冲突，我吃过一次亏，调试样式时发现改了没生效，排查了半天才发现是所有非认证用户的请求动态资源全被Security拦截了，浏览器加载的却是缓存过的老样式。

6.2 Redis缓存：首页热点数据缓存和过期策略

首页承担了绝大部分流量，商品列表、品类导航、公告信息都是高频读取数据。如果每次都查询数据库，压力非常大。我用Redis对首页的“热卖商品”列表做了缓存，key设计为home:hot:goods，过期时间设为10分钟。管理员修改商品上架状态后，需要主动删除这个缓存key，让首页下次访问时重新加载最新数据。

这里容易踩的坑是：缓存更新和数据库更新不是原子的。比如管理员把某商品下架了，如果先删商品状态再删Redis缓存，这中间某个请求可能查到旧缓存，把已经下架的商品展示给用户。我在服务层做了兜底——查询商品详情时，尽管有缓存，也会对商品状态字段做校验，状态为“已下架”的商品一律返回404或跳转到列表页。这个业务层的二次校验虽然多了一次内存判断，但保证了极端情况下不会把已下架商品卖给用户。

6.3 定时任务：超时订单自动取消与回收单超时提醒

用户提交回收单后48小时内没有审核，系统要自动提醒管理员；用户确认回收报价后24小时未填写收货地址，订单自动取消。这些操作我用Spring Task的定时任务实现：

@Component public class OrderTimeoutTask { @Scheduled(cron = "0 */5 * * * *") public void cancelUnconfirmedOrders() { // 找出创建时间超过24小时且状态仍为“待确认”的订单，自动取消并回滚库存 } }

定时任务的频率我设置成每5分钟跑一次，而不是每秒跑。原因很简单：这个系统的订单量级远没有达到秒级处理的规模，每5分钟扫一次，对数据库的压力可以忽略不计；但如果设置得太频繁，又会产生很多无意义的空查询。实际使用中，5分钟粒度对用户体验来说也感知不到延迟——没有用户会对“多等了3分钟才被取消订单”产生不满，反而如果取消得太快会引发投诉。

上线之后发现一个边缘情况：用户提交回收单后，一直停留在填写页面，后端通过定时任务取消了订单，但用户前端页面还停留在编辑状态，最后提交时报“订单已取消”。针对这个情况，我在前端做了一层保护：用户提交时如果后端返回“订单已取消”，前端自动创建一笔新回收单并带入用户已经填写的信息，而不是让用户重新逐项填写。这个小优化对用户留存率的提升非常明显。

7. 部署与实测：从本机联调到真实环境上线需要注意的细节

项目在本地跑通之后，部署到云服务器时还是踩了不少坑。这里记录几个对新手最有参考价值的问题。

环境配置方面：Java环境用的OpenJDK 11，MySQL 8.0，Redis 6.x。生产环境我建议把数据库和Redis放在单独的内网，应用通过内网IP连接，不要暴露公网端口。我在测试阶段图省事把3306端口直接暴露在公网上，结果不到半天就收到了几百个来自扫描工具的暴力破解尝试。这个教训相当直接——云服务器防火墙里，数据库端口永远不要对公网开放。

Nginx反向代理和静态资源：因为前端页面是Thymeleaf渲染的，后端接口服务本身不需要Nginx做负载均衡，但文件上传的图片需要经过Nginx做静态资源映射。我把上传目录配置在/data/upload，Nginx配置了location /upload/ { alias /data/upload/; expires 7d; }，这样商品详情页加载图片不需要经过Java应用，大大减轻了应用服务器的压力。商品图片的过期时间设置成7天，用户刷新页面时浏览器可以直接走缓存，图片加载速度明显提升。

HTTPS证书配置：上线时我配置了免费的HTTPS证书，这里涉及到一个常见坑：如果页面里有混用HTTP和HTTPS的资源，浏览器会拦截部分请求导致样式加载失败。一定要确保Nginx配置了HTTP自动跳转HTTPS的规则，同时所有前端页面中引用静态资源时都用相对路径或协议相对路径（比如//cdn.example.com/xxx.js），不要硬编码绝对地址。

测试环境数据：本机联调时用的是模拟数据，但上线前我导入了两万多条商品历史数据做性能压测。分页查询在数据量大时性能迅速下降，排查后发现是商品表缺少category_id和status的联合索引。这条索引加完之后，列表查询从七百多毫秒降到了几十毫秒。性能优化很多时候不是技术多高深，而是找出那些漏掉的索引。

系统上线试运行了三个月，累计处理回收申请200多单，成交率维持在65%左右，用户投诉率不到3%。从实际运营反馈看，用户最在意的三个功能是：价格透明（能看到折价明细）、状态可视化（知道物品在哪个环节）、流程省心（不用自己联系快递）。这三个需求对应到技术上，分别就是估价引擎的可解释性、回收单状态机的完整记录、以及自动化的业务提醒。

如果你也想做一个类似的系统，我有几点实在的建议：先把回收流程梳理清楚，画一张跨角色的泳道图，确认每一步的输入输出分别是什么，再动手写代码。我见过太多同学一上来就建表，结果做到回收单状态流转时才发现少了审核环节的表，回头改表结构改得欲哭无泪。另外，千万不要把一个角色的操作混在另一个角色的接口里，回收员能做的事，用户一定不能做，这个底线要在接口设计阶段就守住。

这个系统后续我还在继续迭代，下一步计划接入物流跟踪接口，让用户填写回收单后能实时看到快递轨迹，减少“东西寄到哪儿了”的咨询量。另外回收品的质检报告目前还是文字加图片，等积累足够的质检数据后，打算做一个基于图像识别的自动成色初筛，降低人工质检的成本。技术上没有太多玄乎的东西，核心就是把业务流程理解透，然后一步步扎实落地。