做目标检测的，大概没人绕得过YOLO。从2016年YOLOv1那篇单阶段检测论文横空出世，到如今YOLOv11、YOLO-NAS这些衍生版本铺满GitHub，YOLO已经不再是一个具体模型的名字，而是一个庞大且还在持续扩张的技术家族。这篇文章想做一个真正意义上的“历代版本全面总结”：把v1到v11、包括衍生系的来龙去脉，每个版本的核心改动、损失函数与网络结构的演进逻辑、以及工程部署里你八成会踩的坑，一次性理清楚。适合刚开始入门目标检测的初学者，也适合那种已经用YOLO跑过项目、却没系统梳理过版本脉络的工程人。

1. YOLO历代版本图谱：从v1到v11的演进全览

1.1 一张速查表看懂全系版本

网上关于YOLO版本的帖子很多，但大部分要么只讲某一代，要么就是简单的“新版本精度更高、速度更快”一句话带过。我习惯先把整个家族摊开看，再去理解每个版本为什么存在。

下表是我自己整理的速查表，按发布时间排序。注意，v5和v8是Ultralytics团队维护的PyTorch实现，v9、v10是另外两个独立团队做的，v11又回到Ultralytics手里。这一点很多人会搞混，后面我会专门解释。

我特别要提醒一点：YOLOv5、v8、YOLO11都是Ultralytics的“产品线”，但YOLOv9、v10不是Ultralytics官方版本，所以你在Ultralytics仓库里找不到这两个。它们之间不是简单的“升级”关系，而是思路不同的分支。把这一点先立住，后面看代码和模型的时候就不会被误导。

1.2 演进的核心主线：从“快”到“准+快+全能”

YOLO这个词最初让人记住是因为“快”，但十几年下来，整个系列的演进其实有三条主线在同时推进。

第一条是精度。从v1在小目标上的拉胯，到v3用特征金字塔做多尺度检测，再到v8的Anchor-Free和解耦头，每一代都在解决同一个老问题：目标越小、重叠越多、背景越杂，之前的方案就越扛不住。第二条是速度。你去看v6、v7、v10这些版本，几乎每个都在强调“同精度下推得更快”，因为真实项目里，模型精度高但速度跟不上，根本落不了地。第三条是表达能力。从只能出检测框，到v8开始做实例分割、姿态估计、旋转框检测，YOLO从一个检测器变成了一个多任务框架。

这三条线交织在一起，你会发现一个规律：每代YOLO都不只是“参数调优”，而是在网络结构、标签分配、损失函数、后处理这四个层面里至少动一个手术。理解了这一点，版本之间的差异就很容易串起来。

1.3 意外走红的衍生家族：Ultralytics的生态效应

聊YOLO版本，绕不开Ultralytics。严格来说，YOLOv5在当时并没有像v1到v4那样发表正式论文，它是基于PyTorch重写的、工程化极强的实现。但正是这个“没有论文”的版本，因为安装简单、文档齐全、预训练权重好拿，成了绝大多数人第一次跑通目标检测的入口。

Ultralytics做的第二件大事，是推出了all-in-one的训练推理工具链。我印象最深的是它的CLI，一行命令就能训练、验证、导出，还顺手把ONNX、TensorRT、OpenVINO这些导出格式全包了。YOLOv8和YOLO11继承了这条路，所以现在你做项目，从下载代码到部署到生产环境，可能一小时都不需要。这种生态效应，比单纯的一个模型版本重要得多。很多初学者在v8和YOLO11之间纠结，我通常的建议是：如果不是为了刷论文指标，直接用生态最成熟的那个。

2. 历代版本深度拆解：每个版本的核心改动与实战定位

2.1 YOLOv1到v3：奠基时代的三个关键转折

YOLOv1的思路在当时非常反直觉：把整张图切成S×S的网格，每个网格负责预测固定数量的边界框和类别概率，一步到位，不搞两阶段的区域提议。这带来一个巨大的好处——端到端训练，45帧每秒的速度让当时所有两阶段检测器汗颜。但它的问题也很明显：每个网格只能预测两个框，小目标和密集场景几乎报废，定位精度也不如Faster R-CNN。

