基于YOLOv11的棉花叶片病害检测系统实战：从数据准备到UI部署

棉花叶片的病害检测，是典型的"看着简单、做起来处处是坑"的计算机视觉落地任务。我最近把一套基于深度学习YOLOv11的棉花叶片病害检测系统从数据准备、模型训练一路做到UI界面打包上线——包括登录注册、检测页面和后台推理引擎，全部用Python完成。这篇文章把我踩过的坑、试过的参数、最终采用的方案完整记录下来，给同样在做YOLO类目标检测应用的朋友一份可以直接参照的实操清单。

这套系统的核心用一句话概括：把YOLOv11模型封装成一个带登录注册界面的本地检测应用，用户上传棉花叶片照片，系统返回每片叶子上的病害类型、置信度和坐标位置，同时把检测记录存进数据库。它适合作为课程设计或比赛项目来快速落地，也可以作为农业信息化场景下的辅助诊断工具原型。如果你已经训练过一些YOLO模型，但对"怎么把模型做成一个像样的系统"还比较模糊，这篇文章应该能帮你把最后一段路走通。

1. 棉花叶片病害检测的难点，决定了模型选型的方向

1.1 病害场景里三个最容易翻车的现实问题

棉花叶片病害和其他目标检测任务最大的不同，是对象本身极其"小"和"像"。以常见的角斑病为例，早期病斑的直径可能只有几毫米，在一张640像素宽的照片里，占不到全图面积的1%。如果模型训练时对这类小目标的特征学习不够，跑出来的结果基本就是漏检。更麻烦的是，炭疽病和叶锈病在早期形态上高度相似，都是边缘不规则的褐色斑点，人眼都需要凑近了看，模型要区分它们，对训练样本的数量和标注质量要求很高。

再加上田间拍摄时叶片互相遮挡、光照忽强忽弱，背景里的土壤和杂草也会带来大量干扰。这些都是病斑很小、类别相似、背景复杂之外，实际部署时绕不开的变量。这里多说一句：很多初学者在公开数据集上跑测试集，指标很好看，一到真实照片就翻车，原因就是测试集和真实场景分布不一致。棉花叶片数据尤其如此，实验室拍的叶片和田间拍的叶片，纹理、光反射、背景完全不是一个套路。所以我做这套系统的时候，宁可花时间在数据整理上，也不急着调模型结构。

1.2 为什么是YOLOv11而不是YOLOv8或更早版本

YOLOv11是现在官方工具链里的默认系列。相比YOLOv8，它在主干网络里引入了C3k2模块，特征提取时的计算效率更高；另外加入了C2PSA注意力结构，对空间特征的关注更强。这恰恰是病害检测需要的：病斑在叶片上的位置信息很关键，注意力机制能帮模型把计算资源集中在真正有病变的区域上。就我个人体感而言，在同样的数据集上，YOLOv11 m模型的权重比YOLOv8 m略小，但mAP50-95普遍能高1到2个百分点，训练时间反而短一些。

当然，选YOLOv11还有一个非常实际的原因：生态成熟。数据格式、预训练权重、导出ONNX/TensorRT的链路、以及配套的文档，都是现成的。整个系统我可以用一套工具链走到底：标注用通用标注工具，训练用官方库，部署时导出成ONNX，再用onnxruntime做推理，每一环都有非常多的资料可以参考，遇到问题不容易卡住。

模型尺寸方面，我最后用的是yolo11m。yolo11n不是不行，训练和推理都快，但对小病斑的召回率会明显差一截；yolo11l精度提升有限，但推理速度下降明显。对于实时性要求不高的本地图片检测场景，m是性价比最好的选择。

2. 数据决定上限：棉花叶片数据集的采集、标注与增强

2.1 数据集来源与类别设计

这套系统最后覆盖了五个类别：健康叶片、角斑病、炭疽病、枯萎病、叶螨危害（红蜘蛛）。选择这几个类别的原因，一是它们在棉区确实高发，二是它们涵盖了"点状病斑、扩散型病斑、全叶变色、虫害附着"几种完全不同的视觉形态，方便测试模型在不同病害特征下的表现。

