去年处理家里那台闲置的旧笔记本电脑时我跑了三家线下回收店报价从三百到六百五差距大得离谱。后来又在某平台上折腾估价、拍照、等待上门前后花了两天时间最后还被以“成色不符”为由扣了八十块。这段经历让我特别想做一个真正把流程说清楚、把估价标准透明化的旧物回收商城系统。刚好那阵子在系统学习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-PlusCRUD操作、分页查询、条件构造器提升开发效率数据库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对应回收完成后可二次销售的旧物。这里需要注意回收品上架不是简单插入一条商品记录它需要与回收单关联记录货源IDsource_order_id这样每一件在售的二手商品都能追溯到原始回收单用户购买时能看到质检报告和回收单据信息增强透明度。商品表还包括销售价格、原回收价、成色等级、翻新描述、上架状态等字段价格字段记的是实际成交价而非标价的折扣方便后续统计毛利。订单表order_info就是标准电商订单了但有一个回收和购买融合的设计普通购买订单通过order_type字段区分是“直接购买”还是“积分抵扣购买”抵扣部分记录integral_deduction金额。另外因为用户可能同时有多件回收品在流程中下单时如果收货地址为空系统默认取用户最近的回收单中填写的地址减少重复输入。价格规则表price_rule是这套系统的“定价大脑”。字段包括品类ID、基准价近似全新的回收保底价、成色等级优品/良品/普通/维修品、折扣率、活动加成金额、生效时间、失效时间。价格计算时系统根据用户问卷答案算出成色等级再取对应品类的基准价乘以折扣率加上活动加成最后四舍五入到整数。运营后台可以随时调整这些参数不需要改代码重新部署。数据库设计的整体关系我用一句话总结用户通过回收单把旧物交给平台平台质检后生成商品上架用户再通过订单购买其他回收品形成“回收—处理—再销售”的闭环。所有表都围绕这条主线展开尽量减少孤立的表结构。4. 核心业务模块拆解估价引擎、回收单状态机、商城交易闭环4.1 估价引擎把“几成新”翻译成具体价格这个模块是整套系统的灵魂。用户填写问卷时每道题的选项都对应一个系数后端计算最终预估价的逻辑如下public Integer calculateEstimatePrice(RecycleOrder order) { // 获取品类基础价格 PriceRule rule priceRuleMapper.selectOne( new LambdaQueryWrapperPriceRule() .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 MapInteger, ListInteger 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) { ListInteger 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 11MySQL 8.0Redis 6.x。生产环境我建议把数据库和Redis放在单独的内网应用通过内网IP连接不要暴露公网端口。我在测试阶段图省事把3306端口直接暴露在公网上结果不到半天就收到了几百个来自扫描工具的暴力破解尝试。这个教训相当直接——云服务器防火墙里数据库端口永远不要对公网开放。Nginx反向代理和静态资源因为前端页面是Thymeleaf渲染的后端接口服务本身不需要Nginx做负载均衡但文件上传的图片需要经过Nginx做静态资源映射。我把上传目录配置在/data/uploadNginx配置了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%。从实际运营反馈看用户最在意的三个功能是价格透明能看到折价明细、状态可视化知道物品在哪个环节、流程省心不用自己联系快递。这三个需求对应到技术上分别就是估价引擎的可解释性、回收单状态机的完整记录、以及自动化的业务提醒。如果你也想做一个类似的系统我有几点实在的建议先把回收流程梳理清楚画一张跨角色的泳道图确认每一步的输入输出分别是什么再动手写代码。我见过太多同学一上来就建表结果做到回收单状态流转时才发现少了审核环节的表回头改表结构改得欲哭无泪。另外千万不要把一个角色的操作混在另一个角色的接口里回收员能做的事用户一定不能做这个底线要在接口设计阶段就守住。这个系统后续我还在继续迭代下一步计划接入物流跟踪接口让用户填写回收单后能实时看到快递轨迹减少“东西寄到哪儿了”的咨询量。另外回收品的质检报告目前还是文字加图片等积累足够的质检数据后打算做一个基于图像识别的自动成色初筛降低人工质检的成本。技术上没有太多玄乎的东西核心就是把业务流程理解透然后一步步扎实落地。 
长河君 · 2026/10/14 6:23:42 · 阅读 1.2k 基于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-PlusCRUD操作、分页查询、条件构造器提升开发效率数据库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对应回收完成后可二次销售的旧物。这里需要注意回收品上架不是简单插入一条商品记录它需要与回收单关联记录货源IDsource_order_id这样每一件在售的二手商品都能追溯到原始回收单用户购买时能看到质检报告和回收单据信息增强透明度。商品表还包括销售价格、原回收价、成色等级、翻新描述、上架状态等字段价格字段记的是实际成交价而非标价的折扣方便后续统计毛利。订单表order_info就是标准电商订单了但有一个回收和购买融合的设计普通购买订单通过order_type字段区分是“直接购买”还是“积分抵扣购买”抵扣部分记录integral_deduction金额。另外因为用户可能同时有多件回收品在流程中下单时如果收货地址为空系统默认取用户最近的回收单中填写的地址减少重复输入。价格规则表price_rule是这套系统的“定价大脑”。字段包括品类ID、基准价近似全新的回收保底价、成色等级优品/良品/普通/维修品、折扣率、活动加成金额、生效时间、失效时间。价格计算时系统根据用户问卷答案算出成色等级再取对应品类的基准价乘以折扣率加上活动加成最后四舍五入到整数。运营后台可以随时调整这些参数不需要改代码重新部署。数据库设计的整体关系我用一句话总结用户通过回收单把旧物交给平台平台质检后生成商品上架用户再通过订单购买其他回收品形成“回收—处理—再销售”的闭环。所有表都围绕这条主线展开尽量减少孤立的表结构。4. 核心业务模块拆解估价引擎、回收单状态机、商城交易闭环4.1 估价引擎把“几成新”翻译成具体价格这个模块是整套系统的灵魂。用户填写问卷时每道题的选项都对应一个系数后端计算最终预估价的逻辑如下public Integer calculateEstimatePrice(RecycleOrder order) { // 获取品类基础价格 PriceRule rule priceRuleMapper.selectOne( new LambdaQueryWrapperPriceRule() .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 MapInteger, ListInteger 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) { ListInteger 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 11MySQL 8.0Redis 6.x。生产环境我建议把数据库和Redis放在单独的内网应用通过内网IP连接不要暴露公网端口。我在测试阶段图省事把3306端口直接暴露在公网上结果不到半天就收到了几百个来自扫描工具的暴力破解尝试。这个教训相当直接——云服务器防火墙里数据库端口永远不要对公网开放。Nginx反向代理和静态资源因为前端页面是Thymeleaf渲染的后端接口服务本身不需要Nginx做负载均衡但文件上传的图片需要经过Nginx做静态资源映射。我把上传目录配置在/data/uploadNginx配置了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%。从实际运营反馈看用户最在意的三个功能是价格透明能看到折价明细、状态可视化知道物品在哪个环节、流程省心不用自己联系快递。这三个需求对应到技术上分别就是估价引擎的可解释性、回收单状态机的完整记录、以及自动化的业务提醒。如果你也想做一个类似的系统我有几点实在的建议先把回收流程梳理清楚画一张跨角色的泳道图确认每一步的输入输出分别是什么再动手写代码。我见过太多同学一上来就建表结果做到回收单状态流转时才发现少了审核环节的表回头改表结构改得欲哭无泪。另外千万不要把一个角色的操作混在另一个角色的接口里回收员能做的事用户一定不能做这个底线要在接口设计阶段就守住。这个系统后续我还在继续迭代下一步计划接入物流跟踪接口让用户填写回收单后能实时看到快递轨迹减少“东西寄到哪儿了”的咨询量。另外回收品的质检报告目前还是文字加图片等积累足够的质检数据后打算做一个基于图像识别的自动成色初筛降低人工质检的成本。技术上没有太多玄乎的东西核心就是把业务流程理解透然后一步步扎实落地。