YOLOv2的关键词是“锚框”。它借鉴了Faster R-CNN的Anchor概念，但用K-Means在训练集上聚类出更合适的先验框尺寸。这就好比原来每个网格只能猜两个固定大小的框，现在变成了一组更贴合数据分布的“模板”，你在这个基础上去微调坐标，难度大大降低。v2还做了批量归一化、更高分辨率输入、多尺度训练这些前期操作，精度从mAP 63.4直接跳到78.6。现在再看这些改动，都是标配，但在2017年，每一招都算突破。

YOLOv3是奠基时代的高潮。它引入了Darknet-53作为backbone，并借鉴FPN构建了三个不同尺度的预测层，分别在32倍、16倍、8倍下采样特征图上做预测，小目标检测能力终于有了质变。而且它把分类损失从Softmax换成了独立的二分类逻辑，支持多标签输出，一个框里既能是“人”也能是“女人”，这对重叠场景非常友好。我在实际项目中，曾经把一个跑了两年的老模型从v3迁移到v8，迁移后最直观的感受就是误检率明显下降，尤其是小目标那一档。

2.2 YOLOv4和v5：工程化与生态的分水岭

YOLOv4在学术上对应的是一大堆“免费午餐”和“特供餐”技巧的组合。backbone换成了CSPDarknet53，颈部网络加了SPP和PANet，激活函数用Mish，损失函数引入CIoU，数据增强上Mosaic算是它的招牌。CiOU直到今天还是主流损失函数的底子之一，它同时考虑了重叠面积、中心点距离和长宽比，比之前的IoU系损失更接近真实定位目标。你可以这样理解：v4做的不是某个单一结构创新，而是告诉你“把这些成熟组件按正确顺序拼起来，就能同时拿捏精度和速度”。

YOLOv5的价值完全不在论文，而在工程体验。虽然一开始有些人质疑它“没论文，算不算正统YOLO”，但它的PyTorch生态、模型缩放系数（n/s/m/l/x）、自动锚框、超参数进化、烘焙后的FP16推理，几乎是手把手教你怎么把开源模型变成能用的产品。我一直觉得，v5对行业最大的贡献是拉低了目标检测的使用门槛——以前要配置一堆C++依赖才能跑的检测器，现在pycharm里pip install一下就能跑。我自己在公司里带实习生入门，第一课永远是v5或v8，而不是v3。

2.3 YOLOv6到v8：工业落地最凶猛的三年

2022到2023年，YOLO的竞争进入白热化。YOLOv6是美团开源的，核心是Anchor-Free化和RepVGG结构，部署时可以把多分支结构重参数化为单路卷积，推理速度非常优秀。它的定位很明确：服务工业场景，所以对TensorRT部署的支持做得很好。我在一台老旧的GPU机器上跑过v6-s，速度确实比同尺寸的v5快一截，代价是调参生态相对Ultralytics差一些。

YOLOv7是v4原班人马的作品，它最有代表性的改动是E-ELAN结构，通过跨层聚合来提升梯度路径，以及引入辅助训练头、用额外的监督信号让主头学到更多。当时它宣称在相同推理速度下精度超过之前所有YOLO，我实测下来确实不虚，但它的Python生态比较原始，很多优化细节需要自己动手。

YOLOv8则回到Ultralytics体系，全面转向Anchor-Free，设计了解耦分类/回归头，并用TaskAlignedAssigner做正负样本分配。它的杀手锏不只是检测，而是同一套架构直接支持实例分割、姿态估计、分类、OBB旋转框检测。做智慧城市、工业质检、行为识别的团队，几乎可以一个框架全包。我在实际项目中测过v8-seg，在同样数据集上，相比老的Mask R-CNN，训练时间和推理时间都大幅下降，精度差距很小，这对要迭代模型的工程团队来说太关键了。

2.4 YOLOv9、v10与YOLO11：新架构与新赛道的探索

YOLOv9和v10是两条很有意思的技术路线。v9主要解决的是信息瓶颈问题——它在研究中发现，深度网络中前向传播会丢失大量信息，于是提出了可编程梯度信息PGI，保证梯度在不同层之间传递时不会衰减；配合GELAN轻量结构，它在中等算力上取得了非常高性价比的检测效果。YOLOv10则是清华团队搞的，最大的卖点是去掉了NMS后处理，通过双标签分配和一致的匹配度量，实现真正的端到端检测。少了NMS，推理管线干净不少，部署到边缘设备上省掉一个依赖，这也是很多热词里“yolo 26 onnx c++”这类需求出现的原因。

