YOLOv10【第三章：数据集制作与数据工程篇·第4节】COCO、VOC、YOLO 格式互转脚本实践！

🏆 本文收录于 《YOLOv10实战：从入门到深度优化》 专栏。

该专栏系统复现并深度梳理全网主流 YOLOv10 改进方法与工程实战案例，覆盖分类、目标检测、实例分割、多目标追踪、关键点检测、旋转目标检测等多个方向，坚持 持续更新 + 深度解析 + 工程验证。

专栏将围绕 YOLOv10 的网络结构、训练策略、标签分配、损失函数、数据增强、模型压缩、推理加速与部署落地等内容展开，重点分析 Consistent Dual Assignments（一致性双重标签分配）、NMS-Free End-to-End Detection（无 NMS 端到端检测）、Holistic Efficiency-Accuracy Driven Model Design（整体效率-精度驱动模型设计） 等核心设计思想，并结合实际项目讲解其改进方式与应用价值。

部分章节还会结合国内外前沿论文与 AIGC 大模型技术，对主流改进方案进行重构与再设计，使内容更加贴近真实业务场景，适合希望深入研究 YOLOv10 或具有工程落地需求的开发者学习与参考。

🎯限时特惠：当前活动一折秒杀，一次订阅，终身有效，后续所有更新章节全部免费解锁 👉 传送门 👈️

🎉 本专栏还不够过瘾？别急，好戏才刚刚开始！我已经为你准备了一整套 YOLO 进阶实战大礼包🎁：

👉 《YOLOv8实战》 👉 《YOLOv9实战》 👉 《YOLOv10实战》 👉 《YOLOv11实战》 👉 《YOLOv12实战》 👉 以及最新上线的 《YOLOv26实战》

想一次搞定所有版本？直接冲 《YOLO全栈实战合集》，一站式涵盖 YOLO 各版本实战教学！

🚀 想学哪个版本？直接找 bug 菌“许愿”，安排！必须安排！🚀

🎯 本文定位：计算机视觉 × YOLOv10 数据集制作与数据工程篇 📅 预计阅读时间：约 45～60 分钟 🏷️ 难度等级：⭐⭐⭐☆☆（进阶级） 🔧 技术栈：Python 3.9+ · PyTorch 2.0+ · YOLOv10 · ByteTrack · OpenCV · NumPy

全文目录：

• • 上期回顾
  • 一、写在前面：为什么我们绕不开"格式转换"这件事
  • 二、先把地基打牢:三种格式到底长什么样
  • • 2.1 COCO 格式:一个 JSON 文件统治一切
    • 2.2 VOC 格式:一张图一个 XML,直观但"重复"
    • 2.3 YOLO 格式:为训练效率而生的极简设计
    • 2.4 三种格式横向对比:把差异摆在桌面上
  • 三、坐标系转换的数学本质
  • 四、转换脚本的设计思路:中间表示法 + 整体流程图
  • 五、动手实战:六个可直接运行的转换脚本
  • • 5.0 环境准备
    • 5.1 构造一个迷你 COCO 数据集(用于测试)
    • 5.2 COCO -> YOLO:最常用的一条转换路径
    • 5.3 VOC -> YOLO:类别名要自己"定个规矩"
    • 5.4 YOLO -> VOC:反归一化 + 图片尺寸的"补全"
    • 5.5 YOLO -> COCO:把"分散"重新"聚合"
    • 5.6 可视化校验:永远不要相信"没报错"
  • 六、那些年我们踩过的坑(血泪经验)
  • 七、官方工具与社区方案:不必每次都重新发明轮子
  • 八、工程化落地建议
  • 九、本节小结
  • 十、下期预告
  • 📌 附录
  • 👨‍💻 About Me · 关于作者

上期回顾

在上期《YOLOv10【第三章：数据集制作与数据工程篇·第3节】LabelImg、CVAT、Roboflow 标注工具实战对比！》内容中，我们聊的是标注工具的选择问题，这其实是很多人入门目标检测之后第一个会纠结的"幸福的烦恼"——工具太多了，到底该用哪个？

我们当时把三款工具放在一起做了一次比较扎实的横向对比：

LabelImg 是最"老牌"的选手，界面极简，开箱即用，几乎是每个目标检测教程的标配。它的优势在于轻量、离线、本地运行，不需要联网，不依赖账号体系，对个人开发者和小团队来说几乎是零成本起步。但缺点也很明显——它的功能停留在"画框、写类别名"这个最基础的层面，没有团队协作能力、没有版本管理、没有自动化辅助标注，标注一个上千张图片的数据集，纯手工拉框真的会让人手腕酸到怀疑人生。

CVAT（Computer Vision Annotation Tool）则是工程团队更喜欢的选择，由 Intel 开源并维护，支持 Web 端部署、多人协作、任务分配、标注审核流程，还内置了基于深度学习模型的半自动标注（比如可以接入 Segment Anything 或者其他预训练模型来生成初始标注，标注员只需要做微调）。CVAT 的导出格式非常丰富，支持 COCO、VOC、YOLO、CVAT 自有 XML 等多种格式，这一点其实就是我们这一节的"导火索"——因为 CVAT 导出的格式不一定和你训练框架要求的格式一致，所以转换脚本是绕不开的工程环节。

Roboflow 是这几年崛起很快的一站式平台,从标注、数据增强、格式转换到一键导出训练代码,几乎覆盖了数据工程的全流程,对新手非常友好,而且它本身就内置了几十种格式之间的互转功能。但它的免费额度有限制,数据存储在云端,对于涉密或者企业内部数据,直接用 Roboflow 可能会有合规顾虑,这时候还是得回到"自己掌控数据,自己写转换脚本"这条路上来。

我们当时给出的结论大致是：个人学习和小型项目用 LabelImg 起步成本最低；团队协作、需要标注审核流程的场景上 CVAT；想要快速出活、不在意数据云端化的场景可以试试 Roboflow。但无论用哪个工具，最终落到 YOLOv10 训练上,标签文件都必须是 YOLO 格式的 txt 文件——而很多公开数据集(比如 COCO、Pascal VOC)、很多标注工具默认导出的格式,并不是 YOLO 格式。

这就引出了今天这一节的主题。说实话，这一节我个人觉得是整个数据工程篇里"性价比"最高的一节——掌握了格式互转，你就能把网上几乎所有公开数据集、所有标注工具的产出，无缝接入到 YOLOv10 的训练流程里，而不会被"格式不对"这种小事卡住脖子。好，废话不多说，我们正式开始。

一、写在前面：为什么我们绕不开"格式转换"这件事

先说一个我自己踩过的真实场景。几年前我接手一个项目,客户给了一批历史标注数据,是用某个老旧标注系统导出的 Pascal VOC 格式 XML 文件,几千张图,标注质量还不错。我们这边要用 YOLOv10 重新训练一个检测模型。结果第一反应是什么?直接把 XML 文件丢进训练目录,运行训练脚本——当然是直接报错,因为 YOLOv10(以及整个 YOLO 系列)的训练脚本压根不认识 VOC 的 XML 格式,它只认 .txt 格式的标签文件,而且每一行的数字含义、坐标的归一化方式,都和 VOC 完全不同。

这其实揭示了一个很重要的现实问题：标注格式从来不是"标准统一"的,而是"各自为政"的。每一种格式的诞生,背后都有它自己的历史背景和设计考量:

• COCO 格式诞生于微软的 Common Objects in Context 数据集项目,它的设计目标是支持检测、分割、关键点、看图说话等多种视觉任务,所以它用一个庞大的 JSON 文件把图像信息、标注信息、类别信息全部组织在一起,结构复杂但信息量大。
• VOC 格式来自 Pascal VOC Challenge,历史更悠久,设计理念是"一张图一个 XML",简单直观,早期很多检测框架(比如 Faster R-CNN 的官方实现)都是基于这个格式写的数据读取代码。
• YOLO 格式则是 Joseph Redmon 在设计 YOLO 系列算法时,为了追求极简和训练效率,设计出的一种"一行一个目标、归一化坐标、纯文本"的格式,解析速度极快,几乎没有冗余信息。

这三种格式,你可以理解成是三种不同的"语言"——它们描述的其实是同一件事(一张图里,什么位置有什么物体),但表达方式天差地别。我们做数据工程,本质上就是要在这几种"语言"之间做"翻译"。

那为什么不能让大家都用同一种格式呢?现实就是这么残酷——

所以,格式互转脚本,不是什么"锦上添花"的技巧,而是数据工程师的"基本功"——就像程序员必须会用 git 一样自然。这一节,我们就把这三种格式的底层结构彻底拆开揉碎讲清楚,然后手写出可以直接跑的转换脚本,让你以后拿到任何格式的数据集,都能从容地"翻译"成 YOLOv10 想要的样子。

二、先把地基打牢:三种格式到底长什么样

在写转换脚本之前,我想先花比较大的篇幅,把三种格式的"原生结构"讲透。这一步看起来好像是"绕路",但我的经验是——90% 的格式转换 bug,都源于对原始格式的某个字段理解错了。比如把 COCO 的 category_id 直接当成 YOLO 的 class index 用(这俩压根不是一回事),或者以为 VOC 的坐标是归一化的(其实是绝对像素值)。这些理解上的偏差,如果不在源头解决,后面写多少行代码都白搭。

2.1 COCO 格式:一个 JSON 文件统治一切

COCO 格式的核心是一个(或几个)JSON 文件,里面用几个顶层字段把整个数据集的所有信息组织起来。官方标注文件(以 instances_train2017.json 这类目标检测标注为例)的顶层结构大致包含这几个 key:

• info:数据集的描述信息,比如版本号、年份、贡献者等,对训练本身没有影响。
• licenses:许可证信息,同样不影响训练。
• images:一个列表,每个元素描述一张图片——包含 id(图片的唯一编号)、file_name(文件名)、width、height(图片的宽高,单位是像素)。
• categories:一个列表,每个元素描述一个类别——包含 id(类别编号)、name(类别名称)、supercategory(父类别,可选)。
• annotations:一个列表,每个元素描述一个具体的标注框——包含 id(标注的唯一编号)、image_id(这个标注属于哪张图,对应 images 里的 id)、category_id(这个标注属于哪个类别,对应 categories 里的 id)、bbox(边界框坐标)、area(框的面积)、iscrowd(是否为人群/密集目标的标记,0 表示普通目标,1 表示密集人群区域,通常用 RLE 编码的分割掩码表示)、以及可选的 segmentation(分割多边形或 RLE 掩码,目标检测任务可以没有这个字段,实例分割任务必须有)。

这里有两个非常关键、也是最容易踩坑的点,我必须重点强调一下:

第一,bbox 的格式是 [x_min, y_min, width, height],也就是边界框左上角的坐标 + 框的宽和高,单位是像素的绝对值,不是归一化的 0~1 之间的小数。很多人第一次看到 COCO 的 bbox 数值是几十、几百甚至上千,会以为格式写错了,其实这就是它的设计——绝对像素坐标。

第二,category_id 不一定是从 0 开始连续编号的。这一点在官方 COCO 数据集里体现得特别明显——COCO 数据集一共有 80 个常见物体类别,但是 category_id 的取值范围是 1 到 90(中间跳过了一些编号,因为最初设计的 90 个类别里有一部分后来被移除了,但编号没有重新整理)。如果你直接把 category_id 当作 YOLO 的 class index 用,训练的时候模型输出层的类别数和实际类别编号就会对不上,要么报错,要么(更隐蔽也更危险)训练能跑起来,但类别全部错位——这种"能跑但是错"的 bug 是最难排查的,因为它不会立刻让你看到报错信息,只有等你做推理测试的时候才会发现,“咦,为什么把车检测成了人?”

我设计本节的示例数据集时,特意把 category_id 设成了 1、3、17 这种不连续的编号(就是要模拟真实 COCO 数据集的情况),后面写转换脚本的时候,你会看到我们是怎么处理这个映射关系的。

用一张图来表示 COCO JSON 的整体结构层级,大概是这样的:

相关示意图绘制如下，仅供参考：

可以看到,annotations 列表里的每一项,其实是通过 image_id 和 category_id 两个"外键"分别指向 images 和 categories 列表里的对应项——这是一种典型的"关系型数据库式"的设计思路。理解了这个结构,你就能明白为什么 COCO 格式被称为"信息最完整"的格式:它把图像元信息、类别元信息、标注信息全部解耦存储,但通过 id 关联起来,既灵活又不冗余。

2.2 VOC 格式:一张图一个 XML,直观但"重复"

相比 COCO 的"一个文件管全部",Pascal VOC 格式走的是另一个极端:每一张图片对应一个同名的 XML 标注文件。比如 img_001.jpg 对应的标注文件就是 img_001.xml,两者通过文件名(去掉扩展名后)一一对应。

一个标准的 VOC XML 文件,结构大致是这样的:

<annotation>
<filename>img_001.jpg</filename>
<size>
<width>640</width>
<height>480</height>
<depth>3</depth>
</size>
<object>
<name>person</name>
<pose>Unspecified</pose>
<truncated>0</truncated>
<difficult>0</difficult>
<bndbox>
<xmin>100</xmin>
<ymin>50</ymin>
<xmax>220</xmax>
<ymax>250</ymax>
</bndbox>
</object>
<object>
<name>car</name>
…
</object>
</annotation>

VOC 格式的几个关键点:

• <size> 节点记录了图片的宽、高、通道数(depth 通常是 3,表示 RGB 三通道)。这个宽高信息非常重要,因为后面我们要把 VOC 转成 YOLO 格式时,归一化坐标必须要用到图片的真实宽高。
• 每个目标用一个独立的 <object> 节点表示,包含类别名 <name>(注意,这里直接就是字符串类别名,不是数字编号)、以及边界框 <bndbox>。
• <bndbox> 里的四个值 xmin, ymin, xmax, ymax,是边界框左上角和右下角两个点的绝对像素坐标——这是和 COCO 的 [x,y,w,h]、以及 YOLO 的 [cx,cy,w,h] 都不同的第三种表示方式,俗称 xyxy 格式。
• <difficult>、<truncated>、<pose> 这几个字段,是 Pascal VOC 挑战赛为了评测复杂度专门设计的,标记这个目标是否"难以识别"、“被截断”、“姿态信息”。在大多数目标检测任务里,这几个字段对训练没有直接影响,转换的时候通常可以忽略,但有些训练框架会用 difficult=1 来过滤掉一些"困难样本"不参与训练或评测,具体取决于你用的框架的处理逻辑。

我们用画一下 VOC 这种"一图一文件"的组织结构:

相关示意图绘制如下，仅供参考：

这种"一图一文件"的设计,直观、易读,人眼打开 XML 就能看明白标注内容,这也是它早年被广泛采用的原因。但缺点也很明显——当数据集规模到了几万、几十万张图的时候,几万个小文件的 IO 开销会变得很可观,而且类别信息分散在每个 XML 文件里,如果想统一修改某个类别名,就得遍历所有文件逐个改。

2.3 YOLO 格式:为训练效率而生的极简设计

终于到了我们最熟悉(也是最终目标)的 YOLO 格式。如果你看过我们第三章第2节《YOLO 检测标签格式详解》,应该对这部分已经很熟悉了,这里我快速过一遍,重点强调和 COCO/VOC 的差异点。

YOLO 格式同样是"一图一文件",但文件是纯文本的 .txt,不是 XML,也不是 JSON。文件内容的每一行,代表图片中的一个目标,格式是:

<class_id> <x_center> <y_center> <width> <height>

五个数字用空格分隔,全部是归一化到 0~1 之间的浮点数(除了 class_id 是整数)。具体来说:

• class_id:类别索引,从 0 开始连续编号(这一点和 COCO 的 category_id 经常不连续、可能从1开始是最大的区别)。
• x_center, y_center:边界框中心点的横、纵坐标,分别除以图片的宽度和高度,归一化到 0~1。
• width, height:边界框的宽和高,同样分别除以图片的宽度和高度,归一化到 0~1。

举个例子,如果一张图片宽 640、高 480,图中有一个 person(class_id=0)的边界框,左上角在 (100, 50),右下角在 (220, 250),那么转换成 YOLO 格式就是:

0 0.250000 0.312500 0.187500 0.416667

(这几个数字怎么算出来的,我们下一部分会详细推导。)

YOLO 格式还有一个非常重要的"配套文件"——data.yaml(数据集配置文件)。这个文件里通常会指定训练集、验证集、测试集的路径,以及最关键的 names 字段:一个按 class_id 顺序排列的类别名称列表。比如:

train: ./images/train
val: ./images/val
nc: 3
names: ['person', 'car', 'cat']

这里 names 列表的顺序非常重要——names[0] 就对应所有标注文件里 class_id=0 的真实含义,names[1] 对应 class_id=1,以此类推。这个顺序一旦在数据准备阶段定下来,就必须在整个项目生命周期里保持一致,绝对不能中途打乱——这也是我们在第六部分"踩坑经验"里要重点强调的一个雷区。

YOLO 格式对目录结构也有一套约定俗成的规范(虽然不是强制的,但 Ultralytics 官方文档和绝大多数社区脚本都遵循这个规范),通常是 images 和 labels 两个平行目录,内部再按 train/val/test 分子目录,图片和标签文件用相同的文件名(只是扩展名不同)一一对应:

相关示意图绘制如下，仅供参考：

这种设计的好处是显而易见的:解析一个 .txt 文件,只需要按行 split,转成 float,几乎没有解析开销;而且因为坐标是归一化的,图片大小变化(比如做了 resize 增强)也不需要重新计算标注——这对训练时做数据增强(尤其是 Mosaic、随机缩放这类会改变图像尺寸的增强)来说,是巨大的效率优势。这也是为什么 YOLO 系列在设计标签格式时,会选择"归一化坐标"这条路。

2.4 三种格式横向对比:把差异摆在桌面上

讲了这么多,我们用一张表把三种格式的核心差异总结一下,这张表我建议你收藏,以后写转换脚本时随时可以回来对照:

这张表里我想特别拎出来再啰嗦一句的,是坐标系的三种不同表达方式:同一个边界框,在三种格式里看起来完全是三组不同的数字。我们用一张图直观感受一下,假设一张 640×480 的图片里,有一个边界框左上角在 (100,50)、右下角在 (220,250):

相关示意图绘制如下，仅供参考：

把这张图记在脑子里,我们接下来要写的所有转换脚本,本质上都是在做这张图里箭头所代表的数学运算——只不过要加上文件读写、类别映射、边界处理这些"工程细节"。

三、坐标系转换的数学本质

理解了三种格式的结构之后,坐标转换的数学其实非常简单,初中数学水平就能完全看懂。但我还是想花一点篇幅把公式系统地推导一遍,因为我发现很多转换脚本之所以写出 bug,不是因为公式记错了,而是因为对"宽高"和"中心点 vs 左上角"这两个概念混淆了。

我们约定:图片宽度为 img_w,图片高度为 img_h。一个边界框的四个"原始"信息是左上角坐标 (xmin, ymin) 和右下角坐标 (xmax, ymax),这两个点完全确定了一个矩形。

