从个人开发经验来说二手电子产品回收系统这种项目最难的不是某个功能写不出来而是整条业务链路怎么串起来、状态怎么管、估价逻辑怎么设计才能让系统真正能落地。市面上很多教程都在讲单个功能点的代码真正把“用户提交回收申请→系统估价→回收员接单→检测打款”这条完整闭环跑通的项目总结非常少。这篇博文我就拿自己实际做过的一个项目来拆解系统基于 Python 双框架实现Django 负责管理后台与核心业务Flask 负责轻量估价服务和部分对外接口把整个设计与实现过程、踩过的坑、关键代码全部整理出来希望能给准备做类似系统的人一些参考。老实说刚开始我也纠结过要不要统一用 Django 一个框架毕竟一个框架搞定所有功能部署也简单。但实际做下来发现二手回收业务有个特点估价逻辑变化非常频繁今天这个型号行情涨了明天那个机型回收价调整如果每次改估价规则都要重启主应用线上用户正在操作就会受影响。后来我把估价拆成独立的 Flask 服务Django 通过 HTTP 调用它拿估价结果这样改估价规则只需要重启 Flask 服务主站完全不受影响。这个架构为整个系统省了非常多麻烦也是我觉得最值得分享的一个设计决策。项目定位说明这个系统面向的是一般回收商或校园创业团队不是那种大型平台级回收系统但核心业务链路完整可以平滑扩展到小程序端和线下门店使用。1. 项目整体设计与需求拆解1.1 核心需求到底有哪些做这类系统之前一定要先想清楚一个事二手电子产品回收不是单纯的“二手交易”它比 C2C 交易多了一个“检测与定价”环节。用户卖手机给你你不能直接按用户报价打款必须等设备收到、检测完、确认没问题才算完成交易。所以核心需求整理下来其实就这几块。第一块是用户端需求。用户注册登录后可以提交回收申请选择电子产品类型手机、平板、笔记本、耳机、手表等填写品牌型号、购买年份、存储容量、成色描述上传设备外观照片然后系统根据这些信息给出预估价。用户认可估价后选择回收方式上门取件或邮寄填写地址生成回收订单后续可以在订单列表里查看进度状态。第二块是回收员/检测员需求。回收员端需要看到待接单的回收订单接单后上门取件检测员收到设备后需要登记检测结果包括设备实际成色、功能是否正常、有无维修痕迹然后录入实际回收价。如果检测结果和用户申报不一致需要能修改价格并让用户确认。第三块是管理员需求。管理员要能管理用户、管理商品型号库、管理估价规则、查看所有订单、处理纠纷、做数据统计还要能发布回收活动比如旧机补贴、以旧换新。这些需求没有 Django Admin 也能做但用了 Django Admin 可以节省非常多的开发时间。第四块是估价服务。这个看起来不起眼实际上最烧脑。估价不能只写死在代码里要有规则可配置同样的 iPhone 13 128G外观完美无修和屏幕有划痕回收价差了非常多。估价规则本质上是一个多条件评分逻辑需要把设备属性映射到价格区间。1.2 双框架架构的选型理由我最终选择 Django Flask 的混合架构不是炫技而是被项目需求逼出来的。Django 的定位是主后端服务负责用户、订单、回收流程、后台管理、权限体系这些重业务。Django 自带 ORM、Admin、Form 校验、中间件这些东西对业务系统来说太成熟了尤其是 Django Admin我直接把回收订单、用户、型号库注册进去管理后台就完成了大半。Flask 的定位是估价服务和轻量接口。估价规则变化快而且后续打算接行情数据源用 Flask 这种轻框架做微服务拆分独立部署、独立升级、独立扩展非常合适。主服务和估价服务之间通过 HTTP JSON 通信Django 不直接操作估价的数据库表。选型时还考虑过 Flask 全栈、Django 全栈、FastAPI 全栈。Flask 全栈的问题是用户体系、Admin、权限都要自己搭工作量巨大FastAPI 虽然后起之秀性能好但生态在管理后台方面不如 Django 成熟。Django Flask 的组合算是在这个特定业务场景里“既要又要”的一个折中方案。注意双框架不等于两套系统两者的边界要清晰。我的划分标准是凡是要写业务逻辑、操作数据库的放 Django凡是纯计算、纯逻辑、要高频改动的放 Flask。这样代码仓库可以放同一个工程目录下但进程和数据库逻辑上是分离的。1.3 功能模块清单与整体架构系统按功能模块划分主要包括模块核心功能归属框架用户模块注册登录、个人信息、地址管理Django回收申请模块设备信息填写、照片上传、预估价获取Django Flask估价服务模块估价规则配置、价格计算、行情调整Flask订单模块订单生成、状态流转、物流信息Django检测模块检测结果录入、价格调整、图片上传Django支付结算模块打款记录、提现、结算单Django管理后台用户管理、型号管理、订单管理、数据统计Django Admin接口服务小程序/APP 对接 APIDjango Flask整体请求链路举个例子用户在页面提交回收申请前端先把表单数据传到 DjangoDjango 保存申请草稿后把设备参数通过 HTTP 请求发给 Flask 估价服务Flask 根据规则计算出预估价返回Django 把预估价写入草稿记录并展示给用户。用户确认后正式生成回收订单。这个流程保证用户感知的“估价很快”与“估价规则灵活调整”两者兼得。2. 数据库设计与核心模块实现2.1 核心数据表设计数据库设计是这类系统最关键的部分一旦后期要改表结构牵一发动全身。我用了 MySQL 8.0字符集 utf8mb4。核心表包括用户表、回收订单表、估价规则表、检测记录表、物流记录表、结算记录表。下面挑几张贴出来讲。用户表基本复用 Django 自带的 auth.User我额外扩展了一个 Profile 表存手机号、头像、积分这些字段而不是直接改 auth.User 表因为 Django 的 auth.User 在迁移和升级时容易出问题扩展表更安全。回收订单表是最核心的表字段设计必须考虑状态流转的灵活性。我当时建的表大致是这样id, order_no, user_id, device_type, brand, model_name, storage, color, purchase_year, condition_desc, condition_images, estimated_price, confirmed_price, final_price, status, address_id, express_no, create_time, update_time其中 status 字段是灵魂后面会专门讲状态机。order_no 一定要做唯一索引用户端展示、物流查询、内部沟通都用它。估价规则表我放在了 Flask 服务的数据库里但 Django 侧通过接口读取不直接连表。表结构大致是设备类型、品牌、型号、基础价、内存系数、成色系数、配件扣减、市场浮动价、更新时间。核心思想是“基础价 条件系数修正”而不是给每个型号写死一个价格。检测记录表单独拆出来因为一个订单可能被检测两次第一次检测不合格用户复议后复检记录表存检测人、检测结果、检测备注、价格调整记录、复检关联 ID确保每次检测都有迹可循。2.2 订单状态机的设计思路订单状态是整个系统里最容易写烂的部分。很多人用几个 if/else 硬写最后状态越来越多逻辑越来越乱。我在这个项目里用状态机来管理把状态和流转条件集中定义出来。核心状态分为待估价、待确认、待取件/待邮寄、检测中、待结算、已完成、已取消、已拒绝。每个状态允许流转到哪些目标状态要画一张表当前状态可流转状态触发条件待估价待确认、已取消用户确认预估价 / 用户取消待确认待取件、待邮寄、待估价、已取消用户选择回收方式 / 用户改价重新估价待取件/待邮寄检测中、已取消回收员接单取件/用户邮寄并填写单号检测中待结算、待确认、已拒绝检测通过自动确认 / 检测价变更需用户确认 / 检测不合格退回待结算已完成打款完成已拒绝已取消用户放弃回收这个状态机在代码里怎么实现呢我定义了一个字典每个状态的合法目标状态是个集合流转时先校验不合法直接抛异常这样就不会出现用户还在“检测中”结果订单就显示“已完成”这种低级错误。状态变更必须做记录。我加了一张 order_log 表每次状态改变都写一条日志包含操作者、旧状态、新状态、操作时间、备注。刚开始我觉得这个表多余后来排查线上问题时才发现状态日志几乎是唯一能还原现场的依据。2.3 用户认证与权限控制用户认证我用了 Django 自带的 session 认证没有引入 JWT因为主业务是服务端渲染页面 Admin 后台session 简单可靠。接口部分为了后续小程序接入单独实现了一个简单的 Token 鉴权用户在 App 登录后拿到 token后续请求在 Header 带 tokenDjango 中间件统一校验。权限控制分三层普通用户只能看自己的订单回收员能看分配给自己的待取件订单管理员能看全部订单和后台管理页面。Django 自带的 Group 和 Permission 机制基本够用我用 Group 创建了“回收员”组然后在视图函数里用装饰器判断。需要说明的是Django 的权限控制默认作用在模型层级要控制到“回收员只能看到指定物流公司分配的单子”这种行级权限需要自己在 queryset 里加过滤条件。经验之谈行级权限不要硬编码最好做成可配置的规则比如“回收员只能看到自己所属区域内的订单”区域 ID 存在回收员 Profile 里查询时动态过滤后续加城市回收站的时候不用改代码。3. 用户端与管理端的实操流程实现3.1 回收申请与估价核心流程用户提交回收申请前端表单收集的数据包括品牌、型号、存储、购买年份、外观成色、功能问题、期望价格。外观成色我做成单选加图片上传功能问题做成多选框比如“屏幕有划痕”“电池不耐用”“摄像头有灰尘”“无法开机”等这些选项直接影响估价系数。表单提交到 Django 后Django 先生成一条状态为“待估价”的草稿记录然后调用 Flask 估价服务。调用代码如下import requests import json def get_estimate_price(device_data): url http://127.0.0.1:5001/api/estimate payload { device_type: device_data.get(device_type), brand: device_data.get(brand), model: device_data.get(model_name), storage: device_data.get(storage), condition: device_data.get(condition_desc), issues: device_data.get(issues) } try: resp requests.post(url, jsonpayload, timeout3) if resp.status_code 200: return resp.json().get(estimated_price) except requests.exceptions.RequestException: # 估价服务异常时返回兜底价格避免主流程直接失败 return get_default_price(device_data)这段代码里我加了 3 秒超时和异常兜底。真实踩过的坑是Flask 估价服务重启或者数据库连接池超时的时候前端会一直转圈用户以为卡死了。后来我的处理方式是 Django 侧 catch 所有网络异常直接返回一个默认估价同时后台记录告警日志保证用户流程不被一块“估价”卡死。这个兜底看似简单实际对用户体验的提升非常明显。Flask 端的估价逻辑简化如下from flask import Flask, request, jsonify app Flask(__name__) ESTIMATE_BASE { iphone_13_128: 2800, iphone_13_256: 3200, xiaomi_12_128: 1600, } def calc_condition_coefficient(condition): mapping { 全新: 1.0, 95新: 0.95, 9成新: 0.88, 8成新: 0.78, 有维修: 0.6, } return mapping.get(condition, 0.7) app.route(/api/estimate, methods[POST]) def estimate(): data request.get_json() base_price ESTIMATE_BASE.get(data[model], 0) condition_coef calc_condition_coefficient(data[condition]) storage_coef 1.0 (data.get(storage, 128) - 128) / 1000.0 estimated_price round(base_price * condition_coef * storage_coef, 2) return jsonify({estimated_price: estimated_price})真实项目的估价规则比这个复杂得多比如要按购买年份折旧、按功能问题扣减、按市场行情浮动但核心逻辑都是“基础价×成色系数×配置系数-问题扣减行情浮动”把规则做成 JSON 配置存数据库运营人员可以直接在后台改不用发版。3.2 回收订单流转与物流信息更新用户确认估价后订单状态从“待确认”变为“待取件”或“待邮寄”。选择上门取件的系统会把订单放入回收员任务池回收员在后台“接单大厅”里看到待取件订单接单后更新订单状态并锁定订单防止多个回收员同时抢单。针对同时抢单并发问题我在订单表加了一个 lock_by 字段回收员点击接单时用 UPDATE 语句带条件更新实现原子操作。伪代码是updated Order.objects.filter(idorder_id, status待取件, lock_by__isnullTrue).update( lock_byrecycler_id, status待取件, update_timenow() ) if updated 0: return error(订单已被其他人接单)这个写法能避免先 SELECT 再 UPDATE 导致的超卖问题。我最初用“先查后更”的逻辑测试的时候开两个账号同时点接单两个都提示成功后来改成这种“条件更新”的方式才彻底解决。用户选择邮寄回收的需要在订单里填写快递公司和运单号系统会有一个简单的物流信息录入入口。真正对接快递鸟这种物流查询接口我放在了二期第一期只是人工查看物流轨迹够用。3.3 管理后台检测录入与价格调整检测员收到设备后在后台打开检测页面录入实际检测结果。检测页面的核心是“检测报告 最终报价”的组合有成色复评、功能检测列表屏幕、摄像头、电池、充电口、主板、按键、维修史检测每一项都能勾选“正常/异常”异常项填写描述。检测完成后系统计算最终回收价。这里有个容易忽略的点检测价格和预估价很可能不一致如果检测价格低于预估价的 10% 以上系统不能直接打款而是要生成一条“价格变更确认”消息推送给用户用户同意后订单才能进入“待结算”用户不同意则订单进入“待退回”状态设备原路退回。这个机制我一开始没做结果用户收到打款金额和预估差很多直接投诉后来老老实实补上了。后端检测提交的核心逻辑伪代码如下def submit_inspection(order_id, inspection_data): order Order.objects.select_for_update().get(idorder_id) if order.status not in [检测中]: raise BusinessError(订单状态不允许检测提交) inspection Inspection.objects.create( orderorder, final_priceinspection_data[final_price], items_resultjson.dumps(inspection_data[items]), operatorrequest.user ) if inspection_data[final_price] order.confirmed_price * 0.9: order.status 待确认 order.price_change_status pending else: order.status 待结算 order.final_price inspection_data[final_price] order.save() add_order_log(order, 检测完成, ...)select_for_update 是为了防止两个检测员同时打开同一订单分别提交数据库行锁能保证同一时间只有一个人能修改。注意select_for_update 必须放在事务里才生效我一开始没写 with transaction.atomic()行锁失效排查半天才意识到。3.4 管理员后台的数据统计与分析Django Admin 默认只能做简单的 CRUD数据统计还得自己写视图。我的做法是做一个独立的数据看板页面展示几个核心指标每日新增回收申请数、订单完成率、平均回收价、各品牌回收占比、待处理订单数量。统计 SQL 不难但要注意时间范围和时区问题。我遇到过统计结果和实际订单数据对不上是因为服务端时区是 UTC而业务统计用的是北京时间两个差了 8 小时晚 8 点后的订单被统计到第二天去了。后来统一在数据库查询时用本地时区前端展示也一致才彻底解决。4. 常见问题排查与部署实战经验4.1 开发期踩过的印象最深的坑第一个坑是 Flask 和 Django 同属一个工程目录时根目录的 requirements.txt 和启动命令容易混。我当时的工程结构是project_root/ ├── django_project/ │ ├── manage.py │ ├── config/ │ └── apps/ ├── flask_service/ │ ├── app.py │ └── estimate_rules.py ├── requirements.txt └── deploy/两个框架共用一套虚拟环境但启动方式完全不同Django 用 manage.py runserverFlask 用 python app.py。我建议在 README 里把两套启动命令写清楚否则过两周你自己都不记得哪个端口对应哪个服务。第二个坑是图片上传大小限制。用户上传设备照片我最初没有限制文件大小结果有人上传一张 15MB 的图片Django 直接内存溢出页面 500。后来在配置里加了 MAX_UPLOAD_SIZE前端也做了压缩后端再用 Pillow 统一压缩成 800px 宽度的 JPG 存储问题解决。第三个坑是 Flask 估价服务的并发性能。Flask 自带开发服务器是单线程的并发一高就阻塞。我本地测试没问题部署后生产环境一压测接口响应时间从 50ms 涨到 3 秒。解决方案是生产环境用 gunicorn 启动 Flask配置多 worker同时在 Django 侧对估价接口做缓存相同型号、相同成色的估价请求直接命中缓存不重复计算。4.2 下单与接单的并发处理并发问题除了前面说的接单场景还出现在下单环节。用户重复点击“提交订单”按钮会生成多条相同内容的订单。前端的处理是按钮置灰加 loading后端的处理是幂等校验根据用户 ID 设备唯一标识 当日时间生成一个幂等键数据库加唯一索引重复请求直接返回已有订单。这个幂等键设计一开始没做测试时用脚本模拟并发请求 10 次数据库里出现 10 条一模一样的订单用户被扣了 10 次预估价额度非常尴尬。加了幂等键后相同的请求只允许创建一次从根源上避免脏数据。4.3 生产环境部署步骤详解部署我采用的是同机部署双服务用 Nginx 做统一入口按路径转发/api/estimate/* 转发到 Flask 的 5001 端口其他所有请求转发到 Django 的 8000 端口静态文件和上传文件由 Nginx 直接处理。部署步骤简单整理如下服务器上创建虚拟环境安装 requirements.txt。安装并配置 MySQL创建数据库导入初始数据。用 collectstatic 收集 Django 静态文件。编写两个 systemd 服务文件分别管理 Djangogunicorn 8 worker和 Flaskgunicorn 4 worker。配置 Nginx反向代理到两个服务端口配置上传文件目录别名。部署完成后用 curl 分别测试 Django 首页和 Flask 估价接口是否正常。gunicorn 配置我推荐一行命令搞定gunicorn config.wsgi:application -w 8 -b 127.0.0.1:8000 --timeout 60Flask 服务同理gunicorn app:app -w 4 -b 127.0.0.1:5001 --timeout 30worker 数量不是越多越好要根据服务器 CPU 核心数来一般 2 核服务器 Django 配 4 个 worker 足够太多反而增加内存消耗导致 OOM。上线前一定要检查 Django 的 DEBUG 是否设置为 FalseALLOWED_HOSTS 是否配置了你的域名。我犯过一次上线几个小时用户访问全部 500 的错罪魁祸首就是 DEBUGTrue代码异常时直接把敏感信息暴露在页面上。4.4 常见问题速查表问题现象可能原因排查思路页面 500日志无报错ALLOWED_HOSTS 未配置检查 settings.py添加域名到白名单用户图片上传失败上传大小超限查看上传目录权限和配置文件大小限制估价接口偶发超时Flask worker 数不足检查 gunicorn 日志按并发调整 worker 数订单状态混乱状态机校验缺失检查状态流转代码确认所有入口都走统一更新方法接单后订单丢失事务未正确提交检查是否使用 atomic 包裹订单更新逻辑统计数据少 8 小时时区不一致统一数据库连接时区和业务展示时区后台地址栏输入订单号显示别人的订单行级权限未做增加 queryset 过滤校验订单归属我给自己的排查流程是先看后端日志再看 Nginx 日志然后确认是 Django 问题还是 Flask 问题最后定位到具体接口。日志一定要加上请求 ID 和用户 ID否则排查用户反馈时根本不知道对应哪一条记录。5. 一些个人经验分享与后续扩展方向这个项目从设计到上线前前后后花了大约两个月核心开发时间其实只占一半另一半都花在状态流转逻辑、并发处理和部署安全这些“看不见的地方”。我最大的体会是业务系统最怕的不是功能少而是逻辑上的漏洞。比如状态机设计完整了订单就不会乱条件更新写对了并发就不会超兜底逻辑做足了外部服务挂了你也不会崩。对于后续扩展我计划往这三个方向推进。第一个方向是接入更智能的估价模型。前面说的估价规则还是基于人工配置的系数下一步想引入历史成交数据用简单回归模型预测回收价让估价更贴近市场真实行情。其实做起来不复杂把历史订单的“最终回收价”作为标签设备属性作为特征训练一个轻量模型Flask 服务里直接加载模型文件实时预测。第二个方向是对接物流查询接口和微信小程序。小程序可以复用 Django 的接口把核心回收流程搬到微信端用户拍照上传更方便物流查询对接快递鸟开放平台后用户随时能看到设备走到哪一步非常能提升信任感。第三个方向是运营侧的数据分析。现在后台统计只做了基础指标后续想把用户流失分析做起来用户在哪个环节放弃最多估价和最终价格的差距对成交率影响有多大这些都能指导运营优化回收流程。写到最后说一句实在的如果你也想做类似系统先把需求边界想清楚再搭骨架然后一个模块一个模块填肉。别一上来就追求完美的架构更别一开始就 CTD。先把最核心链路跑通你会在迭代过程中自然地发现问题、调整设计。这也是我个人做这个项目收获最大的一点。