YOLO11又回到Ultralytics手里，它在v8的基础上优化了C3k2、C2PSA这些模块，主干和颈部做了轻量化改造。实测下来，YOLO11n在CPU上的推理速度比v8n快一截，精度也略有提升，很适合边缘设备。不过要注意，YOLO11刚出来时，一些老代码的兼容性需要升级到新版本Ultralytics，所以我个人在生产环境里反而更倾向保守选择v8。

3. 核心技术点拆解：损失函数、网络结构与任务能力

3.1 损失函数：YOLO系列如何一步步“调教”出准确框

很多人在“YOLO损失函数”这个热词上搜来搜去，其实就是想搞明白为什么YOLO能同时预测框、置信度和类别。我简单梳理一下历代损失函数的变化，你会发现规律很清晰。

YOLOv1的损失是三个部分的加权和：坐标误差、置信度误差、分类误差，全部用平方误差。它的问题也很明显——大框和小框的误差量级不同，直接回归宽高容易被大目标主导。v2引入了logistic回归做objectness，v3则把分类改成多标签二分类交叉熵，允许一个框输出多个类别。真正大的变化在v4：框回归损失从IoU系升级到CIoU，把重叠度、中心点距离、宽高比全部塞进损失函数。YOLOv5沿用了CIoU/GIoU的路线，但在代码里把分类、置信度、框回归三部分做成可配置权重。

到了v8，损失设计更复杂了。分类用的是BCEWithLogitsLoss，框回归在CIoU基础上加了DFL分布焦点损失——它不直接回归框的坐标值，而是预测坐标的概率分布，再取期望值。这种方式对边界模糊的目标更鲁棒，尤其在遮挡场景下效果提升明显。YOLOv10还引入了Focaler-IoU这类改进，核心思路都是让损失更关注难样本。给初学者的建议：不要一开始就去改损失函数权重，先保持默认，等你的数据集确实出现“小目标漏检率偏高”且其他手段都试过之后，再考虑调整。

3.2 网络结构：从Darknet到CSP、C2f、ELAN的骨架进化

YOLO的网络结构演进，本质上是在回答一个问题：如何在加深网络的同时，不丢失信息、不增加太多算力。

v1和v2用自研的Darknet系列，结构简单但有效。v3引入了残差结构和FPN，是第一个真正意义上“带金字塔结构”的YOLO。v4用了CSPDarknet53，CSP的设计初衷是把特征图在通道维度切成两部分，一部分直接连到下一层，另一部分走卷积计算，这样既减少了重复梯度计算，又保持梯度传播能力。v5继承了CSP，在工程上做了很多模块化调整，比如Focus层把输入图切片后拼通道数，相当于早期的下采样策略。

v8把CSP换成C2f，这个模块在CSP基础上增加了更多的跨层分支连接，让信息在浅层和深层之间交互更充分，同时参数效率更高。v9的GELAN是对ELAN结构的轻量化扩展，v7的E-ELAN则强调跨层聚合。YOLO11里的C3k2和C2PSA，其实是对C2f做进一步裁剪和有选择地引入位置注意力。这一路看下来，你就能理解一件事：每次结构改动都是在精度和FLOPs之间找平衡，没有谁绝对领先，只有“适不适合你的算力”。

3.3 实例分割与热力图：YOLO能力边界的扩展

“YOLO实例分割”是目前搜索热度很高的方向，因为很多项目已经把需求从“框住目标”升级到“抠出目标轮廓”。YOLOv8-seg和YOLO11-seg的思路是重参数化掩码分支：模型除了输出检测框，还会输出一组原型掩码和对应的掩码系数，两者相乘再经过上采样，就得到每个实例的像素级分割结果。

这种设计比Mask R-CNN简单很多，不需要独立的ROI分支，所以训练和推理都快。我用YOLOv8-seg做过一个统计苗木数量的项目，两千多张无人机图，一张图里有上百棵重叠的树冠，v8-seg能稳定分割出大部分轮廓，比之前用语义分割加连通域分析的传统方案省事太多。注意，分割分支会占用额外显存，实际部署时如果只想要框，就别加载seg模型。