从 VOC(xyxy)到 COCO(xywh)的转换,非常直接,只是换一种参数化方式:

x = xmin
y = ymin
w = xmax – xmin
h = ymax – ymin

反过来,从 COCO 到 VOC:

xmin = x
ymin = y
xmax = x + w
ymax = y + h

从 VOC/COCO(绝对像素)到 YOLO(归一化中心点宽高)的转换,需要两步操作:第一步是把"左上角+宽高"或者"左上角+右下角"转换成"中心点+宽高";第二步是用图片的宽高做归一化。公式是:

cx = (xmin + xmax) / 2 / img_w
cy = (ymin + ymax) / 2 / img_h
w_norm = (xmax – xmin) / img_w
h_norm = (ymax – ymin) / img_h

如果你拿到的是 COCO 格式的 [x, y, w, h](注意这里的 x,y 是左上角,不是中心点!),那就先算出 xmax = x + w、ymax = y + h,再代入上面的公式;或者更直接一点,可以推导出这个等价公式:

cx = (x + w/2) / img_w
cy = (y + h/2) / img_h
w_norm = w / img_w
h_norm = h / img_h

这两种写法在数学上是完全等价的,代码里用哪一种取决于你拿到的是 xyxy 还是 xywh 数据,但一定要先想清楚自己手里的数字到底代表什么——这就是我前面说的,80% 的坑都在"理解错了原始数据的含义"这一步。

反过来,从 YOLO(归一化中心点宽高)还原到 VOC(xyxy 绝对像素):

xmin = (cx – w_norm/2) * img_w
ymin = (cy – h_norm/2) * img_h
xmax = (cx + w_norm/2) * img_w
ymax = (cy + h_norm/2) * img_h

这个反向公式我们在 5.3 节(YOLO -> VOC)的实战代码里会真正用到。

这里有一个细节我想单独强调:反归一化之后的坐标,理论上应该落在 [0, img_w] 和 [0, img_h] 的范围内,但因为浮点数运算的误差,实际计算结果有时会出现极小的负数(比如 -0.0000001)或者略微超出图片边界的数值(比如 640.0003)。如果你直接把这种数值写入 XML 或者用来画图,通常不会出大问题,但严谨的工程实践里,我们会加一步边界裁剪(clip):

xmin = max(0, xmin)
ymin = max(0, ymin)
xmax = min(img_w, xmax)
ymax = min(img_h, ymax)

这一步在我们 5.3 节的代码里也会出现,你看到的时候记得它是为了解决什么问题。

另外还有一个经常被忽略但很重要的点——面积(area)的计算。COCO 格式的 annotations 里有一个 area 字段,这个字段在 COCO 官方评测脚本(pycocotools)里会被用来对不同尺寸的目标分组统计(比如区分"小目标"、“中目标”、"大目标"的检测精度,这也是我们第六节《小目标数据集制作》里会展开的话题)。如果你写 YOLO -> COCO 的转换脚本,千万别忘了把这个字段算出来——公式很简单,就是 area = w * h(这里的 w, h 是绝对像素值的宽高,不是归一化的),但忘了写这个字段,用 pycocotools 评测的时候就会报错或者算出错误的统计结果。

四、转换脚本的设计思路:中间表示法 + 整体流程图

如果你现在打开搜索引擎搜"coco to yolo python",会发现一大堆脚本,大部分长得都差不多——一个函数读 COCO json,直接遍历、计算、写 txt。这种"点对点"的写法在小项目里没问题,但如果你需要支持 COCO、VOC、YOLO 三种格式之间任意两两转换,点对点写法就会面临一个组合爆炸的问题:三种格式,两两转换,一共需要 3 × 2 = 6 个转换函数(COCO→VOC, COCO→YOLO, VOC→COCO, VOC→YOLO, YOLO→COCO, YOLO→VOC)。如果以后再加一种格式(比如 LabelMe 的 json 格式),转换函数的数量会继续呈平方级增长。

更优雅的做法,是引入一个**“中间表示”(Intermediate Representation, IR)**——设计一个统一的、与具体格式无关的内部数据结构,所有格式先"解析"成这个中间表示,再从中间表示"序列化"成目标格式。这样,N 种格式之间的转换,只需要写 N 个"解析器"和 N 个"序列化器",总共 2N 个函数,而不是 N×(N-1) 个转换函数。

这个中间表示该怎么设计?其实非常朴素——我们用一个 Python 字典(或者更严谨一点,用 dataclass)来描述"一张图片 + 它所有的标注框",大致结构是:

{
"file_name": "img_001.jpg",
"width": 640,
"height": 480,
"objects": [
{"class_name": "person", "bbox_xyxy": [100, 50, 220, 250]},
{"class_name": "car", "bbox_xyxy": [300, 200, 500, 300]},
]
}

我把 bbox 统一用 xyxy 绝对像素坐标作为中间表示的标准——之所以选这个,是因为 VOC 本身就是 xyxy,COCO 的 xywh 转 xyxy 只需要一次加法,YOLO 的归一化 cxcywh 转 xyxy 也只是一步反归一化,三者转成 xyxy 的代码量都最小,选它作为"通用语"是最划算的。

整个转换流程,用画出来是这样的，仅供参考：

为什么我要专门讲这个"中间表示"的设计思路,而不是直接甩代码?因为我觉得理解设计思路,比记住某一段具体代码更重要——很多读者反馈说,看完转换脚本能跑是能跑,但换一个数据集(比如类别名里有空格、或者图片是 png 不是 jpg)就出错了,改起来一头雾水。如果你理解了"先统一成 xyxy 中间表示,再分别序列化"这个思路,遇到新的格式变种,你自己就能照着这个套路把"解析器"和"序列化器"补全,而不需要从头再学一遍。

好,思路讲完了,接下来真正进入"撕代码"环节。为了让你能直接复制粘贴跑起来(而不需要先去找一个真实数据集),我们先用代码"造"一个迷你数据集出来——这一步在实际工程里其实也很常见,叫做用小规模合成数据做单元测试,确保转换脚本的逻辑正确之后,再放到大规模真实数据上去跑。

五、动手实战:六个可直接运行的转换脚本

5.0 环境准备

我们这一节用到的库都非常基础,绝大多数 Python 环境里都自带或者一条命令就能装好:

# 这一节只需要 Pillow(读写图片、画框可视化)
# json、os、xml.etree.ElementTree 都是 Python 标准库,无需额外安装
pip install Pillow

特别说明一下:我们这里不依赖 OpenCV(cv2),完全用 Pillow 处理图片读取尺寸和画框,这样可以减少环境依赖。如果你的项目里已经在用 cv2,把 Image.open(…).size 换成 cv2.imread(…).shape[:2][::-1] 即可,逻辑是一样的。

5.1 构造一个迷你 COCO 数据集(用于测试)

下面这段代码会在当前目录下创建一个 coco_demo 文件夹,里面包含两张占位图片(用纯色矩形代替真实照片,方便复现)和一个 COCO 格式的标注文件。注意我故意把 category_id 设置成 1、3、17 这种不连续的编号——这是真实 COCO 数据集里经常出现的情况,我们要让转换脚本能正确处理这种情况,而不是想当然地认为类别编号是连续的。

# make_mock_coco.py
# 作用:构造一个迷你 COCO 格式数据集,用于测试转换脚本是否正确
# 思路:用纯色图片代替真实照片,重点是验证标注数据的转换逻辑,不依赖真实图像内容

import json
from PIL import Image
import os

os.makedirs("coco_demo/images", exist_ok=True)

# 生成两张占位图片,分辨率不同(640×480 和 800×600),
# 模拟真实数据集里图片尺寸往往不统一的情况——这一点很重要,
# 因为坐标归一化的分母就是图片的宽高,尺寸不统一是常态而非特例
Image.new("RGB", (640, 480), (200, 200, 200)).save("coco_demo/images/img_001.jpg")
Image.new("RGB", (800, 600), (180, 220, 180)).save("coco_demo/images/img_002.jpg")

coco = {
"info": {"description": "mini demo dataset"},
"licenses": [],
# 关键点:categories 的 id 故意设置为 1, 3, 17(不连续),
# 这模拟了真实 COCO 数据集中 category_id 跳号的情况
"categories": [
{"id": 1, "name": "person", "supercategory": "none"},
{"id": 3, "name": "car", "supercategory": "none"},
{"id": 17, "name": "cat", "supercategory": "none"},
],
"images": [
{"id": 1, "file_name": "img_001.jpg", "width": 640, "height": 480},
{"id": 2, "file_name": "img_002.jpg", "width": 800, "height": 600},
],
"annotations": [
# bbox 格式:[x_min, y_min, width, height],单位像素(COCO 官方标准格式)
{"id": 1, "image_id": 1, "category_id": 1, "bbox": [100, 50, 120, 200], "area": 24000, "iscrowd": 0},
{"id": 2, "image_id": 1, "category_id": 3, "bbox": [300, 200, 200, 100], "area": 20000, "iscrowd": 0},
{"id": 3, "image_id": 2, "category_id": 17, "bbox": [50, 50, 80, 60], "area": 4800, "iscrowd": 0},
{"id": 4, "image_id": 2, "category_id": 1, "bbox": [400, 300, 150, 250], "area": 37500, "iscrowd": 0},
],
}

with open("coco_demo/annotations.json", "w", encoding="utf-8") as f:
json.dump(coco, f, ensure_ascii=False, indent=2)

print("迷你 COCO 数据集已生成 -> coco_demo/")