数据来源我分成了三块：第一块是从公开的图像检索里筛选出来的真实棉田照片，这类照片背景复杂，适合训练模型的抗干扰能力；第二块是室内固定光源下拍摄的叶片特写，这类照片病斑清晰，适合作为小目标的精细样本；第三块是对部分病叶做模拟条件下的旋转、补拍，用来补齐不同成熟度的病斑形态。最终每类有效图片数量在900到1300张之间，总计约5600张原始图片，再通过增强扩展到两万级别。如果你的资源更紧张，每个类别至少也要凑到500张，少于这个数，yolo11m很容易过拟合，测试集指标虚高，实际使用却拉胯。

2.2 标注时最容易踩的坑

标注是整个过程里工作量最大的一环。我用的是带自动分割辅助的标注工具，先把叶片边缘分割出来，再在分割结果上快速加矩形框，速度比纯手工一张张画框快很多。但自动辅助只适合处理健康叶片和病斑边界清晰的情况，遇到两个病斑边界模糊的重叠区域，一定要手动放大图片再画框，绝不能图快。

标注规范直接影响模型上限，有几点必须统一：

• 框要紧贴病斑边缘，宁可稍微留一点余量，也不能把半个病斑切在框外；
• 同一个病斑被叶片卷曲分成两段时，按两个独立目标标，不要用一个框强包；
• 完全模糊失焦的图片直接删除，不要"赌模型能学出来"；
• 标注完成后必须做一轮交叉检查，至少抽查10%的数据，框偏移明显的样本要重新标。

YOLO格式的标签是txt文件，每行对应一个目标，结构是class_id cx cy w h，四个坐标值都归一化到0到1之间。如果你从别的工具导出的是COCO JSON或者VOC XML，需要写脚本转换。转换时注意归一化要除以图片实际宽高，不要把宽高比搞反，这个错误非常隐蔽，训练时loss不降可能就出在这里。

2.3 数据增强：哪些有效，哪些帮倒忙

官方库在训练时会自动做mosaic、随机仿射、HSV颜色扰动等增强。我最终的增强配置是这样的：mosaic 1.0，随机水平翻转0.5，HSV的H、S、V扰动分别设成0.015、0.7、0.4，mixup设到0.1。这套配置对棉花叶片效果很好，尤其是HSV的饱和度扰动，能模拟不同光照下叶片颜色的差异，对抑制野外照片的过拟合帮助很大。

但有一个副作用要注意：mosaic会把四张图拼成一张，如果原图本身比较复杂，拼完之后每个病斑的面积会进一步缩小，小目标更难学。我实测发现，当图像里病斑本来就很小的时候，把mosaic从1.0降到0.5反而能提升小目标召回率。所以看完第一轮训练结果后，如果小目标类别AP偏低，可以先试试降低mosaic概率，而不是急着加大模型。

3. YOLOv11训练与评估：参数调优的思路比堆epochs更重要

3.1 训练环境的组合

我用的是Python 3.11加CUDA加PyTorch 2.x加官方库11.x这套组合。安装官方库的命令很简单：

pip install ultralytics

它会自动带上所需的依赖。如果机器上有NVIDIA显卡，记得先装对应版本的PyTorch，再装官方库，顺序反了容易把CPU版PyTorch装上，训练速度会慢到一个量级。我踩过这个坑，第一轮训练跑了一下午才发现显卡占用是0。

数据集的配置用data.yaml组织，内容大概是：

path: datasets/cotton_leaf train: images/train val: images/val nc: 5 names: ['healthy', 'angular_leaf_spot', 'anthracnose', 'fusarium_wilt', 'spider_mite']

3.2 训练参数的选择逻辑

我最终采用的训练命令：

yolo detect train data=data.yaml model=yolo11m.pt epochs=150 batch=16 imgsz=640 optimizer=SGD lr0=0.01 mosaic=1.0

几个参数的选择逻辑：epochs设到150是因为病害检测的收敛速度比通用目标检测慢，病斑小、类间差异小，需要更长时间把特征磨细；batch=16是显存约束下的选择；imgsz=640是综合考虑训练速度和精度后的值，如果训练时间充裕，试过1024之后小目标AP能再提升3到4个百分点，但推理速度会明显下降。