热力图也是很多人问的。用YOLO生成热力图，本质是Grad-CAM类方法：把输入图片过一遍网络，hook住最后一层卷积特征，对类别得分求关于特征图的梯度，然后做全局平均池化得到权重，加权求和再归一化，叠加到原图上。Ultralytics没有内置热力图接口，但你可以用pytorch-grad-cam，强制归一化输入尺寸后，把backbone作为目标层，很快就能出图。它最大的用途是排查模型为什么误检——如果热力图只看了一小片区域，说明模型没学到完整目标特征，数据或标注有问题。

4. 工程化落地与实操：从PyCharm到AGX Orin

4.1 PyCharm里快速跑通YOLO的完整流程

这一节照顾一下刚入门的朋友。“使用pycharm安装并使用yolo”是搜索热词，其实流程非常标准化，照下面做不会错。

第一步，创建虚拟环境。我推荐在PyCharm里用conda新建环境，Python 3.8到3.11之间随便选，版本太新可能有些依赖还没适配。第二步，安装依赖。打开Terminal，输入：

pip install ultralytics

如果网速拉胯可以用国内镜像，实测把源切到清华或阿里以后速度提升明显。第三步，写一个最简单的推理脚本：

from ultralytics import YOLO model = YOLO("yolov8n.pt") results = model("bus.jpg", save=True)

第一次运行会自动下载权重，网不好的话建议手动去GitHub Release页面把pt文件下载到项目目录。第四步，跑一个训练流程验证环境。在项目里建一个data.yaml，指向自己的标注数据集，然后：

yolo detect train data=data.yaml model=yolov8n.pt epochs=30 imgsz=640

等它跑完几个epoch，说明环境没问题，后面的事都好说。这里有个常见坑：如果你用的是Apple Silicon，PyTorch的MPS后端不一定支持所有算子，训练时可能报错，建议直接用CPU或CUDA。

4.2 导出ONNX并用C++部署：脱离Python也能跑

“yolo 26 onnx c++”这个热词说明很多人想把YOLO模型从Python环境搬到C++生产环境。这个流程我走通过很多次，核心就三步。

第一步，导出ONNX。Ultralytics封装的导出命令是：

yolo export model=best.pt format=onnx dynamic=True simplify=True opset=12

建议打开dynamic，让输入维度不固定，后面C++端推理时方便处理不同尺寸的图片。simplify会做图优化，opset版本根据你的onnxruntime版本定，太新太旧都可能出问题，我用opset12最多。导出成功后，用onnxruntime的Python接口先跑一遍，确认输出shape和预处理方式，这一步能帮你省掉大量C++联调时间。

第二步，C++端加载模型。用onnxruntime的C++ API，核心代码逻辑大概是：

Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "yolo"); Ort::SessionOptions opts; opts.SetIntraOpNumThreads(4); Ort::Session session(env, model_path, opts); // 预处理：letterbox + BGR转RGB + 归一化 cv::Mat blob = letterbox(input, 640); // 推理：把blob的尺寸和模型输入节点对齐 auto outputs = session.Run(...);

第三步，写后处理。这一步最容易被忽视。Python端自动做了NMS和解码，C++端全要自己写。你要把模型输出的1×8400×85这种张量拆开：前4个值是坐标（以640尺寸为准），中间是类别置信度，最后是各类别概率。先做置信度过滤，再做NMS，最后把坐标从640尺寸还原到原图尺寸，注意letterbox时padding的比例和偏移。

我踩过一个大坑：Python端推理和C++端推理结果不一致，查了很久发现是图像预处理时RGB和BGR顺序没对齐。PyTorch加载图片是RGB，OpenCV默认是BGR，不改这个顺序，模型精度直接崩掉。所有预处理步骤必须和训练时完全一致，这就是“能跑”和“跑得对”的区别。

4.3 嵌入式平台实战：在AGX Orin上搭建YOLO环境

AGX Orin是边缘计算里很流行的高算力设备，搜“在agx orin上搭建yolo环境”的越来越多，基本都是为了做车载或机器人视觉。这套流程说复杂也复杂，说简单也简单，关键在版本匹配。

拿到一台刷好JetPack的Orin后，第一步确认系统版本和CUDA版本：

sudo apt list --installed | grep nvidia-jetpack nvcc -V