跑完这段代码,你会得到 coco_demo/images/ 下两张图片,和 coco_demo/annotations.json 一个标注文件。接下来我们正式进入转换环节。

5.2 COCO -> YOLO:最常用的一条转换路径

这是实战中最常用的一条转换路径,因为大量公开数据集(COCO 本身、很多 Kaggle 数据集)都是 COCO json 格式发布的,而我们最终要喂给 YOLOv10 训练的是 YOLO txt 格式。

# coco2yolo.py
# 作用:将 COCO 格式的标注(单个 json 文件)转换为 YOLO 格式(每张图一个 txt)
# 核心难点:
# 1) category_id 可能不连续,需要重新映射为 0..N-1 的连续 class_id
# 2) bbox 是 [x,y,w,h] 绝对像素,需要转换为归一化的 [cx,cy,w,h]

import json
import os

def coco_to_yolo(coco_json_path, output_dir):
"""
coco_json_path: COCO 标注 json 文件路径
output_dir: 转换后 YOLO txt 文件的输出目录
返回值: names —— 按 class_id 顺序排列的类别名列表,需要写进 data.yaml
"""
with open(coco_json_path, "r", encoding="utf-8") as f:
coco = json.load(f)

os.makedirs(output_dir, exist_ok=True)

# —— 关键步骤1:建立 category_id -> yolo class_id 的映射表 ——
# 按照 category 的 id 字段从小到大排序后,依次赋予 0,1,2,… 的新编号
# 这样无论原始 id 是 1,3,17 还是别的不连续编号,转换后都会变成连续的 0,1,2,…
categories = sorted(coco["categories"], key=lambda c: c["id"])
cat_id_to_yolo_idx = {c["id"]: idx for idx, c in enumerate(categories)}
names = [c["name"] for c in categories]

# —— 关键步骤2:按 image_id 把 annotations 分组 ——
# 避免对每个 image 都遍历一次完整的 annotations 列表,提升效率
img_id_to_info = {img["id"]: img for img in coco["images"]}
anns_by_image = {}
for ann in coco["annotations"]:
anns_by_image.setdefault(ann["image_id"], []).append(ann)

# —— 关键步骤3:逐张图片生成对应的 txt 标签文件 ——
for img_id, img_info in img_id_to_info.items():
img_w, img_h = img_info["width"], img_info["height"]
file_stem = os.path.splitext(img_info["file_name"])[0]

lines = []
for ann in anns_by_image.get(img_id, []):
x, y, w, h = ann["bbox"] # COCO: 左上角(x,y) + 宽高(w,h),单位像素

# 坐标转换公式:左上角+宽高 -> 归一化中心点+宽高
cx = (x + w / 2) / img_w
cy = (y + h / 2) / img_h
nw = w / img_w
nh = h / img_h

cls = cat_id_to_yolo_idx[ann["category_id"]]
lines.append(f"{cls} {cx:.6f} {cy:.6f} {nw:.6f} {nh:.6f}")

# 即使一张图片没有任何标注(纯负样本),也要生成一个空的 txt 文件
# 这一点在 YOLO 训练里很重要——空 txt 表示"这张图没有目标",
# 而"没有 txt 文件"在某些训练配置下会被直接忽略而不是当作负样本
txt_path = os.path.join(output_dir, file_stem + ".txt")
with open(txt_path, "w") as f:
f.write("\\n".join(lines))

return names

if __name__ == "__main__":
names = coco_to_yolo("coco_demo/annotations.json", "coco_demo/labels")
print("类别名顺序(对应 class_id 0,1,2,…):", names)

# 把 names 写入 data.yaml,这一步千万别漏!
yaml_content = (
"train: ./images/train\\n"
"val: ./images/val\\n"
f"nc: {len(names)}\\n"
f"names: {names}\\n"
)
with open("coco_demo/data.yaml", "w", encoding="utf-8") as f:
f.write(yaml_content)
print("data.yaml 已生成")

跑一下这段代码,我们用前面构造的迷你数据集做测试,输出结果应该是:

类别名顺序(对应 class_id 0,1,2,…): ['person', 'car', 'cat']

而 coco_demo/labels/img_001.txt 的内容是:

0 0.250000 0.312500 0.187500 0.416667
1 0.625000 0.520833 0.312500 0.208333

我们来手算验证一下第一行:img_001.jpg 尺寸是 640×480,第一个标注的 bbox 是 [100, 50, 120, 200](category_id=1,即 person)。

cx = (100 + 120/2) / 640 = 160/640 = 0.25 ✓
cy = (50 + 200/2) / 480 = 150/480 = 0.3125 ✓
w = 120 / 640 = 0.1875 ✓
h = 200 / 480 = 0.41667 ✓

class_id 是 0,对应 names 列表里的 person(因为 category_id=1 排序后是最小的,被映射成了 0)——完全正确!第二行 category_id=3(car)被映射成了 1,这也验证了我们的"重新编号"逻辑生效了。

这里我想再多说一句关于"空 txt 文件"的事——这其实是一个很容易被忽略,但在实际项目里非常重要的细节。如果你的数据集里有一部分图片是"背景图"(没有任何目标,纯粹是负样本,我们在第12节《背景负样本构建》里会专门讲这个),那么这些图片对应的标注文件应该是一个空文件,而不是完全不存在的文件。区别在哪?如果文件不存在,有些数据加载逻辑会直接跳过这张图(相当于这张图没有参与训练);而如果文件存在但是空的,YOLOv10 的数据加载器会把它当作"这张图确认没有任何目标"来处理,两者在训练语义上是不同的。所以写转换脚本的时候,这个看似"多余"的 with open(txt_path, "w") 操作,其实是有意为之。

5.3 VOC -> YOLO:类别名要自己"定个规矩"

VOC 转 YOLO,和 COCO 转 YOLO 最大的区别在哪?COCO 的类别信息集中存储在 json 的 categories 字段里,可以自动提取并排序;而 VOC 的类别信息分散在每个 XML 文件的 <name> 标签里,是字符串,没有统一的编号。所以转换之前,我们必须预先定义一份类别名列表,这份列表的顺序就决定了 YOLO 的 class_id 分配。

# voc2yolo.py
# 作用:将 VOC 格式的标注(每张图一个 xml)转换为 YOLO 格式(每张图一个 txt)
# 核心难点:
# 1) VOC 用类别"名字"(字符串),YOLO 用类别"编号"(整数),
# 需要预先约定一份固定顺序的类别列表,作为两者之间的映射桥梁
# 2) bbox 是 xyxy 绝对像素,需要转换为归一化 cxcywh

import os
import xml.etree.ElementTree as ET

# —— 关键:预先定义类别名列表,顺序即为 yolo class_id ——
# 这份列表必须在整个项目中保持完全一致,建议直接写进 data.yaml 里统一管理,
# 不要在不同脚本里各写一份,否则一旦顺序不一致,训练出来的模型类别就全错位了
CLASS_NAMES = ["person", "car", "cat"]
name_to_idx = {name: idx for idx, name in enumerate(CLASS_NAMES)}

def voc_to_yolo(xml_dir, output_dir):
"""
xml_dir: 存放 VOC xml 标注文件的目录
output_dir: 转换后 YOLO txt 文件的输出目录
"""
os.makedirs(output_dir, exist_ok=True)

for xml_file in os.listdir(xml_dir):
if not xml_file.endswith(".xml"):
continue

tree = ET.parse(os.path.join(xml_dir, xml_file))
root = tree.getroot()

# 从 <size> 节点读取图片宽高,这是归一化必需的分母
size_node = root.find("size")
img_w = int(size_node.find("width").text)
img_h = int(size_node.find("height").text)

lines = []
for obj in root.findall("object"):
name = obj.find("name").text

# 防御性编程:如果遇到不在 CLASS_NAMES 里的"陌生类别",
# 不要悄悄丢弃也不要随意编号,而是打印警告让人工介入处理
if name not in name_to_idx:
print(f"[警告] 文件 {xml_file} 中出现未登记类别 '{name}',已跳过该目标")
continue

bnd = obj.find("bndbox")
xmin = float(bnd.find("xmin").text)
ymin = float(bnd.find("ymin").text)
xmax = float(bnd.find("xmax").text)
ymax = float(bnd.find("ymax").text)

# xyxy 绝对像素 -> 归一化 cxcywh
cx = (xmin + xmax) / 2 / img_w
cy = (ymin + ymax) / 2 / img_h
w = (xmax – xmin) / img_w
h = (ymax – ymin) / img_h

cls = name_to_idx[name]
lines.append(f"{cls} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}")

stem = os.path.splitext(xml_file)[0]
with open(os.path.join(output_dir, stem + ".txt"), "w") as f:
f.write("\\n".join(lines))

if __name__ == "__main__":
voc_to_yolo("voc_demo/Annotations", "voc_demo/labels")
print("VOC -> YOLO 转换完成,class_id 对应关系:")
for idx, name in enumerate(CLASS_NAMES):
print(f" {idx} -> {name}")

这里我想专门展开讲讲那个"防御性编程"的小判断——if name not in name_to_idx。

你可能会觉得,这不就是个简单的容错吗,有什么值得专门讲的?但我自己在真实项目里,真的遇到过这种情况:标注团队在标注过程中,因为没有严格执行类别命名规范,有人把 “car” 标成了 “Car”(大写开头),还有人手滑标成了 "car " (后面带了一个空格)。如果转换脚本里没有这个判断,而是简单地用 name_to_idx.get(name, 某个默认值) 或者直接 name_to_idx[name] 让它抛 KeyError 中断整个转换——前者会让这些"脏标注"被错误地归到某个类别里(更糟),后者会让整个转换流程在处理到第几千张图的时候突然崩掉,而你根本不知道是哪张图、哪个标注出了问题。