优化器在SGD和AdamW之间我对比过，差异值得关注：

如果你希望快速看到效果而不是追求极致精度，用AdamW、初始学习率0.001，跑80个epoch也能出可用的模型。

3.3 训练过程监控与结果判读

训练时盯几个指标：box_loss、cls_loss、mAP50、mAP50-95，以及每个类别的AP。loss一直降不代表mAP会一直涨，如果发现训练后段mAP50基本平了，而val loss开始回升，就是在过拟合，这时候提前停止比硬跑完150个epoch更靠谱。官方库自带早停机制，patience设置成20比较合适。

我这套模型训练完的指标大致是：mAP50约93%，mAP50-95约76%。角斑病这类点状病斑的AP最高，叶螨危害这类细碎密集目标的AP最低，只有80%出头，因为它的小目标密度太高，标注框之间相互重叠，模型的召回压力很大。这类问题靠模型本身很难完全解决，更多要靠数据侧多补密集样本。

训练结束后导出ONNX模型：

yolo export model=runs/detect/train/weights/best.pt format=onnx opset=12

导出后建议用onnxruntime跑一遍验证结果和PyTorch推理是否一致，再放进系统。

4. 从模型到系统：登录注册、UI界面与推理引擎的衔接

4.1 系统整体架构

整个系统分三层：界面层、业务层、数据层。界面层用PySide6写，包括登录注册窗口和主检测窗口；业务层包含用户认证、模型推理、检测记录管理三个模块；数据层用SQLite存用户信息和历史检测记录。选择PySide6而不是纯Web方案，是因为本地应用部署简单，不需要搭服务端，而且能用桌面端的资源做本地推理，适合单机工具型产品的定位，也不用担心跨平台的问题。

模型推理这层我单独封装成了一个Detector类，全局只加载一次模型，初始化时加载模型权重，之后所有检测请求都走同一个引擎。加载模型这个动作非常耗时，第一次加载可能要几秒，如果每次点"开始检测"都重新加载，用户体验会非常差。

4.2 登录注册模块的安全细节

登录注册是系统的一个标准入口，但很多演示项目里的登录模块只是把用户名密码明文存下来，这一点很不可取。我用的方案是"密码加盐再哈希"：每个用户在注册时生成一个随机盐值，把密码和盐拼接之后做SHA-256哈希，数据库里存的是盐和哈希值，而不是明文密码。登录时用输入的密码和库里存的盐组装哈希，比对结果。

核心代码结构大概是这样的：

import hashlib import os def hash_password(password: str, salt: str) -> str: return hashlib.sha256((salt + password).encode()).hexdigest() def register_user(username: str, password: str, conn): if username_exists(conn, username): return False, "用户名已存在" salt = os.urandom(16).hex() hashed = hash_password(password, salt) conn.execute( "INSERT INTO users (username, salt, hashed_password) VALUES (?, ?, ?)", (username, salt, hashed) ) return True, "注册成功"

注册时还要做基础校验：用户名长度至少3位、密码至少6位、两次输入一致。登录失败要有次数限制，连续失败5次锁定一段时间，避免被暴力猜测。这些功能代码量不大，但对系统完整性的提升是实打实的。

4.3 检测界面的布局与异步推理

主检测窗口的布局我分了三个区域：左侧是图片选择区和缩略图，中间是检测结果展示区，原图和标注框直接叠加绘制，右侧是结果面板，列出每个检测框的类别、置信度、坐标，以及按类别统计的病害数量。底部是历史记录表格，每次检测完成自动插入一条记录，关联当前登录用户。

推理过程必须放到后台线程。PySide6的QThread是常用做法：界面线程只负责接收点击事件和展示结果，真正跑模型推理的代码放到QThread的run方法里，推理完成通过信号把结果传回主线程。

class InferenceWorker(QThread): finished = Signal(dict) def __init__(self, image_path, detector): super().__init__() self.image_path = image_path self.detector = detector def run(self): results = self.detector.detect(self.image_path) self.finished.emit(results)