JetPack 5.x对应CUDA 11.4左右，JetPack 6.x对应CUDA 12.x，不同版本对应的PyTorch wheel完全不一样。第二步，安装PyTorch。建议直接去NVIDIA官网下载JetPack对应的PyTorch轮子，不要用pip默认源里的版本，因为默认版本往往不带CUDA支持，装完等于白装。第三步，安装Ultralytics：

pip install ultralytics

如果设备上已经装了onnx、onnxruntime等依赖，建议先升级到最新版本，否则容易在导出时碰到算子不兼容的报错。第四步，建议把模型导出为TensorRT的engine格式，在Orin上能榨干GPU性能：

yolo export model=yolov8n.pt format=engine device=0

我实测在Orin上，同一模型从ONNX Runtime切到TensorRT，帧率能提升两倍以上。还有一个经验：Orin的显存是共享内存，跑长时间推理时，记得定时用nvidia-smi看显存占用，确认没有累积式上涨。

4.4 一键部署脚本的思路：把环境搭建变成一条命令

“一键部署脚本yolo最新版本更新内容”这个词很有意思，说明大家不只想跑通，还想让部署可复制。我自己的做法是写一个bash脚本，把环境搭建的每一步都固化成命令，新机器上一条命令拉起来。

脚本大致包含五个阶段：系统检查，确认Python版本和GPU驱动；安装conda并创建虚拟环境；pip安装依赖并指定镜像源；下载模型权重并校验完整性；跑一次冒烟测试，推理一张图看输出是否正常。核心逻辑是：

#!/bin/bash set -e check_python && create_conda_env && install_deps && download_weights && smoke_test

每个函数里都加了异常捕获，某一步失败就打印明确错误信息并退出。这样做的好处是，团队里的人不用再看十几页部署文档，每个人都用同一套环境，那些“在我电脑上能跑”的矛盾直接消失。

写脚本时注意一个细节：最好不要把pip install直接写成固定版本，而是用一个requirements.txt，把Ultralytics和onnxruntime等核心依赖锁定版本。因为YOLO更新很快，隔几个月API就变，一旦安装的是最新版，很多旧脚本可能跑不动。

5. 版本选型建议：不同场景到底该用哪个YOLO

5.1 场景化选型速查表

用了这么多版本，我最大的感受是：没有“最好”的YOLO，只有“最合适”的YOLO。下面这张表直接按照场景给结论，都是我自己或团队实测验证过的思路。

5.2 新手入门推荐路线：先别研究版本，先把流程跑通

如果你是第一次接触YOLO，我不建议一上来就从v1开始读论文。更好的路径是：先装好Ultralytics，用v8n跑通训练和推理，理解一个检测项目的完整流程——数据标注、数据配置、训练、评估、导出模型。等你跑通一遍，回头再看v1到v3的论文，很多当初看不懂的名词就自然明白了，因为你知道在哪个环节会用到锚框、NMS、置信度阈值。

为什么推荐v8而不是最新版YOLO11？不是因为YOLO11不好，而是v8的教程、社区问答、第三方工具链最全。很多在线教程和课程至今还以v8为主，你遇到问题时，搜到的解决方案最多。YOLO11更适合你已经有一套成熟流程，想单纯提升速度和精度时再去切换。

5.3 高性能与边缘场景的取舍：算力决定模型复杂度

选型时最核心的决策变量是算力。同样一个目标检测项目，在有RTX 4090的开发机和在Orin NX的边缘盒子上，最优解完全不同。在高端GPU上，我会直接选v8x或v9c，用大模型换精度，训练时还可以把输入尺寸拉到1280，小目标检测效果明显更好。在边缘设备上，我会用v8n或YOLO11n，再把模型导出成TensorRT engine或OpenVINO IR，输入尺寸压到416或480。

还有一个容易被忽略的点：数据规模。小模型在大数据集上未必比大模型差多少，但在几百张图的小数据上，大模型很容易过拟合。我做肺结节检测这类医疗项目时，标注数据通常不多，这时候优先用v8n，配合强数据增强，比一上来就调v8x要靠谱得多。模型不是越大越好，是“刚好够用”最好。

6. 常见问题与排查技巧实录

6.1 YOLO长时间运行后内存为什么会涨

这个热词出现频率很高，说明很多人部署到服务器或盒子上之后遇到了内存泄漏困惑。先分清是“显存”还是“内存”。用nvidia-smi看显存，用ps aux或htop看内存。YOLO长时间运行时内存上涨，绝大部分原因不在模型本身，而在推理循环的写法。