加上这个警告打印之后,你转换完一份几千张图的数据集,如果终端打印出了几十条"未登记类别"的警告,你立刻就能知道——数据里存在命名不规范的问题,需要回去清洗(这正是第9节《脏数据清洗》要讲的内容)。好的转换脚本,不仅要能转换正确的数据,更要能在遇到"脏数据"时,清晰地告诉你哪里脏了,而不是悄无声息地把脏数据也一起转换过去。

跑一下这段代码(配合我们前面构造的 voc_demo 数据,XML 内容和我们 COCO 示例里的 bbox 是对应设计的),结果应该和 5.2 节 COCO 转换出来的 img_001.txt 完全一致(因为我设计的两份示例数据描述的是同一个边界框):

0 0.250000 0.312500 0.187500 0.416667
1 0.625000 0.520833 0.312500 0.208333

这其实也是一种很好的自检方式——如果你手头同时有 COCO 格式和 VOC 格式的同一份数据(比如某些数据集会同时提供两种格式),分别转成 YOLO 之后,结果应该是一致的。如果不一致,大概率是某个格式的解析逻辑写错了。

5.4 YOLO -> VOC:反归一化 + 图片尺寸的"补全"

这是一条"反向"的转换路径,看起来用得少,但其实有几个很实用的场景:比如你用 YOLOv10 训练好的模型对一批新图片做推理,生成的检测结果想要导入到某个只支持 VOC 格式的标注审核工具里做人工复核(这其实就是我们第13节《主动学习》会涉及的场景);或者你想把 YOLO 格式的数据集"喂"给一个只支持 VOC 格式输入的旧版训练框架做对比实验。

这条路径最大的特点是:YOLO 标注文件本身不包含图片尺寸信息,所以反归一化之前,必须先读取真实图片文件拿到宽高。

# yolo2voc.py
# 作用:将 YOLO 格式标注(txt)转换为 VOC 格式标注(xml)
# 核心难点:
# 1) YOLO txt 里没有图片宽高,必须打开图片文件实际读取
# 2) 反归一化坐标可能因浮点误差略微越界,需要做边界裁剪

import os
from PIL import Image
import xml.etree.ElementTree as ET
from xml.dom import minidom

CLASS_NAMES = ["person", "car", "cat"]

def yolo_to_voc(images_dir, labels_dir, output_dir):
"""
images_dir: 图片所在目录(用于读取图片真实尺寸)
labels_dir: YOLO txt 标注所在目录
output_dir: 转换后 VOC xml 文件的输出目录
"""
os.makedirs(output_dir, exist_ok=True)

for img_file in os.listdir(images_dir):
stem, ext = os.path.splitext(img_file)
label_path = os.path.join(labels_dir, stem + ".txt")
if not os.path.exists(label_path):
# 这张图没有对应的标注文件,跳过
# (注意:这和"标注文件存在但内容为空"是两种不同的情况)
continue

# 关键步骤:打开图片读取真实宽高,这是反归一化的分母
with Image.open(os.path.join(images_dir, img_file)) as im:
img_w, img_h = im.size

# 构造 XML 树的根节点和基础信息
root = ET.Element("annotation")
ET.SubElement(root, "filename").text = img_file
size_node = ET.SubElement(root, "size")
ET.SubElement(size_node, "width").text = str(img_w)
ET.SubElement(size_node, "height").text = str(img_h)
ET.SubElement(size_node, "depth").text = "3"

with open(label_path) as f:
for line in f:
line = line.strip()
if not line:
continue # 跳过空行(对应"无目标"的图片)

cls, cx, cy, w, h = line.split()
cls = int(cls)
cx, cy, w, h = float(cx), float(cy), float(w), float(h)

# 归一化 cxcywh -> 绝对像素 xyxy
xmin = (cx – w / 2) * img_w
ymin = (cy – h / 2) * img_h
xmax = (cx + w / 2) * img_w
ymax = (cy + h / 2) * img_h

# 边界裁剪:防止浮点误差导致坐标轻微越界
# (比如算出 -0.0003 或 640.0002 这种数值)
xmin = max(0, xmin); ymin = max(0, ymin)
xmax = min(img_w, xmax); ymax = min(img_h, ymax)

obj = ET.SubElement(root, "object")
ET.SubElement(obj, "name").text = CLASS_NAMES[cls]
ET.SubElement(obj, "difficult").text = "0"
bnd = ET.SubElement(obj, "bndbox")
# 写入 XML 时四舍五入为整数像素,VOC 格式约定坐标为整数
ET.SubElement(bnd, "xmin").text = str(int(round(xmin)))
ET.SubElement(bnd, "ymin").text = str(int(round(ymin)))
ET.SubElement(bnd, "xmax").text = str(int(round(xmax)))
ET.SubElement(bnd, "ymax").text = str(int(round(ymax)))

# 用 minidom 美化输出格式(加上换行和缩进),否则 ET 默认输出是一行到底,人很难阅读
xml_str = minidom.parseString(ET.tostring(root)).toprettyxml(indent=" ")
with open(os.path.join(output_dir, stem + ".xml"), "w") as f:
f.write(xml_str)

if __name__ == "__main__":
yolo_to_voc("coco_demo/images", "coco_demo/labels", "yolo2voc_out")
print("YOLO -> VOC 转换完成,输出目录:yolo2voc_out/")

我自己实际跑了一遍这段代码,用 5.2 节转换出来的 coco_demo/labels/img_001.txt 作为输入,得到的 img_001.xml 里 <bndbox> 是:

<bndbox>
<xmin>100</xmin>
<ymin>50</ymin>
<xmax>220</xmax>
<ymax>250</ymax>
</bndbox>

和我们最初构造的 VOC 示例数据(5.3节用的 voc_demo/Annotations/img_001.xml)里的 <bndbox> 完全一致!这说明 COCO -> YOLO -> VOC 这一条"链路"做了一次完整的"环形验证"——经过两次格式转换之后,坐标信息完全没有丢失或失真。这种"环形验证"其实是我个人在工程里非常喜欢用的一种测试手段:A 转 B 再转回 A,结果应该(在误差范围内)和原始 A 一致,如果不一致,说明转换链路里某一环的公式或逻辑写错了。

顺便提一句关于 minidom.parseString(…).toprettyxml(…) 这个写法——如果你直接用 ET.tostring(root),得到的会是一整行没有任何换行和缩进的 XML 字符串,虽然程序能正常解析,但人眼几乎没法读。用 minidom 重新格式化一遍,虽然多了几行代码,但生成的 XML 文件可以直接用文本编辑器打开检查,这对调试和人工审核都很重要——别小看这种"人类可读性",在数据工程里,能让人一眼看懂的中间产物,能帮你省下大量排查 bug 的时间。

5.5 YOLO -> COCO:把"分散"重新"聚合"

最后一条路径,是把 YOLO 格式的多个 txt 文件,重新聚合成一个 COCO 格式的 json 文件。这个场景常见于:你用 YOLOv10 标注/训练了一批数据,现在想用 pycocotools 这种标准的 COCO 评测工具来计算 mAP(因为 pycocotools 是目标检测领域最广泛使用的评测标准之一,很多论文复现、竞赛评测都要求提交 COCO 格式的结果)。

# yolo2coco.py
# 作用:将 YOLO 格式标注(多个 txt)聚合转换为单个 COCO 格式 json 文件
# 核心难点:
# 1) 需要为每张图片、每个标注分配全局唯一的 image_id / annotation_id
# 2) 需要计算 area 字段(pycocotools 评测会用到)
# 3) categories 列表需要和 CLASS_NAMES 顺序一致

import os
import json
from PIL import Image

CLASS_NAMES = ["person", "car", "cat"]

def yolo_to_coco(images_dir, labels_dir, output_json):
"""
images_dir: 图片所在目录(用于读取真实宽高)
labels_dir: YOLO txt 标注所在目录
output_json: 输出的 COCO json 文件路径
"""
images, annotations = [], []
# categories 直接按 CLASS_NAMES 的顺序生成,id 从 0 开始(与 YOLO class_id 完全对齐)
categories = [
{"id": i, "name": n, "supercategory": "none"}
for i, n in enumerate(CLASS_NAMES)
]

ann_id = 1 # annotation 的全局唯一编号,从 1 开始递增(沿用 COCO 习惯)

# 对图片列表排序,保证每次转换的 image_id 分配是确定且可复现的
for img_id, img_file in enumerate(sorted(os.listdir(images_dir)), start=1):
stem, ext = os.path.splitext(img_file)

with Image.open(os.path.join(images_dir, img_file)) as im:
img_w, img_h = im.size

images.append({
"id": img_id,
"file_name": img_file,
"width": img_w,
"height": img_h,
})

label_path = os.path.join(labels_dir, stem + ".txt")
if not os.path.exists(label_path):
continue

with open(label_path) as f:
for line in f:
line = line.strip()
if not line:
continue

cls, cx, cy, w, h = line.split()
cls = int(cls)
cx, cy, w, h = float(cx), float(cy), float(w), float(h)

# 归一化 cxcywh -> 绝对像素 xywh(COCO 格式)
box_w = w * img_w
box_h = h * img_h
x_min = (cx – w / 2) * img_w
y_min = (cy – h / 2) * img_h