如果不做这一步，模型推理耗时一两秒，整个窗口就会"未响应"，这是桌面应用开发者最容易犯的错。

4.4 推理引擎的选型与速度对比

我在系统里实际上准备了两种推理后端，默认用ONNX Runtime，另一个保留PyTorch原始模型作为回退。原因很简单：ONNX Runtime在CPU上的推理速度明显快于PyTorch的eager模式，而且在部署机上不需要装完整的深度学习框架，依赖少很多。用ONNX Runtime时，预处理要把图像从BGR转到RGB、归一化、letterbox缩放，这些步骤和训练时保持一致的顺序非常重要，任何一步不一致都会导致检测精度下降。

实际测试下来，在普通办公电脑的CPU上，一张640x640的图片单次推理大约需要0.35到0.5秒；如果开了GPU，可以直接降到20到40毫秒。

如果是在没有GPU的机器上用摄像头做实时检测，建议把输入分辨率降到416，或者做跳帧检测（每两帧处理一帧），否则帧率会低到没办法用。

5. 实测翻车记录：误检、漏检和界面卡顿的排查过程

5.1 光线变化导致误检：校准输入分布比调阈值更有用

第一次实拍测试，模型在室内白炽灯下表现很好，拿到自然光下一试，健康叶片的误检率突然上升，不少土壤和枯草被标成了病害。我第一反应是调高置信度阈值，从0.25调到0.45，误检确实压下去一些，但小病斑召回率也掉了。后来逐图排查发现，问题不在阈值，在于输入图像的亮度分布和训练集差异太大。

解决办法是在预处理里加了一步自适应亮度校正：把图像从BGR转到HSV，对V通道做CLAHE（限制对比度自适应直方图均衡），再转回BGR。这一步让不同光线下拍的照片亮度分布更接近训练集，误检率立刻降了下来。这个例子说明，在实际系统里，输入端的图像校正往往比反复调阈值有效得多。

5.2 叶片重叠导致漏检：滑窗切图的思路

第二类翻车是自然场景里叶片互相重叠，模型经常只检出最前面那片叶子的病斑，被遮挡区域的病斑直接丢掉。模型训练时虽然做过mosaic增强，但mosaic是"拼接不同图"，不是"模拟真实遮挡"，对这类问题帮助有限。

我最后的方案是对大图做滑窗切块推理：把原图按640x640的窗口、64像素步长滑动切块，每块单独推理，再把所有检测框映射回原图坐标，做一次全局NMS合并。这个方案在整片照片级的大图上效果很好，小目标召回率明显提升，代价是推理时间成倍增加。如果你做的是单张叶片特写检测，不需要这一步；只有检测大范围棉田照片时才值得用。

5.3 界面卡顿与数据库写入阻塞

还有一个容易被忽略的问题：检测完成后把结果写入SQLite，如果直接在推理线程里执行写入，而界面主线程同时又在读历史记录，SQLite会出现"database is locked"的报错。排查出来的原因很直接——SQLite默认对多线程访问不友好。我的处理方案是：每个线程使用自己的数据库连接，写入时用重试等待锁释放，同时把历史记录刷新放到写入完成信号后再执行。改动不大，但界面的稳定性提升很明显。

5.4 摄像头实时检测的帧率瓶颈

如果要把系统从"单张图片检测"升级成"摄像头实时检测"，瓶颈基本都在CPU推理速度上。我的建议是先用跳帧加降低分辨率的方式让功能跑起来，然后在已标注的小规模数据上测试量化后的模型。把ONNX模型做INT8量化，推理速度能再提升2到3倍，但要小心小目标类别在量化后AP明显下降，需要对比量化前后的指标再决定是否启用。

最后再说一个从实操里总结的小心得：这套系统的所有模块，难度都不在单个技术点上，而在于把它们串成一条可靠的数据链路——从登录认证到图片预处理，从模型推理到结果落库，任何一环不一致，最终展示给用户的结果都会看起来正常但经不起细看。如果你也准备做一个类似的目标检测系统，建议先用最简版本把链路跑通，再逐环节做优化，这样排查问题会轻松很多。