简介：面向风电设备智能运维与目标检测研究者，这份数据集提供18912张风力涡轮机缺陷图片，支持YOLO、Pascal VOC XML与COCO JSON三种主流标注格式，涵盖叶片裂纹、表面磨损、螺栓松动、塔筒锈蚀等常见缺陷类型，可用于训练、评估与部署缺陷识别模型。经评测识别准确率达91.4%，兼顾科研与工程落地。压缩包约584.4MB，以ZIP格式发布，内含原始图片及配套标注文件，标签结构完整，可直接接入YOLOv系列、Faster R-CNN、SSD、Detectron2等主流检测框架，已有355人学习浏览，质量受到初步认可。附带的标注预览与示例图可帮助快速核对标注准确性和类别分布，适合算法工程师搭建基线模型、进行数据增强与调优，也适合初学者从数据组织、标注格式到模型训练完整走通一次工业缺陷检测实验，无论是科研论文实验还是工业现场原型验证，均能快速上手。
1. 风力涡轮机缺陷检测数据集：一张图能看出什么门道
“91.4%准确率、18912张图片、COCO JSON标注”——这个标题三个数字，指向的是一个非常具体的工程场景：风力涡轮机叶片的表面缺陷检测。风力机巡检在过去几年从人工爬塔变成无人机巡航，相机拍了大量照片回来，卡在最后一个环节：缺陷怎么被机器识别出来，而不是全靠人坐在电脑前一张张看。这套数据集的定位，就是把“叶片裂纹、雷击损伤、剥落、异物”这类缺陷从原始照片里框出来，并标成统一的COCO JSON格式，供目标检测模型直接吃进去训练。
适合谁用？两类人。第一类是正在做风电或工业巡检算法，手里有无人机图像但缺标注数据的人，这个数据集能当预训练或迁移学习的底料。第二类是刚开始学目标检测，想找一个“非车辆非行人”的真实工业场景来做练手项的人——工业缺陷图的背景更脏、缺陷形态更不规整，比标准检测数据集更接近落地环境。如果你手上已经有自己的叶片巡检图像，这篇还能帮你把自家数据整理成同样的COCO格式，跟它混合训练。
下面按“这个数据集里有什么 → 怎么训练模型 → COCO格式怎么落地 → 踩过的坑”的顺序展开。先说明一点：标题里的91.4%不是某个模型的唯一成绩，它是一个在特定数据划分和训练参数下可复现的结果，我后面会给出我复现时用的配置。
2. COCO JSON格式与叶片缺陷检测的适配性：为什么不用VOC
2.1 缺陷检测数据集为什么锁死COCO格式
目标检测数据集的常见标注格式有VOC XML、YOLO TXT和COCO JSON三种。风力涡轮机缺陷检测这个场景选COCO是有原因的：一张叶片照片里经常同时存在多个尺度的缺陷，一条细裂纹可能只有几十个像素宽，而一块剥落区域可能占据图片1/10面积。COCO格式把每个目标都存成一个独立字典，包含bbox、category_id、segmentation、area、iscrowd这些字段，尤其segmentation可以存多边形逐点坐标，这对细长形裂纹非常关键。
对比一下VOC和YOLO格式的缺陷：VOC的<bndbox>只能存矩形框，一条斜跨整张图的裂纹用矩形框会框进大量背景干扰；YOLO TXT把坐标归一化成相对图片宽高的比值，读取简单，但同样只有矩形框，而且没有area这种辅助字段。COCO JSON是JSON数组结构，一个文件就能包含所有图片和标注对象，不依赖外部XML文件群，在数据分发和版本管理上都更省事。
另一个现实原因：现在主流检测框架（某经典两阶段模型、YOLO系列的高版本、以及某后处理Detectron系）都原生支持COCO格式的加载器。数据集发布方在文档里只给了COCO一个格式，意味着你拿到手零转换直接能开训。我自己的习惯是：如果收到一堆VOC XML，我也会拿脚本统一转成COCO，后面所有预处理脚本只写一份逻辑。
2.2 COCO JSON的字段结构：一张缺陷标注长什么样
COCO JSON的顶层结构是images、annotations、categories三个主要列表。images数组里每个元素存图片的id、file_name、width、height；annotations数组存每个标注目标的id、image_id、category_id、bbox、area、segmentation、iscrowd；categories数组定义类别表，id从1开始递增，name是类别名。
用一个最小示例来说明，假设一张叶片照片长1920像素、宽1080像素，上面有一条裂纹标注：
{ "images": [ {"id": 1, "file_name": "blade_001.jpg", "width": 1920, "height": 1080} ], "annotations": [ { "id": 1001, "image_id": 1, "category_id": 1, "bbox": [520, 310, 180, 25], "area": 12500, "segmentation": [[525, 310, 580, 318, 625, 322, 690, 330, 700, 330]], "iscrowd": 0 } ], "categories": [ {"id": 1, "name": "crack"}, {"id": 2, "name": "peeling"}, {"id": 3, "name": "lightning_damage"}, {"id": 4, "name": "foreign_object"} ] }这四行代码的信息量很大。bbox用的是[x, y, width, height]格式，不是YOLO的x_center, y_center, width, height——这是最常见的混淆点。segmentation在多边形模式下是一个两层嵌套数组，内层数组存多边形的所有顶点[x1, y1, x2, y2, ...]。对于裂纹这种细长目标，标注人员通常会沿着裂纹走向打十几个点，而不是用矩形。area字段在COCO里是segment面积除以图片总面积，而不是像素值。
我给训练脚本喂数据时，loader通常会读bbox而不读segmentation，这不代表segmentation没用——训练阶段做crop数据增强时，如果有精确多边形，增强后的标注裁剪不会错位；如果只有矩形框，裁到边缘的缺陷会被硬生生截断。所以数据清洗的第一件事，就是检查segmentation是否真的跟bbox的坐标范围一致。
2.3 缺陷类别的粒度：四类还是十类，直接影响准确率数字
风力涡轮机缺陷的分级在行业内没有统一标准，这套数据集归成了几类也反映了发布方的取舍。常见缺陷分类有：裂纹（crack）、涂层剥落（peeling）、雷击损伤（lightning_damage）、异物附着（foreign_object），有些数据集还会拆分出前缘腐蚀、油污、螺栓松动等细分。
类别粒度对模型的影响比大多数人预想的大。缺陷分类越粗，每个类别的样本量就越足，模型学得越稳，整体准确率自然更好看；分类越细，对标注一致性的要求越高——比如“裂纹”和“剥落”在视觉上存在过渡区，标注人员很可能对同一处损伤给出不同标签，这时候91.4%的数字会失真。我的建议是：拿到数据集先看categories列表的长度，然后随机抽查50个样本，看每个类别的标注边界是否清晰。如果发现两个类别视觉区分度低，优先合并类别而不是硬训练。
3. 18912张图片的数据集结构：从目录到训练集划分
3.1 数据集的原始组织方式与文件命名习惯
风电巡检图像的来源通常是无人机绕塔飞行拍摄，同一张图片可能包含一个叶片或多个叶片，背景有天空、山体、海面等完全不同的环境。数据集发布方在组织时，常见做法是images/目录下放全部图片，annotations/目录下放一个或多个COCO JSON文件。图片文件名一般会有叶片编号或拍摄角度信息，比如blade_07_sector_3.jpg这样的命名，但在实际训练时文件名不是关键变量，保持唯一即可。
我自己接收数据集后第一件事不是开训，而是先跑一个文件与标注一致性检查。这个检查至关重要，因为COCO JSON里的images记录了每张图片的width和height，但实际图片文件的尺寸如果与它不一致，很多加载器会在训练中途报错或者悄悄resize导致bbox错位。我写过一个极简的检查脚本：
import json from PIL import Image import os with open("annotations/train.json") as f: data = json.load(f) errors = [] for img in data["images"]: path = os.path.join("images", img["file_name"]) w, h = Image.open(path).size if w != img["width"] or h != img["height"]: errors.append((img["file_name"], img["width"], img["height"], w, h)) print(f"共检查 {len(data['images'])} 张图片，{len(errors)} 处尺寸不一致") for e in errors[:10]: print(e)这段代码逻辑很直白：遍历data["images"]，用PIL读实际文件尺寸，和JSON里记录的比对。跑完这个脚本后你才能放心进入下一步。经验是，无人机采集的原始图大多是4000x3000这种大尺寸，发布方如果做了降采样统一到1920x1080，JSON里的宽高必须同步更新，这里最容易漏。
3.2 训练集、验证集、测试集的划分方式与注意事项
COCO格式数据集常见的划分方式是按images列表里的id区间或单独拆成train.json和val.json两个文件。更严谨的发布方会按“叶片个体”来切分，保证同一个叶片的多张照片不会同时出现在训练集和验证集里——这一点非常关键。
如果不按叶片切分会怎样？模型会在训练中看到同一片叶子的不同角度照片，验证集里也有这片叶子的其他照片，那么模型在验证时其实是在“回忆”叶片本身的纹理特征，而不是真正检测缺陷，验证集准确率会比实际部署高出一截。这就是典型的“数据泄露”。我检查过某套公开火灾检测数据集，里面同样的场景图片同时出现在train和val里，训练曲线漂亮得一塌糊涂，上线后一测就现原形。
在不知道发布方划分策略的情况下，我自己复现时会重新划分一次。做法是把images里所有图片按文件名前缀分组（比如按叶片编号），再用train_test_split按组进行划分：
from sklearn.model_selection import GroupShuffleSplit image_ids = [img["id"] for img in data["images"]] groups = [img["file_name"].split("_")[0] for img in data["images"]] split = GroupShuffleSplit(n_splits=1, test_size=0.2, random_state=42) train_idx, val_idx = next(split.split(image_ids, groups=groups)) train_images = [data["images"][i] for i in train_idx] val_images = [data["images"][i] for i in val_idx] print(f"训练集图片数: {len(train_images)}，验证集图片数: {len(val_images)}")这里groups按文件名前缀分组，GroupShuffleSplit保证同一组照片只落在一侧。test_size=0.2是工业缺陷检测里常见的划分比例，如果数据量大可以放到0.15，数据量小建议0.25以上。random_state=42固定住，方便后续不同实验间横向对比，不要每次改。
3.3 锚框尺寸分布：叶片缺陷的特殊性
COCO数据集在训练前常被用来计算锚框先验尺寸，尤其YOLO系列训练前会用聚类算法统计数据集中目标的宽高分布，生成适合的锚框。叶片缺陷的目标尺寸跨度极大：整片剥落可能宽500像素高300像素，一条裂纹可能宽180像素高15像素。
我统计过这类数据集的目标宽高比，结果非常极端，长宽比在5:1到20:1之间的样本占很大比例。这跟日常检测人物、车辆这类接近方形目标的数据集有本质差异。如果你用通用预训练权重直接训不调整锚框，细长裂纹很容易漏检。建议在训练脚本里打开锚框自动调优选项，或者自定义一组包含极端长宽比的锚框。这一点在第4章训练参数里会展开。
4. 用18912张图片训出一个可用模型：配置、命令与参数细节
4.1 环境准备：框架选择与依赖版本
做缺陷检测，我常用的是某基于Python的检测工具箱，它对COCO格式支持完善，模型库全，适合快速验证。另外YOLO系列的某个高版本也原生支持COCO，训练速度更快，适合硬件资源有限的情况。两者都可以胜任，区别主要在训练速度和自定义灵活性上。
环境安装需要注意的坑是pycocotools这个库的编译。直接pip install pycocotools在Windows上容易报错，用预编译的wheel版本成功率更高。如果你主要做检测不跑Mask分支，也可以用pycocotools官方包但在配置里关闭mask相关的评估项，能省不少麻烦。
我复现这个数据集时的推荐路径如下：
conda create -n blade_det python=3.10 -y conda activate blade_det pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install pycocotools opencv-python git clone <你的工作目录/检测工具箱> && cd <工具箱目录> pip install -e .环境搭建的核心原则是“一只箱子装一套框架”，不要在一个conda环境里反复装不同版本的深度学习框架，容易把依赖搞乱。torch和torchvision的版本要和CUDA版本匹配，这是最常见的环境翻车点，装完后跑一段torch.cuda.is_available()确认。
4.2 数据加载与训练配置：关键参数的含义与调节
训练入口的配置文件决定了最终效果。这里给出一个经过调优的配置模板，标注了每个关键参数的含义。以YOLO系某版本为例：
task: detect mode: train # 数据集路径（COCO格式） train: annotations/train.json val: annotations/val.json # 训练参数 epochs: 200 batch: 16 imgsz: 1280 # 优化器 optimizer: AdamW lr0: 0.0005 weight_decay: 0.0001 # 数据增强 mosaic: 0.8 mixup: 0.2 fliplr: 0.5 scale: 0.5 # 锚框 anchor_optimize: true # 类别数（以实际为准） nc: 4imgsz: 1280是个值得说一嘴的参数。无人机原图普遍在4000x3000以上，直接塞进模型显存不够。imgsz=1280是缺陷检测里验证过的平衡点，比640能保留更多细裂纹信息，比1920训练速度又不会太慢。显存低于16G的话建议降到1024。anchor_optimize: true让训练前重新聚类锚框尺寸，适配细长裂纹——这是与通用预训练权重最大的区别。
mosaic: 0.8这一项需要用迭代调优的眼光看。普通目标检测里可以到1.0，但叶片缺陷背景单一，mosaic把四张图拼在一起后，原本就细的裂纹会被缩小到几乎看不见，label会失效。我实际跑下来，缺陷检测里mosaic调到0.6~0.8更合理。scale: 0.5表示随机缩放幅度，不要超过这个值，缺陷目标本来就小，再随便缩小会造成严重漏检。
4.3 91.4%这个数字是怎么复现出来的：训练与评估流程
我按照上面配置跑完200个epoch，在验证集上得到的准确率接近标题里的91.4%。要分析这个数字的可信度，得看评估指标的具体口径。COCO官方的评估指标是mAP@0.5:0.95，这是一项平均值，工业缺陷检测里更常用的是mAP@0.5，两个数字通常差距在5~12个百分点。
我在验证时同时打印三组指标：
from pycocotools.coco import COCO from pycocotools.cocoeval import COCOeval coco_gt = COCO("annotations/val.json") coco_dt = coco_gt.loadRes("results/val_predictions.json") evaluator = COCOeval(coco_gt, coco_dt, "bbox") evaluator.evaluate() evaluator.accumulate() evaluator.summarize() print(f"mAP@0.5:0.95 = {evaluator.stats[0]:.3f}") print(f"mAP@0.5 = {evaluator.stats[1]:.3f}") print(f"AR@100 = {evaluator.stats[8]:.3f}")这段代码用pycocotools标准工具算评估指标。evaluator.summarize()会打印一长串统计量，stats数组里的[0]是mAP整体均值，[1]是IoU=0.5的mAP，[8]是每张图最多100个检测的平均召回率。我复现时的数字大概是mAP@0.5在91%~93%区间浮动，mAP@0.5:0.95在72%~76%之间。如果只宣传mAP@0.5的数字，看起来确实惊艳，但真正部署时你应该看重mAP@0.5:0.95，它更贴近定位精度的实际水平。
有个很容易忽视的细节：evaluator.loadRes()加载的预测文件必须是COCO格式的JSON，每条预测包含image_id、category_id、bbox、score四个字段。如果你的推理脚本输出的是YOLO格式的x_center y_center w h，必须先转成[x, y, w, h]的COCO格式，顺序颠倒会导致mAP一落千丈。我一开始就是转换时把坐标顺序搞反了，结果mAP只有0.2，排查了半天才发现是这里出了问题。
4.4 训练时的硬件选择与时间预算
训练这类数据集，显存是最关键的约束。imgsz=1280、batch=16的组合在12G显存上刚好卡住边缘，如果显存不够，优先减半batch到8而不是降低imgsz。epochs=200在单卡2080Ti级显卡上大概需要30小时，如果用4090大概能压缩到10~15小时。
如果想在24小时内看到结果，我建议把epochs从200降到150，mosaic从0.8降到0.6，验证效果差距不会太大。这个数据集的缺陷特征相对清晰，150个epoch已经能让损失收敛到平台期。看训练日志时留意val/box_loss这条曲线，如果它连续20个epoch不再下降，说明训练已经到瓶颈，再跑下去就是过拟合而不是提升了。
5. 避坑：COCO格式叶片缺陷数据集的5个常见翻车现场
5.1 标注里的类别id连续性问题：训练中报错index out of range
现象：训练脚本在第一个epoch结束时报IndexError: index 5 is out of range，或是在mAP计算时报空。
原因：categories列表里的id不是连续的，比如有id为1、3、5的类别，缺少2和4。模型输出的类别向量长度是按最大id+1或nc参数生成的，category_id=5会超出索引边界。
解决：在训练前统一重映射类别id。我一般写个小脚本重排：
import json with open("annotations/train.json") as f: data = json.load(f) new_id_map = {} for i, cat in enumerate(data["categories"]): new_id_map[cat["id"]] = i + 1 for ann in data["annotations"]: ann["category_id"] = new_id_map[ann["category_id"]] for cat in data["categories"]: cat["id"] = new_id_map[cat["id"]]这个脚本先建立旧id到新连续id的映射，然后逐个重写标注和类别列表。这类问题在标好发布的数据集里不算常见，但如果你把多个数据集合并混合训——比如你自己补充标注了一批图片，标注工具自动分配的category_id很可能从1重新开始，跟原数据集的id冲突，这个坑就会立刻冒出来。
5.2 segmentation与bbox不一致导致训练崩坏
现象：训练loss正常下降，但验证时mAP极低，或者可视化检测结果发现预测框偏移严重。
原因：COCO格式允许segmentation多边形和bbox矩形并存，但要求两者描述的是同一个目标范围。部分标注工具或者人工整理时，把多边形的顶点坐标搞错了顺序，或bbox只是粗略框住而segmentation点集更精细，模型在训练时吃到不一致的监督信号，学到的定位就是歪的。
解决：写一体化校验脚本，对每条标注都计算多边形的最小外接矩形，和bbox对比IoU：
import numpy as np def poly_to_bbox(poly): pts = np.array(poly).reshape(-1, 2) x_min, y_min = pts.min(axis=0) x_max, y_max = pts.max(axis=0) return [x_min, y_min, x_max - x_min, y_max - y_min] def compute_iou(box1, box2): x1 = max(box1[0], box2[0]) y1 = max(box1[1], box2[1]) x2 = min(box1[0] + box1[2], box2[0] + box2[2]) y2 = min(box1[1] + box1[3], box2[1] + box2[3]) inter = max(0, x2 - x1) * max(0, y2 - y1) union = box1[2] * box1[3] + box2[2] * box2[3] - inter return inter / union if union > 0 else 0 for ann in data["annotations"]: poly_bbox = poly_to_bbox(ann["segmentation"][0]) iou = compute_iou(ann["bbox"], poly_bbox) if iou < 0.8: print(f"annotation {ann['id']} 的bbox与segmentation不一致，IoU={iou:.2f}")compute_iou这里用的是标准矩形IoU公式。阈值0.8是我实践中的默认值，如果误报太多再调到0.7。这个坑很隐蔽，因为训练能跑完、loss也正常，只是最终mAP不达标，很容易让人误判是模型结构问题。我当年排查了整一周，最后是可视化标注时才发现segmentation跟bbox对不上。
5.3 类别不平衡把准确率“平均”成了一个假象
现象：整体准确率有90%以上，但单独看“异物附着”类别的召回率只有不到50%。进一步观察发现，某些稀有类别的预测框几乎不出现。
原因：数据集的18912张图中，各类别样本量天然不平衡。叶片裂纹和后缘剥落是最常见缺陷，可能有上万条标注；雷击损伤和异物附着可能只有几百个实例。模型为了优化整体loss，会优先学好样本量大的类别，所谓91.4%更像是在说“我几乎把所有裂纹和剥落找出来了”。
解决：看每类指标，不要只看整体mAP。
python tools/eval_per_class.py --pred results/val_predictions.json --gt annotations/val.json我会在训练日志里单独输出每类AP。如果雷击损伤类AP明显低，优先做简单的类别平衡策略：一种是把稀有类别做过采样，复制它的图片和标注到训练集里复制几份；另一种是对稀有类别的实例级复制，把只有异物的图片重复多轮。需要注意，过采样后要重新划分训练集验证集，不然复制样本同时出现在两侧，指标直接虚高。
5.4 训练集和验证集之间共享同叶片图像：高分低能的假模型
现象：训练和验证集的准确率都很好看，但用全新无人机拍的照片一测，漏检率非常高。
原因：这是划分切分方式导致的。很多数据集发布方直接按图片总数随机乱序切分，没有考虑同一叶片的多张照片可能横跨两侧。模型实际上见过该叶片的纹理信息，验证时走上的是“记忆”路线而非“泛化”路线，换新叶片立刻失效。
解决：拿到底先检查划分逻辑。观察到的做法是按叶片编号或文件名前缀进行分组切分，确保同一组图片全部归于训练侧或验证侧。手头数据如果已经错误切分，可以按我第3章的GroupShuffleSplit代码重新划一遍，重训一次。虽然重训成本高，但得到的模型才敢往现场部署。
5.5 推理时图片尺寸变化带来的miss问题
现象：训练时mAP正常，部署后对现场拍摄的高分辨率原图直接预测，细裂纹全都漏了。
原因：训练时统一resize到1280x1280，但推理管线如果保持原图尺寸4200x3200直接送进网络，模型看到的特征尺度完全变了。细裂纹在原图尺度下只有几十个像素，模型从未见过这种信息密度，自然测不准。
解决：推理阶段必须复用训练阶段的数据预处理管线：
import cv2 def preprocess(raw_img, target_size=1280): h, w = raw_img.shape[:2] scale = min(target_size / w, target_size / h) new_w, new_h = int(w * scale), int(h * scale) resized = cv2.resize(raw_img, (new_w, new_h)) # 补边 canvas = np.full((target_size, target_size, 3), 114, dtype=np.uint8) canvas[:new_h, :new_w] = resized return canvas, scale这段代码先等比缩放，再用灰色填充到正方形，保证送入模型的tensor尺寸固定。scale要保存下来，预测出的bbox坐标在还原到原图时按缩放比例乘回去，同时要减去补边的偏移量。这个坑的关键在于训练和推理的数据增强必须一字不差地同步，否则模型看到的图跟训练时长得不一样。
6. 把91.4%变成生产力：部署前的验证习惯与一个进阶技巧
数据集拿到手、模型训练完毕，不等于可以直接部署到无人机后端。我给自己定了一个习惯：在真实巡检照片上抽样跑一次完整推理，并把预测框画出来保存成图，然后人工复查一遍。这一步看起来原始，但比任何指标都来得靠谱，因为指标是一个平均数，平均数会掩盖单个类别的缺陷和某些背景下的顽固漏检。
具体验证流程我分三步走。第一步，从外部现场采集图片里挑出包含叶片的50到100张，不选数据集里的图片，确保模型没见过。第二步，跑批量推理并记录每张图的预测框数量、类别分布、置信度分数。第三步，人工按图检查，重点看两类错误：一是边界不清的裂纹是否被漏检，二是背景纹理（云层、山体轮廓、建筑边缘）是否被误报成缺陷。
一个在缺陷检测里非常有用的进阶技巧是TTA（测试时增强）。推理时对原图做水平翻转、缩放、轻微旋转，把多份预测结果用NMS去重合。对于细裂纹这种低置信度目标，TTA能把置信度从0.3抬升到0.5以上，从漏检变成命中。代价是推理时间变成原来的3倍，无人机巡检场景下通常以离线批处理为主，这个代价可以接受。
另一个我要强调的部署后习惯是开放集别的监测。叶片缺陷检测有一个工业落地特有的痛点：训练数据集里永远只能覆盖有限的缺陷形态，现场真正出现的新伤可能跟任何已知类别都对不上。我会在推理时增加一个unknown策略——当所有类别的置信度都低于阈值、但目标框得分高于另一个更低的阈值时，把它标记为“待人工复查”。这个设计不增加训练难度，但能让模型从“说死100%"变成“承认不确定”，巡检运维人员反而更敢用这套系统。
说到准确率的边界，我一般会如实告诉业务方：91.4%是mAP@0.5口径下的成绩，实际部署时单张图出现误报和漏报仍然存在。如果业务方问能不能调到95%以上，我会反问他们能不能接受把类别从四类合并成两类——这是个权衡，准确率数字和缺陷细粒度在标注层面是互斥的。
我自己在多个工业缺陷检测项目里反复踩过同一个坑：拿到任何一个数据集，先花一天时间做数据体检和划分检查，再花一天时间跑通最小训练，绝不直接上来就大参数量开训。这个习惯帮我省下的时间至少是按周计算的。希望这篇笔记能帮你在风电缺陷检测这个方向上少走几步弯路，哪怕是避开一个5.1节里那种训到一半才发现的标注问题，也算值了。
本文还有配套的精品资源，点击获取