annotations.append({
"id": ann_id,
"image_id": img_id,
"category_id": cls, # 因为 categories 的 id 就是从0开始按 CLASS_NAMES 顺序排的,这里可以直接对齐
"bbox": [round(x_min, 2), round(y_min, 2), round(box_w, 2), round(box_h, 2)],
"area": round(box_w * box_h, 2),
"iscrowd": 0,
})
ann_id += 1

coco = {
"info": {"description": "converted from YOLO format"},
"licenses": [],
"images": images,
"annotations": annotations,
"categories": categories,
}

with open(output_json, "w", encoding="utf-8") as f:
json.dump(coco, f, ensure_ascii=False, indent=2)

if __name__ == "__main__":
yolo_to_coco("coco_demo/images", "coco_demo/labels", "yolo2coco_out.json")
print("YOLO -> COCO 转换完成 -> yolo2coco_out.json")

跑完之后,我们再做一次"环形验证"——把 yolo2coco_out.json 和最初 5.1 节里手写的 coco_demo/annotations.json 对比一下:第一个标注 bbox: [100, 50, 120, 200] 转成 YOLO 再转回 COCO,得到的是 [100.0, 50.0, 120.0, 200.0],area 是 24000.02(原始是 24000)。

注意到那个微小的差异了吗?24000 变成了 24000.02。这不是 bug,而是我们前面讨论过的浮点精度损失——因为 YOLO 格式把坐标保留到 6 位小数(我们脚本里用的 :.6f),在"归一化再反归一化"的过程中,引入了大约 10^-5 量级的误差,放大到像素尺度上,就变成了零点几的偏差。这种误差在实际工程里完全可以忽略(对于检测框来说,几十分之一个像素的偏差不会对训练或评测产生任何实质影响),但我专门把它展示出来,是想让你建立一个认知:格式转换不是"无损"的数学变换,只要涉及归一化/反归一化,就一定存在浮点精度的损耗。如果你的下游任务对坐标精度有极高要求(比如某些医学影像或工业测量场景),需要考虑提高保留小数位数,或者干脆设计一套全程使用绝对像素坐标的内部格式来规避这个问题。

5.6 可视化校验:永远不要相信"没报错"

写完了四个转换脚本,理论上格式互转的"硬功夫"就讲完了。但我想再加一节——也是我认为整个数据工程流程里最容易被偷工减料、但也最重要的一步:可视化校验。

为什么这么说?因为格式转换脚本最危险的 bug,往往不是那种会让程序崩溃报错的 bug,而是"程序跑得很顺利,输出文件也生成了,数字看起来也都在合理范围内,但框画的位置就是不对"——比如把 x 和 y 算反了、宽高弄反了、或者归一化的时候用错了 img_w 和 img_h(比如把宽和高搞反,这在长宽比悬殊的图片上特别容易出问题)。这种 bug,光看数字你根本发现不了,唯一靠谱的办法就是把框画到图上,用眼睛去看。

# visualize.py
# 作用:把 YOLO 格式的标注框画到图片上,人工抽样检查转换结果是否正确
# 这是格式转换流程里"成本最低、收益最高"的一步质检环节

import os
from PIL import Image, ImageDraw

CLASS_NAMES = ["person", "car", "cat"]
COLORS = [(255, 0, 0), (0, 200, 0), (0, 0, 255)] # 不同类别用不同颜色,方便区分

def visualize_yolo(images_dir, labels_dir, save_dir):
os.makedirs(save_dir, exist_ok=True)

for img_file in os.listdir(images_dir):
stem, ext = os.path.splitext(img_file)
label_path = os.path.join(labels_dir, stem + ".txt")
if not os.path.exists(label_path):
continue

im = Image.open(os.path.join(images_dir, img_file)).convert("RGB")
img_w, img_h = im.size
draw = ImageDraw.Draw(im)

with open(label_path) as f:
for line in f:
line = line.strip()
if not line:
continue
cls, cx, cy, w, h = map(float, line.split())
cls = int(cls)

xmin = (cx – w / 2) * img_w
ymin = (cy – h / 2) * img_h
xmax = (cx + w / 2) * img_w
ymax = (cy + h / 2) * img_h

color = COLORS[cls % len(COLORS)]
draw.rectangle([xmin, ymin, xmax, ymax], outline=color, width=3)
draw.text((xmin + 2, ymin + 2), CLASS_NAMES[cls], fill=color)

im.save(os.path.join(save_dir, img_file))

if __name__ == "__main__":
visualize_yolo("coco_demo/images", "coco_demo/labels", "vis_out")
print("可视化结果已保存到 vis_out/,请打开图片人工核对框的位置是否正确")

这段代码非常简单,本质上就是把我们 5.4 节里"YOLO -> VOC"用过的反归一化公式拿过来,把框画在图上而不是写进 XML。但我想强调的不是代码本身,而是一种工作习惯:每一次写完格式转换脚本,都至少随机抽 5~10 张图,跑一遍可视化,用肉眼确认框的位置、类别标签都对得上。这一步花不了你五分钟,但能帮你避免"用错误标注训练出一个看起来在收敛、但实际上学到的是错误规律的模型"这种最痛苦的情况——而这种情况一旦发生,你往往要等模型训练完、做推理评测的时候才会发现"咦,为什么效果这么差",再回头排查,可能已经浪费了好几个小时甚至好几天的训练时间。我自己团队的规矩是:任何格式转换脚本提交前,必须附上至少 5 张可视化抽检图,这已经写进了我们的代码审查清单里。

六、那些年我们踩过的坑(血泪经验)

讲完了"正路",接下来这一节,我想聊点"反面教材"——这些坑,几乎每一个我自己或者团队成员都曾经亲身踩过,放在这里,希望能帮你绕过去。

坑一:把 COCO 的 category_id 直接当成 YOLO 的 class_id

这是最经典、也是最隐蔽的一个坑。前面已经反复强调过,COCO 数据集的 category_id 范围是 1~90(且不连续),如果你直接用 category_id 作为 YOLO 的 class_id,那么你的 data.yaml 里 nc(类别数量)就要写 90,names 列表也要凑够 90 个位置(中间空缺的编号要用占位字符串填充)。这样虽然"能跑",但模型的输出层会白白浪费大量神经元在那些根本不存在的类别上,训练效率和收敛速度都会受影响。正确做法永远是:重新映射成 0…N-1 的连续编号,这也是我们 5.2 节代码里第一步就在做的事。

坑二:归一化时用错了图片的宽和高

这个坑听起来很傻,“宽和高还能搞混?”,但当你处理成千上万张图片、尤其是图片里长宽比差异很大(比如有些图是横向的全景图,宽高比 4:1;有些是竖向的手机拍照,宽高比 9:16)的时候,如果代码里某一处把 img_w 和 img_h 写反了,转换出来的归一化坐标在数值上依然落在 0~1 之间、看起来完全合理——但框的位置和大小是错的!这种 bug 用肉眼看一两个数字根本发现不了,必须靠 5.6 节的可视化校验才能抓出来。我建议你在写完转换脚本后,专门挑一张宽高比悬殊的图片做可视化测试,这种图片对"宽高搞反"这类 bug 的"放大效果"特别明显——如果宽高搞反了,在宽高比悬殊的图上,框会变成完全不成比例的形状,一眼就能看出来。

坑三:类别名顺序在不同脚本里不一致

这个坑我个人觉得是最容易被忽视、但后果最严重的一个。想象这样一个场景:你写了一个 voc2yolo.py,里面定义了 CLASS_NAMES = ["person", "car", "cat"];过了几天,你又写了一个数据增强脚本,里面又重新定义了一份 CLASS_NAMES = ["car", "cat", "person"](顺序不小心写反了,或者是从另一份代码里复制过来的,顺序不一样)。如果这份新脚本生成的标注也混进了训练集——模型训练完全不会报错,但训练出来的模型里,"car"和"person"的类别会被错误地互相学习,推理的时候会把车检测成人、把人检测成车。这种 bug 极难排查,因为表面上一切正常,只有在评估某个特定类别的精度异常低、或者做可视化推理时才会暴露。

我给的解决方案是:把 CLASS_NAMES(也就是 names 列表)只在 data.yaml 里定义一次,所有脚本都从这个文件里读取,绝不在多个脚本里各自硬编码一份。下面这个小工具函数,可以作为你所有转换脚本的"标准开头":

# load_class_names.py
# 作用:统一从 data.yaml 读取类别名列表,避免在多个脚本里各自硬编码导致顺序不一致
import yaml # 需要 pip install pyyaml

def load_class_names(yaml_path):
with open(yaml_path, "r", encoding="utf-8") as f:
data = yaml.safe_load(f)
names = data["names"]
# 兼容两种写法:names 可能是列表 ['a','b','c'],也可能是字典 {0:'a',1:'b',2:'c'}
if isinstance(names, dict):
names = [names[i] for i in sorted(names.keys())]
return names

坑四:图像和标注文件"对不上号"

这个坑通常出现在文件名层面——比如图片是 IMG_0001.JPG(大写扩展名),但标注文件是 img_0001.txt(小写文件名);或者图片文件夹里混进了 .png 和 .jpg 两种格式,但转换脚本里写死了只处理 .jpg,结果一部分 .png 图片"悄无声息"地被漏掉了,既没有报错,也没有生成对应的标注文件。

我的建议是:转换脚本写完之后,一定要做一次"数量核对"——统计转换前的图片数量、标注数量,和转换后的标注文件数量是否一致。如果不一致,差异的数量就是你需要排查的"漏网之鱼"。这个核对逻辑可以写成几行简单的代码:

# 数量核对小工具
import os

images_count = len([f for f in os.listdir("coco_demo/images")
if f.lower().endswith((".jpg", ".jpeg", ".png"))])
labels_count = len([f for f in os.listdir("coco_demo/labels")
if f.endswith(".txt")])