最常见的坑是：在循环里反复创建YOLO类实例或者反复调用model.to(device)，每调用一次就分配一次新内存而旧对象没有被释放。正确做法是在循环外只初始化一次模型，循环内只做前向推理。第二个常见问题是PyTorch的缓存机制：GPU显存不会立刻还给系统，这是正常的，不代表泄漏。你要观察的是“峰值是否持续上涨”，而不是“显存是否一直占用”。第三个问题是数据集加载器线程：num_workers设置过大且没有正确关闭，会导致系统内存缓慢上涨。

排查思路是从简到繁：先注销推理循环里的重复初始化；再在每次推理后调用：

torch.cuda.empty_cache()

然后观察；如果还是涨，再用tracemalloc或memory_profiler定位是哪一行分配了内存。我接过不少“内存泄漏”的工单，最后发现都是把数据集读进list、循环里不断append结果导致的，跟模型关系不大。

6.2 模型精度上不去的常见原因

训练时mAP一直上不去，大概率不是模型架构问题，而是数据或训练配置问题。第一个要查的是标注质量。YOLO格式的标签框如果画得太松或太紧，模型会学出一个“平均值”，精度天花板就被锁死了。我在项目中用脚本统计过标注框的面积分布，发现很多框只有几个像素，这种标签本来就没法学习。第二个是学习率。YOLO的默认学习率是给COCO这种大数据集调的，你的私人数据集小，建议把lr0调到0.001甚至更低，否则前几个epoch就会震荡。

第三个是类别不平衡。如果某类目标极少，模型会为了压低总损失而把所有目标都预测成大类。可以在loss里调高少数类权重，或者对少数类的样本做在线增强。第四个是锚框。如果你用的是v5/v8这类带自动锚框的版本，可以打开auto_anchor，它会根据你的数据重新聚类anchor尺寸，但要注意训练集和验证集应来自同一分布，否则锚框优化没有意义。

我在“学生专注度检测YOLOv8”这类项目里踩过一个坑：一开始数据里大量图片是人脸特写，少量图片是远距离全身，导致模型对近距离框很准、远距离框几乎没有。后来按目标尺寸分布重新做了数据分层，训练才正常。这就是典型的“先看数据分布，再怪模型精度”。

6.3 推理速度慢的排查清单

推理慢这个问题，80%出现在预处理和后处理，而不是模型本身。我列一个排查清单，按这个顺序查基本不会漏。

第一，有没有用GPU推理？很多人加载模型后忘了指定device='cuda:0'，模型跑在CPU上，慢是必然的。第二，推理输入尺寸是否合理？用imgsz=640和imgsz=1280在同一GPU上，耗时差三倍以上，很多场景480或416就够了。第三，有没有开半精度？把模型转成FP16，在results = model(..., half=True)或者导出engine时开启FP16，显存占用和速度都有改善。第四，有没有遗漏自定义后处理？如果你在Python里自定义了一个双层循环做NMS，换成向量化实现或直接调用onnxruntime的NMS，速度能提升一到两个数量级。最后，检查一下模型是否被多次包装，比如有些人习惯在代码里手动加载pt再封装一层class，每层封装都可能引入额外计算。

6.4 部署时遇到的环境/依赖问题速查

部署到新机器时，环境问题比模型问题多得多。我整理了一个速查表，是按真实报错场景总结的。

这里我再补充一条经验：部署时永远不要“裸装”，把环境写进Docker或conda导出yaml文件才是长久之计。Ultralytics现在也提供官方镜像，直接用docker pull ultralytics/ultralytics能省掉很多折腾。

最后说点个人体会。我用了这么多年YOLO，踩过最大的坑不是模型精度不够，而是版本之间的API变化比模型换代还频繁。今天写好的训练脚本，三个月后可能就因为某个参数改名跑不动了。所以我现在的习惯是：但凡用于生产的代码，一定锁定依赖版本，并把模型导出成ONNX或TensorRT格式后再上线，绝不让线上服务直接依赖某个训练框架的API。这套思路帮我避开了很多次“线上服务突然挂了”的尴尬。如果你想深入研究YOLO，也不用急着把所有版本的源码都啃一遍，把v3、v5、v8这三代的代码吃透，再去看其他版本，基本都是举一反三的事。