简介这是基于YOLOv8的智能结算系统完整源码与详细文档面向深度学习及计算机视觉方向的毕业设计、课程项目或工程实践人员解决传统超市自助结账扫码慢、排队久等痛点实现无需条形码的多商品快速识别。资源包共770个文件、64.79MB包含278张jpg图像、264个txt标注文件、190个json配置以及Python源码、onnx/pt模型权重、训练配置yaml和csv日志等从数据标注到模型训练、评估与部署均有覆盖。用户可通过文档说明快速复现识别流程也可在已有基础上改进模型结构或优化识别策略适合作为高分项目参考。已有74人学习下载适合需要完整工程参考与实战经验的开发者深入学习。1. 智能结算系统为什么离不开YOLOv8超市自助收银、食堂餐线计价、无人便利店取货这些场景的共性是“识别对象多、结算要求快、错漏代价高”。传统方案靠 RFID 标签或人工扫码前者要改商品包装、后者在高峰期排队严重。基于 YOLOv8 的智能结算系统走的是另一条路用摄像头直接看盘子里的东西检测出目标类别和位置再由结算模块映射商品、计算金额、生成订单。它解决的是“把视觉识别结果变成可入账的交易数据”这整条链路而不只是“能认出东西”这一步。适合的人群是做目标检测落地但没接触过业务系统的开发者或者已经在用 YOLOv8 做识别、想把结果接到库存和支付流程里的工程师。这套系统的难点不在模型精度而在“识别完之后怎么处理”所以本文会从数据集配置、模型训练、结算逻辑到部署排错完整走一遍。2. 用 YOLOv8 训练识别目标数据集构造与模型配置2.1 结算场景的数据采集摄像头视角决定数据质量很多项目拿公开数据集如 COCO直接训练放到结算场景马上掉点。原因是结算摄像头的视角是俯拍或者斜 45 度俯拍商品之间互相遮挡、反光、密集摆放这和 COCO 里那些日常物体照片的分布差异很大。我一般会建议先架好相机拍 3000 到 5000 张真实摆放的照片覆盖不同光源、不同背景、不同遮挡程度。如果商品种类多但单类样本少就先用手机拍再用随机裁剪、旋转、亮度抖动做离线增强。采集时注意留出 10% 的图片完全不参与训练专门用来验证泛化能力。标注格式推荐 YOLO 的 txt 格式每行是“类别id 中心点x 中心点y 宽 高”坐标都是归一化到 0 到 1。开源工具 LabelImg 或者 Label Studio 都支持直接导出这种格式。有一点容易漏结算场景里同一个商品可能出现在画面边缘这时目标框会被截断标注时要不要框全我默认框到可见部分然后靠后处理去重逻辑弥补不要在标注阶段强行猜测被截掉的部分。2.2 模型选型按 GPU 和帧率要求选 YOLOv8 变体YOLOv8 提供 n/s/m/l/x 五档结算系统最常见的部署环境是普通办公电脑的 GTX 1660Ti 或者边缘设备 RK3588也有直接跑在服务器 CPU 上的。选型不能只看 mAP要看“每秒能处理多少帧”和“单帧能承载多少商品”。自助结算台通常要求 2 到 3 秒内完成一轮识别所以单帧推理加后处理要控制在 300 毫秒以内如果是无人货柜摄像头抓拍频率低可以选择精度更高的 yolov8m 或 yolov8l。模型输入分辨率单帧推理耗时1660Ti小目标精度适用场景yolov8n640x640约 15ms一般边缘设备 / 快速原型yolov8s640x640约 25ms中等单路结算台yolov8m640x640约 45ms较好多商品重叠场景yolov8l1280x1280约 120ms好高精度、低帧率需求训练时默认输入分辨率是 640如果商品小且密集可以提高到 960 或 1280但推理耗时也同步上升。对小商品更好的做法是切图把 1920x1080 的画面切成 4 块 960x540 分别识别再合并坐标这样比直接放大整图要稳得多。2.3 训练命令与关键参数不要让默认参数拖后腿YOLOv8 用 ultralytics 库训练最小命令非常短但参数要按结算场景调整。下面是一个适合小规模商品识别的训练脚本yolo train \ modelyolov8s.pt \ datasettlement.yaml \ epochs200 \ imgsz640 \ batch16 \ patience30 \ lr00.01 \ cos_lrTrue \ device0datasettlement.yaml里需要指定训练集和验证集路径以及类别名称列表格式和 COCO128 示例保持一致。epochs200对几千张图的数据集够用patience30表示连续 30 轮验证集指标没有提升就提前停止避免过拟合浪费时间。cos_lrTrue让学习率按余弦曲线衰减训练后期更平滑。小数据集上lr0不要用默认的 0.01可以降到 0.005否则前几轮容易震荡。训练完成后重点看两个指标验证集 mAP50-95 和每个类别的 recall。结算场景里漏检比误检严重因为漏检意味着商品没算钱所以 recall 比 precision 更优先。如果某个类别 recall 偏低优先检查是不是样本太少而不是急着换模型。提示训练损失曲线如果在最后几十轮还在明显下降但 mAP 不涨说明模型已经过拟合回退到 patience 保存的最佳权重即可不要直接使用最后一轮权重。3. 结算逻辑从检测坐标到订单金额的完整实现3.1 把每帧检测结果变成“稳定存在”的商品条目YOLOv8 是单帧检测模型对视频流里的同一商品每帧都会输出一个检测框。如果直接把每帧结果累加进购物车同一个苹果会被记录成七八个苹果。所以结算系统的第一层逻辑是目标追踪而不是检测。常见做法是配合 ByteTrack 或者 DeepSORT给每个检测框分配一个 track_id然后在连续帧里跟踪这个 id 的位置变化。但追踪方案多一个依赖维护成本高。如果结算场景是“商品放上结算台静止后拍照识别”可以不用追踪而是在 500 毫秒内连续拍 5 帧对每一帧做检测然后用 IoU 判断不同帧里的框是否对应同一个商品。对应规则是两个框的 IoU 大于 0.6 就认为是同一商品取 5 帧里置信度最高的一次结果作为最终记录。这样既消除了运动模糊带来的误检又不需要追踪模型。代码如下def merge_detections(detections_list, iou_threshold0.6): 将多帧检测结果合并 detections_list: list[list[Detection]], 每个 Detection 有 bbox, cls, conf merged [] for det in detections_list[0]: count 0 matched False for other in detections_list[1:]: matched_box find_max_iou_box(det.bbox, other, iou_threshold) if matched_box: det.bbox average_bbox(det.bbox, matched_box.bbox) det.conf max(det.conf, matched_box.conf) count 1 # 至少出现3帧才认为是一个稳定目标防止单帧闪烁误检 if count 2: merged.append(det) return merged逻辑说明第一帧的每个检测框作为候选去和后续 4 帧里 IoU 最大的框匹配count 2表示该目标至少被 3 帧确认。average_bbox做的是按坐标取平均这样最终框位置比任何单帧都稳。conf取最大值因为商品被遮挡时某一帧置信度可能低但只要有帧置信度高就不该漏掉它。3.2 类别 ID 到商品条码的映射处理一物多类的问题模型输出的类别 ID 是“视觉类别”比如“可口可乐 330ml”和“百事可乐 330ml”在视觉上长得不一样需要映射到不同的 SKU。但对于同一款商品的不同包装版本视觉类别可能相同库存系统里却是不同条码。我一般会在这一层加一个映射表和一个校验规则SKU_MAP { 0: {name: 可乐-330ml-易拉罐, sku: 6901234567890, price: 3.5}, 1: {name: 纯牛奶-250ml-利乐包, sku: 6901234567891, price: 5.0}, 2: {name: 袋装薯片-原味, sku: 6901234567892, price: 6.5}, } def convert_detection_to_cart(detections): cart {} for det in detections: sku SKU_MAP[det.cls][sku] if sku not in cart: cart[sku] {count: 0, price: SKU_MAP[det.cls][price]} cart[sku][count] 1 return cart参数说明convert_detection_to_cart里按 SKU 聚合而不是按类别聚合这样后面跟库存系统交互时直接传条码。count累加的是前面合并后的Detection对象而不是原始帧的检测数量。如果同一 SKU 有多个视觉类别 ID这里还要加一层“类别到 SKU 的多对一映射”用字典或 SQL 表维护不要在代码里写死。3.3 防重复结算与人工确认机制合并帧和多帧投票只能解决重复检测解决不了“用户把商品放上去又拿走”的情况。结算系统需要一个状态机检测到商品放入 - 加入待结算列表 - 用户点击“确认结算” - 生成订单 - 清空当前购物车。在确认之前如果连续 2 秒检测不到该商品的任何框就把它从待结算列表里移除。这个“移除”操作要谨慎建议给它加一个冷却时间防止商品暂时被手挡住导致误删。生成订单时还要关联订单号、时间戳、结算台 ID 和摄像头抓拍的图片路径。图片路径很关键后续如果用户投诉“多扣钱了”可以按订单号找到抓拍图人工核对。我的做法是把每次结算确认前最后一帧完整图片存到按日期分目录的文件夹里文件名带订单号。4. 系统源码结构与前后端通信让 YOLOv8 结果服务化4.1 后端服务拆分检测服务与订单服务必须解耦源码里最常见的分层是“视觉检测服务”和“业务结算服务”分开部署中间通过 REST 或者 gRPC 通信。检测服务只接收图片、返回检测框和类别业务服务负责购物车、订单、库存和支付回调。这样做的原因是两者的更新频率不同模型需要经常重训换权重而业务逻辑要稳定如果耦合在一个进程里每次换模型都要重新部署整个系统风险太大。检测服务用 FastAPI 或 Flask 封装核心接口是app.post(/detect) async def detect(image: UploadFile): img_bytes await image.read() np_arr np.frombuffer(img_bytes, np.uint8) img cv2.imdecode(np_arr, cv2.IMREAD_COLOR) results model.predict(img, conf0.45, iou0.5, verboseFalse) boxes results[0].boxes detections [] for box in boxes: detections.append({ cls: int(box.cls), conf: round(float(box.conf), 3), bbox: [round(v, 1) for v in box.xyxy[0].tolist()] }) return {code: 0, detections: detections}说明conf0.45是置信度阈值低于这个值的框会被过滤。业务场景里这个值不能拍脑袋定要在验证集上画一次 precision-recall 曲线找到误检和漏检的平衡点。iou0.5是 NMS 的 IoU 阈值值越大保留的重叠框越多商品密集堆叠时建议降到 0.4减少两个重叠商品被合并成一个框的概率。4.2 结算服务的关键接口设计接口方法入参说明/cart/currentGET无获取当前待结算商品列表/cart/addPOSTsku, count, image_id加入购物车image_id 用于追溯/cart/removePOSTsku, count移除商品需记录原因/order/confirmPOSTcart_token确认结算生成订单/order/historyGETdate, page查询历史订单和抓拍图/cart/add和/cart/remove必须带上一个cart_token来标识当前结算会话防止多台设备同时操作同一结算台造成数据错乱。image_id是检测服务里的抓拍图文件名前端上传图片时可以由前端生成 UUID 并回传也可以由检测服务返回。4.3 本地跑通整套源码的三条命令拿到这套源码先别急着看训练代码按下面的步骤把服务跑起来# 1. 创建虚拟环境并安装依赖 python -m venv venv source venv/bin/activate pip install -r requirements.txt # 2. 启动检测服务默认端口 8001 python detector_server.py --host 0.0.0.0 --port 8001 # 3. 启动结算服务默认端口 8002 python settlement_server.py --config configs/settlement.yamlrequirements.txt里通常会锁住 ultralytics、fastapi、uvicorn、opencv-python、pydantic 这几个核心包版本。settlement.yaml里配置的是 Redis 连接地址、MySQL 数据库连接字符串、抓拍图存储路径和 SKU 映射表路径。启动顺序必须是检测服务先起结算服务启动时会做一次健康检查请求检测服务的/health接口确认模型加载成功如果检测服务没起来结算服务会直接报错退出。5. 参数校准与排错让系统在真实场景里稳定运行5.1 用损失函数曲线判断训练是否真正收敛训练完不能只看 mAP还要看 loss 曲线。YOLOv8 训练过程会自动输出results.png包含 box_loss、cls_loss、dfl_loss 三条曲线。判断标准不是“loss 降到零”而是“训练集 loss 下降、验证集 loss 不再上升”。如果验证集 cls_loss 在训练后期反弹说明类别过拟合了常见原因是某个类别样本太多而其他类别太少。这时不要加数据增强而是做类别平衡采样把样本多的类别降采样、样本少的类别过采样。画曲线也可以自己导出每轮的损失值yolo train ... --project runs/train --name settlement_v1 tensorboard --logdir runs/train/settlement_v1--project和--name指定输出目录TensorBoard 读取的是训练过程中自动保存的events.out.tfevents.*文件。看曲线时重点关注前 50 轮如果 box_loss 在前 50 轮没有明显下降往往是学习率设置过大导致震荡如果下降但 mAP 不升大概率是 NMS 参数或置信度阈值和训练分布不匹配跟模型本身无关。5.2 部署环境的算力边界1660Ti 与 RK3588 的取舍GTX 1660Ti 跑 yolov8s 640 分辨率大约是 25 到 30 毫秒一帧完全够用。RK3588 这类边缘设备不能直接跑原版 PyTorch 模型需要先导出为 ONNX 再用 RKNN-Toolkit 转成 rknn 格式。转换时要注意三点第一opset版本要选择 12 或更高否则部分算子不支持第二RK3588 的 NPU 对某些激活函数支持不完整如果转完精度掉得厉害把模型里的 SiLU 换成 ReLU 重训一次是常见做法第三int8 量化会掉 1 到 2 个点的 mAP但是推理速度提升明显结算场景优先保证 recall如果掉的是小目标类别的 recall就不要用 int8用 fp16。设备端的部署代码需要把预处理resize、归一化也写进去常见错误是训练时用 640x640部署时输入的是 1920x1080 整图导致检测目标变小一截。正确做法是保持与训练一致先 resize 到 640x640或者用 640x640 的滑动窗口在 1920x1080 上滑动多余部分填充 128。5.3 常见误检、漏检的快速定位方法一个非常有效的手段是把识别结果画在图上保存下来每 10 帧留一帧。看画帧的时候按这些顺序排查框是否跟随商品移动还是停在背景上背景误检需要负样本。同一种商品在不同光照下是否都识别得出光照不足补光或加光照增强。两个相邻商品是否常被识别成一个框NMS 阈值问题调低 iou 到 0.4。识别结果在结算台上偶尔消失一两帧遮挡问题多帧投票会解决不用改模型。这个阶段可以准备一份“硬样本集”把每天线上跑出来置信度在 0.5 到 0.7 之间的检测结果单独存下来定期人工标注并加进训练集。这比反复调训练参数有效得多尤其适合结算台这种相机位置固定、背景变化小的场景。提示改 NMS 阈值、置信度阈值这类参数时每次只改一个并且用同一组验证集图片做对比不要同时调整多个参数否则出了问题根本定位不了是哪个引起的。6. 进阶验证用 shadow mode 评估新模型再替换模型训练好了参数也调好了直接替换线上旧模型是要担风险的。我把这个方法叫“影子模式”新模型和旧模型同时在跑但新模型的结算结果只记录不生效累计收集 1000 个真实结算场景后对比两个模型的检测结果差异再决定要不要切换。具体做法是在detector_server.py里加一个转发开关检测结果同时打到旧模型和新模型写入对比表CREATE TABLE model_compare ( id INT AUTO_INCREMENT PRIMARY KEY, order_id VARCHAR(32), old_sku_list TEXT, new_sku_list TEXT, old_conf_avg FLOAT, new_conf_avg FLOAT, status ENUM(same, differ), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );线上运行一周后执行查询找出status differ的订单按类别聚合差异频次。如果某一个类别总是新模型识别成不同的 SKU检查该类别在新训练集里的样本分布优先补充这个类别的现场照片。这种验证方式胜在真实场景覆盖率高远比拿验证集图片跑一波 mAP 要可信。最后还有一个值得花半小时做的小技巧把结算系统的检测置信度阈值做成动态的。具体到商品类别层面容易互相混淆的类别比如不同口味的同一品牌饮料用较高的阈值 0.5形状差异大的类别易拉罐和盒装牛奶用较低的阈值 0.3。训练时在验证集上给每个类别算一个最佳阈值启动服务时读取这些阈值配置不要全局用一个值。这一步不需要重新训练模型只改推理参数但通常能减少 2% 到 3% 的误结算率。结算系统的收益空间是慢慢磨出来的视觉部分做到 95% 很高但剩下 5% 的误差就是靠这类细节一点一点压下来的。本文还有配套的精品资源点击获取