print(f"图片数量: {images_count}, 标注文件数量: {labels_count}")
assert images_count == labels_count, "图片和标注数量不一致!请检查文件名匹配逻辑"

坑五:中文路径与文件名编码问题

如果你的数据集里有中文文件名(虽然不推荐,但现实中确实存在),在 Windows 系统上用某些库读写文件时可能会遇到编码报错。我的建议是,在数据工程的最早期阶段,就把所有文件统一重命名为纯英文+数字+下划线的组合(比如用 img_00001.jpg、img_00002.jpg 这种格式批量重命名),这不仅能规避编码问题,也能让你的数据集结构更规整、更适合自动化处理。

七、官方工具与社区方案:不必每次都重新发明轮子

讲了这么多"手写脚本"的内容,我想最后再强调一个工程上的态度问题:理解原理、能手写脚本,和"每次都手写脚本"是两件不同的事。在真实项目里,如果有经过广泛验证、维护良好的官方或社区工具能满足你的需求,优先用现成的工具,把精力留给那些"现成工具搞不定的定制化需求"。

Ultralytics(YOLO 系列的维护方)在其代码库里提供了 ultralytics.data.converter 模块,其中包含 convert_coco 这样的函数,可以直接把 COCO 格式的标注转换为 YOLO 格式,并且对 COCO 数据集本身的一些特殊情况(比如 iscrowd=1 的标注、分割掩码到检测框的转换)做了官方维护的处理。如果你的需求就是"标准 COCO -> 标准 YOLO",直接用官方提供的转换工具,通常比自己手写更省心,也更不容易遗漏官方文档里提到的边缘情况。具体的函数签名和参数,建议以你安装的 Ultralytics 版本所附带的官方文档和源码为准,因为不同版本之间接口可能会有细微调整。

社区里还有一些专门做格式转换的开源仓库,比较有代表性的比如早期由 Ultralytics 团队维护的 JSON2YOLO 工具仓库,专门处理 COCO json 到 YOLO txt 的批量转换,支持处理一些 COCO 数据集里的特殊字段。另外像 labelme2yolo、各种 voc2coco.py 社区脚本,也都是网上能搜到的成熟方案。

那么,既然有这些现成工具,为什么我还要花一整节的篇幅讲手写脚本?原因有三:

第一,现成工具往往是"黑盒",当你的数据集存在一些"非标准"情况时(比如类别名里有特殊字符、bbox 坐标有负数、某些标注缺失某个字段),现成工具可能直接报错退出,而你如果不理解底层逻辑,很难快速定位问题、写一个针对性的预处理脚本去修复;

第二,很多企业内部的标注系统,导出的格式是"类 COCO"或"类 VOC"但又不完全标准(比如多了几个自定义字段,或者字段命名有细微差异),这时候现成工具大概率用不了,你必须基于理解原理,自己改造或重写转换逻辑;

第三,也是最重要的一点——理解原理,能让你在遇到任何"新格式"时,都能快速判断它和现有格式的关系,设计出合理的转换方案,而不是每次遇到新格式就去网上漫无目的地搜"xxx to yolo converter script"然后祈祸能搜到一个恰好适用的。

所以我的建议是:先理解原理(本节的核心内容),日常工作中优先用经过验证的官方/社区工具提高效率,但当工具不够用、或者数据有"非标准"情况时,你要有能力自己动手解决——这才是数据工程师真正的"硬实力"。

八、工程化落地建议

最后,从工程化的角度,再给几条我自己团队在实践中总结出来的建议,希望能帮你把"格式转换"这件事,从"一次性脚本"升级为"可靠的工程环节"。

第一,转换脚本要做"前后数量核对"和"断言校验"。前面坑四里已经提到了图片和标注数量的核对,这里再补充一点:转换前后,标注框的总数量也应该保持一致(除非你有意做了过滤,比如过滤掉了某些"陌生类别")。可以在脚本最后加一个简单的统计和断言:

# 转换前后标注框总数核对(示例逻辑)
def count_yolo_boxes(labels_dir):
total = 0
for fn in os.listdir(labels_dir):
if fn.endswith(".txt"):
with open(os.path.join(labels_dir, fn)) as f:
total += len([line for line in f if line.strip()])
return total

# 假设 coco 原始标注框总数已知为 original_count
# converted_count = count_yolo_boxes("coco_demo/labels")
# assert converted_count == original_count, f"标注框数量不一致: {converted_count} vs {original_count}"

第二,转换后的数据集要"打版本"。数据集和代码一样,也会迭代——你可能会修复一些标注错误、补充新的数据、调整类别定义。建议给每一次转换/处理后的数据集打上版本号(比如用日期+序号命名文件夹,dataset_v20260611_01),并保留一份简单的 changelog,记录这个版本相对上一个版本做了什么改动(比如"修复了 32 张图的标注框越界问题"、“新增类别 ‘truck’”)。这一点和我们第15节《企业级数据闭环》里会讲的"数据回流再训练"流程也是直接相关的——没有版本管理,数据闭环就无从谈起。

第三,把"中间表示"思路用起来,但不必拘泥于具体形式。本节我们用 Python 字典作为中间表示,实际项目里你也可以用 pandas.DataFrame(每行是一个标注框,列包括 file_name, class_name, xmin, ymin, xmax, ymax, img_w, img_h)——用 DataFrame 的好处是,你可以非常方便地用 pandas 的筛选、分组、统计功能,对整个数据集做各种数据分析(比如统计每个类别的标注框数量分布、统计标注框尺寸分布等),这其实是为我们后面第8节《长尾类别处理》和第6节《小目标数据集制作》打下基础。

第四,这一节学到的内容,和下一节是"承上启下"的关系。我们这一节解决的是"把数据从一种格式翻译成另一种格式"的问题,但翻译完之后,这些数据怎么划分成训练集、验证集、测试集?如果划分得不合理,会不会出现"训练集和验证集里其实有几乎一样的图片"这种"数据泄漏"的隐患?这正是下一节要解决的问题——而下一节的划分脚本,输入的就是我们这一节转换好的 YOLO 格式数据。

九、本节小结

这一节,我们花了相当大的篇幅,系统地讲解了 COCO、VOC、YOLO 三种主流目标检测标注格式的底层结构、坐标系表示方式的数学本质,并基于"中间表示"的设计思路,手写实现了 COCO↔YOLO、VOC↔YOLO 之间的双向转换脚本,以及一个用于人工抽样核验的可视化脚本。

如果只让我用一句话总结这一节最重要的收获,我会说:格式转换的核心,从来不是代码本身,而是对"每一个数字到底代表什么"这件事的精确理解——是绝对坐标还是归一化坐标?是左上角+宽高,还是左上角+右下角,还是中心点+宽高?类别是用数字编号还是字符串名称?编号是从0还是从1开始,是否连续?把这几个问题在动手写代码之前就想清楚,你就已经避开了 90% 的坑。

也希望本节里反复出现的那几个"工程习惯"——环形验证、数量核对、可视化抽检、统一管理类别名列表——能成为你以后处理任何数据格式问题时,下意识就会去做的事。这些习惯,看起来好像增加了一点工作量,但它们能在关键时刻为你省下成倍的排查时间,这笔账,做数据工程的人迟早会明白是划算的。

十、下期预告

下一节,我们要解决一个听起来很"基础"、但实际操作中暗藏不少陷阱的问题:怎么把一份数据集,正确地划分成训练集(train)、验证集(val)和测试集(test)?

很多人对这个问题的第一反应是:“这还不简单,随机打乱、按 8:1:1 的比例切一下不就行了吗?” ——如果数据集里的每一张图片都是完全独立、互不相关的,那这种做法确实没问题。但现实中的数据集,经常存在各种"隐藏的关联性":

• 如果你的数据是从视频里逐帧抽取得到的,相邻几帧的画面内容几乎一模一样——如果简单随机划分,很可能出现"第100帧分到了训练集,第101帧(和第100帧几乎一样)分到了验证集"的情况,模型在验证集上的表现会"虚高",因为它本质上是在"背答案",而不是真正学到了泛化能力。
• 如果你对原始图片做过数据增强(比如旋转、裁剪、颜色变换生成了多个变体),这些由同一张原图衍生出来的变体,也绝对不能分散到训练集和验证集里——否则同样会造成"数据泄漏"。
• 如果数据集里某些类别的样本数量极少(这是第8节《长尾类别处理》要讨论的话题),随机划分还可能导致某个类别在验证集或测试集里"一个样本都没有",评测结果完全失真。

下一节,我们会系统讲解几种科学的划分策略——包括基于"分组(group)"的划分方法(确保来自同一来源的数据不会跨集合)、基于类别分布的"分层抽样(stratified split)"方法,并提供可直接运行的 Python 划分脚本,帮你在划分数据集的同时,自动检测并规避这些常见的数据泄漏陷阱。

写到这里,这一节也算是告一段落了。说实话,格式转换这个话题,讲起来可能不像模型结构、训练技巧那样"性感",但我始终觉得,数据工程的每一个环节做得扎不扎实,直接决定了后面模型训练的"地基"稳不稳。如果你跟着这一节,自己动手把代码跑了一遍、做了可视化校验,那么恭喜你——你已经掌握了一项能让你在任何"格式不兼容"的场景下都从容不迫的硬本领了。

最后,如果你在实际操作中,遇到了一些本节没有覆盖到的"非标准格式"或者特殊情况,欢迎在评论区留言告诉我具体是什么样的格式结构,我们可以一起讨论怎么扩展转换脚本的逻辑——毕竟数据工程这件事,案例永远比理论丰富,集思广益才能把"坑"填得更全。我们下一节,数据集划分策略,不见不散!

📌 附录

相关参考资料

• YOLOv10 官方论文：YOLOv10: Real-Time End-to-End Object Detection，Wang et al., 2024，arXiv: 2405.14458
• YOLOv10 核心机制：Consistent Dual Assignments（一致性双重标签分配）
• YOLOv10 端到端检测机制：One-to-Many + One-to-One Dual Assignments
• YOLOv10 高效模型设计：Holistic Efficiency-Accuracy Driven Model Design
• YOLOv10 NMS-Free 推理：End-to-End Object Detection without NMS
• DFL 相关：Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection
• COCO 数据集基准：https://cocodataset.org
• YOLOv10 官方仓库：https://github.com/THU-MIG/yolov10
• PyTorch 官方安装指南：https://pytorch.org/get-started/locally/
• NVIDIA CUDA Toolkit 归档：https://developer.nvidia.com/cuda-toolkit-archive
• Miniconda 下载：https://docs.conda.io/en/latest/miniconda.html
• 本节所有脚本代码：见文章各代码块，可直接复制使用

COCO:

希望本文围绕 YOLOv10 的实战讲解，能够在以下几个维度上切实帮助到你：

• 🎯 模型精度提升：结合 YOLOv10 的一致性双重标签分配、端到端检测机制与整体效率-精度设计思想，从网络结构、特征融合、检测头、标签分配、损失函数和数据增强等方向展开优化，通过工程实验进一步提升目标检测精度；
• 🚀 推理速度优化：结合 YOLOv10 的 NMS-Free 推理机制，以及模型轻量化、结构重参数化、剪枝、量化、知识蒸馏与部署加速策略，帮助模型在真实业务场景中运行得更快、更稳定；
• 🧩 工程落地实践：覆盖数据准备、环境配置、模型训练、效果评估、问题排查、模型导出与部署推理等完整链路，提供可直接复用或稍加修改即可迁移的工程级方案；
• 🧠 核心机制理解：深入分析 YOLOv10 中 One-to-Many 与 One-to-One 双标签分配机制、一致性匹配度量、端到端检测以及高效网络设计 的设计逻辑，帮助你理解模型性能提升背后的原因，而不是停留在简单调用层面；
• 🔬 改进方案验证：通过消融实验、指标对比与可视化分析，评估不同改进模块对 Precision、Recall、mAP、FPS、Latency、参数量和 FLOPs 的实际影响。

PS：如果你按照文中步骤对 YOLOv10 进行优化后仍然遇到问题，请不必焦虑或灰心。

YOLOv10 是一个涉及网络结构、特征提取、标签分配、梯度优化、端到端预测与部署环境的复杂目标检测框架，最终表现会受到 硬件环境、数据集质量、任务定义、类别分布、训练配置、代码版本与部署平台 等多重因素的共同影响。

这是目标检测项目中十分常见的客观现象，并不意味着某个改进模块一定无效。

如果你在实践过程中遇到以下问题：

• 🐛 模块替换后出现新的报错或 Bug；
• 📉 Precision、Recall 或 mAP 难以继续提升；
• 📈 训练损失异常、梯度不稳定或模型难以收敛；
• 🎯 One-to-One / One-to-Many 分支训练效果异常；
• ⏱️ 推理速度、Latency、显存占用或部署性能不达预期；
• 🔄 修改网络结构后出现维度、通道数或特征层不匹配；
• ⚙️ 修改检测头后端到端预测分支出现兼容性问题；
• 📦 模型导出 ONNX、TensorRT、OpenVINO 等格式时失败；

欢迎将 完整报错信息 + 环境版本 + 关键配置截图 + 网络配置文件 + 核心代码片段 粘贴至评论区，我们可以一起分析问题根因，并探讨更加可行的解决方案。

如果你已经摸索出更优的训练参数、网络结构、标签分配策略、模块组合或部署优化思路，也非常欢迎在评论区分享。

你的每一条实战经验，都可能成为其他开发者解决问题、减少试错成本的关键线索。

部分章节还会结合国内外前沿论文与 AIGC 大模型技术，对 YOLOv10 的主流改进方案进行重构与再设计，使内容更加贴近工业检测、智慧交通、游戏分析、行为识别、遥感影像、无人机视觉与边缘设备部署等真实应用场景。

## 🧧🧧 文末福利，等你来拿！🧧🧧

📌 文中所涉及的技术内容，大多来源于本人在 YOLOv10 项目中的一线实践积累，部分案例参考了开源项目、公开论文、技术社区资料与读者反馈。

如有版权相关问题，欢迎第一时间联系，我将尽快核实并进行修改或下线处理。

部分问题分析思路与排查路径参考了技术社区及 AI 问答平台，在此一并致谢 🙏

最后想说的是：

YOLOv10 的优化本质上是一个高度依赖任务、数据和部署环境的系统工程问题，不存在“一招通杀”的银弹方案。

一致性双重标签分配、One-to-Many / One-to-One 检测策略、注意力机制、轻量化卷积、改进检测头、IoU 损失函数、特征融合模块和数据增强策略，都有其适用条件。

某个模块在公开数据集上取得提升，并不意味着它能够在所有自定义数据集、硬件平台和业务场景中获得同样收益。

尤其对于 YOLOv10 而言，在进行结构改进时还需要额外关注 端到端检测分支、标签分配一致性以及 NMS-Free 推理链路。某些直接从 YOLOv8、YOLOv9、YOLOv11 等模型迁移过来的模块，如果没有处理好检测头与训练分支之间的适配关系，也可能出现精度下降、训练不稳定或推理逻辑异常等问题。

真正有效的优化路径，永远源于：

• 对业务目标与评价指标的准确理解；
• 对数据质量和类别分布的持续分析；
• 对模型瓶颈的定位与针对性改进；
• 对 One-to-Many 与 One-to-One 分支机制的正确理解；
• 对实验变量的严格控制；
• 对精度、速度、Latency、参数量和部署成本的综合权衡；
• 以及一轮又一轮可复现的对比实验。

如果你已经在自己的项目中探索出了更加高效、稳定的 YOLOv10 优化路径，非常鼓励你：

• 💬 在评论区简要分享核心思路与实验结论；
• 📊 分享不同模块的消融实验结果；
• 📝 将完整过程整理成教程、博客或系列文章；
• 🔧 提交可复现的配置文件、代码或工程实践经验。

你的经验，或许正是别人卡关已久所缺少的最后一块拼图。

✅ 本期关于 YOLOv10 优化与实战应用 的内容就先聊到这里。

如果你想进一步深入：

• 🔍 系统理解 Consistent Dual Assignments 与 YOLOv10 的整体网络结构；
• 🎯 深入理解 One-to-Many 与 One-to-One 双标签分配机制；
• 🚀 掌握 YOLOv10 无 NMS 端到端目标检测的实现原理；
• 🧱 学习主干网络、颈部网络、检测头与特征融合模块的改进方法；
• 📉 掌握损失函数、匹配度量、样本分配与训练策略的优化技巧；
• ⚡ 对比不同场景下的模型轻量化与部署加速方案；
• 🧪 建立规范的消融实验、指标对比与模型评估流程；
• 🧠 系统构建一套属于自己的 YOLOv10 调优方法论；

欢迎继续关注专栏：《YOLOv10实战：从入门到深度优化》

期待这些内容能够在你的项目中真正落地见效，帮助你 少踩坑、多提效、快验证、稳部署，我们下期见。

✨ 当然，如果 YOLOv10 专栏已经无法满足你，也可以继续关注：

• 《YOLOv9实战：从入门到深度优化》

• 《YOLOv11实战：从入门到深度优化》

• 《YOLOv12实战：从入门到深度优化》

更多新版本、新模块与新论文的工程复现内容，也会持续更新。

✍️ 码字不易，如果这篇文章对你有所启发或帮助，欢迎给我来个 一键三连：关注 + 点赞 + 收藏。

你的支持，是我持续输出高质量 YOLOv10 技术内容与工程实战案例最直接的动力来源。

同时诚挚推荐关注我的技术号： 「猿圈奇妙屋」

在这里，你可以：

• 📡 第一时间获取 YOLOv10、目标检测、多目标追踪与多任务学习等方向的进阶内容；
• 🛠️ 获取视觉算法、深度学习与模型部署的最新优化方案和工程实战经验；
• 📚 学习 PyTorch、OpenCV、ONNX、TensorRT 等相关技术；
• 🎁 获取 BAT 大厂面经、技术书籍 PDF、工程模板与常用工具清单等实用资源。

期待在更多维度上与你一起进步、共同成长。

👨‍💻 About Me · 关于作者

我是专注于 计算机视觉、图像识别、目标检测与深度学习工程落地 的讲师和技术博主，笔名 bug菌：

• 活跃于 CSDN｜稀土掘金｜InfoQ｜51CTO｜华为云开发者社区｜阿里云开发者社区｜腾讯云开发者社区｜开源中国｜博客园｜墨天轮 等多个技术社区；
• CSDN 博客之星 Top 30、华为云多年度十佳博主及卓越贡献奖获得者、掘金多年度人气作者 Top 40；
• CSDN、掘金、InfoQ、51CTO 等平台签约作者及优质创作者；
• 全网粉丝累计 30w+。

更多高质量技术内容与成长资料，可查看合集入口：

👉 点击查看 👈️

硬核技术号 「猿圈奇妙屋」 期待你的加入，一起进阶、一起打怪升级。

– End –