企业官网建设流程全解析

简介：本资源是一个面向人工智能与计算机视觉方向学习者、智能驾驶系统开发者及高校科研人员的实战项目，聚焦驾驶员疲劳与危险行为（如闭眼、低头看手机）的实时检测与预警问题。项目基于YOLOv5实现高精度行为识别，结合DeepSORT完成鲁棒性目标追踪，构建端到端可运行的预警系统，适用于车载监控、ADAS辅助驾驶等实际场景。压缩包共58个文件，含20个核心Python脚本（如mydetect.py、myfatigue.py、main.py）、18个YOLO配置yaml文件（支持s/m/l/x多模型切换）、13个编译缓存pyc文件、1个Qt界面ui文件、1个预训练权重best.pt及1个面部关键点dat模型，另有演示视频MP4与Dockerfile等，整体大小110.68MB。已有510人学习下载，提供完整工程结构、可直接运行的GUI主程序、疲劳检测逻辑封装、YOLOv5+DeepSORT集成范例及实操演示视频，便于快速复现、二次开发与嵌入式部署验证。 做这个项目的起因，我自己跑过车队的安全监控项目，坐在监控室盯八个画面看一天，眼睛先受不了，更别说人脑注意力能撑多久。交通事故里导致重大伤亡的原因往往集中在两类：一是疲劳驾驶，二是分心行为——打电话、看手机、喝水、抽烟，哪个单独拎出来都是血淋淋的事故样本。所以我才把“基于深度学习的驾驶员分心驾驶行为（疲劳+危险行为）预警系统”这套东西认真做了一遍。整套系统选择了YOLOv5做目标检测、DeepSORT做目标跟踪，最终输出一个可直接落地的预警工程包。这篇文章就是把这个项目的完整技术链路、训练过程、踩坑记录和交付结构全部摊开来讲，适合正在做驾驶员状态监测、ADAS辅助功能、边缘端视觉部署的开发者参考。

1. 项目要做的事：分心驾驶预警系统的目标拆解

1.1 预警系统到底要解决什么

先说清楚这套系统不是“把YOLOv5跑通”就完事。它要处理的是连续视频流里的实时行为判断：司机有没有闭眼超过两秒、有没有连续打哈欠、有没有长时间低头看手机、有没有单手离开方向盘打电话、有没有点烟抽烟、有没有拿水杯喝水。

这些行为有一个共同特征——它们都是“短暂且非静止的”。如果你只是在单帧图片上做检测，那稍微一卡顿或者光线变化就会导致漏检、误检。这也是为什么标题里同时出现YOLOv5和DeepSORT：YOLOv5负责每一帧里把人、手、手机、水杯、烟等目标找出来，DeepSORT负责把这些目标在时间轴上连续绑定，让系统知道“这个打电话的人就是刚才那个司机”，从而统计行为持续时间，判断是不是真的发生了危险动作。

1.2 系统功能模块划分

从功能上拆，这套项目包含四个核心子模块：

• 目标检测模块：基于YOLOv5，检测驾驶舱内的司机、手机、水杯、烟、手部以及人眼和嘴巴状态。
• 目标跟踪模块：基于DeepSORT，对检测结果做ID分配与轨迹平滑，降低单帧误检。
• 行为判定模块：通过跟踪得到的轨迹和状态，结合疲劳判定规则（闭眼时长、打哈欠频率、PERCLOS）和分心行为判定规则，输出告警事件。
• 告警输出模块：输出到本地日志、HTTP接口、串口或语音播报，方便接入车队管理平台。

这些模块之间是串联关系：视频帧进来之后先检测、再跟踪、最后进规则引擎，任何一环出问题都会影响最终告警准确率。所以下面每个模块我都会讲实现原理和实际调试中容易忽视的点。

2. 为什么是YOLOv5+DeepSORT：检测与跟踪的技术选型逻辑

2.1 目标检测方案的取舍

做目标检测可选的方向太多了：传统图像处理、Faster R-CNN、SSD、YOLO系列、EfficientDet、DETR、YOLOv8。我最终选了YOLOv5，理由很实在：

一是生态成熟。YOLOv5的代码结构、权重格式、部署工具链（ONNX、TensorRT、TFLite）都是被社区反复验证过的，遇到问题基本都有现成答案。

二是速度与精度平衡。驾驶员监控的场景通常是30fps或者更高帧率的摄像头输入，推理速度必须跟上。YOLOv5s在RTX 3090上单帧推理只要十几毫秒，普通工控机上也跑得动，这是双阶段检测器很难做到的。

三是自定义类别灵活。驾驶员行为检测不是像COCO那样只分人、车、猫、狗，我需要把“手”、“手机”、“水杯”、“烟”、“闭眼”、“张嘴”这些特定小目标单独建模，YOLOv5的配置文件和数据集格式非常适合这套逻辑。

2.2 为什么必须加DeepSORT而不是只用检测器

很多人刚接触这个任务时会有疑问：既然YOLOv5已经能检测出司机和手机，那直接用检测框叠加判断不就行了？问题在于单帧检测结果不连续。实际摄像头画面里，司机的手可能因为运动模糊突然检测不到，手机可能因为角度变化从侧脸方向消失一两帧。如果只看单帧，系统会不断产生“有-无-有”的告警抖动，这种抖动在真实监控场景下根本无法用。

DeepSORT的作用有两个：

一是轨迹平滑。它通过卡尔曼滤波预测目标在下一帧的位置，并用匈牙利算法把当前帧检测框与已有轨迹关联匹配，这样即使某几帧检测失败，轨迹也能保持，不会出现ID频繁切换或目标“闪没”。

二是为行为判定提供时长数据。危险行为不能只看一帧，比如打电话，如果只是司机手从耳边滑过去，你也不能每次都报警。通过DeepSORT维护的轨迹帧序号，我能算出某个行为状态持续了多少毫秒，超过阈值才触发告警，这个逻辑在后面的规则引擎里非常重要。

2.3 DeepSORT与传统跟踪方案对比

这里顺便把DeepSORT和另外两种常见的跟踪思路做个对比。

项目中采用DeepSORT，还有一个原因是它内部集成了外观特征描述子（ReID），能利用目标的外观特征来区分同一类别的不同个体。在一个驾驶舱里通常只有司机一个人，但有时副驾驶也会入镜，这时ReID能明显降低把副驾驶误判成司机的概率。

3. 训练前的准备：环境、数据与标注

3.1 开发环境配置清单

先说环境，免得有人卡在第一步。项目开发环境我用的Ubuntu 22.04，Python 3.9，PyTorch 1.12，CUDA 11.6。显卡是RTX 3090，显存24G。训练时数据比较多，显存不够很容易爆，所以如果显存只有8G左右，建议用YOLOv5s或者更小的YOLOv5n，并且把batch size调低。

核心依赖建议直接按requirements.txt装：

• torch>=1.7.0
• torchvision>=0.8.0
• numpy
• opencv-python
• pillow
• pyyaml
• tqdm
• scipy
• seaborn
• matplotlib

DeepSORT部分额外需要：

• scikit-learn
• filterpy

安装没什么特殊技巧，唯一要注意的是PyTorch的CUDA版本必须和你机器上的驱动匹配。装好后可以用一条命令验证：

python -c "import torch; print(torch.cuda.is_available())"

如果输出True，说明环境没问题。很多人在“yolov5安装步骤”上卡壳，实际多数都是cuda和torch版本不匹配，或者缺少gcc编译组件。

3.2 数据集来源与核心数据处理

驾驶员行为识别最常用的公开数据集是State Farm Distracted Driver Detection，里面把驾驶员行为分成10类：

• c0: 安全驾驶
• c1: 右手发短信
• c2: 左手发短信
• c3: 右手打电话
• c4: 左手打电话
• c5: 操作收音机/中控
• c6: 喝水
• c7: 向后伸手
• c8: 整理头发和化妆
• c9: 和乘客交谈

这个数据集是图片分类格式，不是目标检测的标注框格式。如果要把它转成YOLOv5需要的检测数据集，需要先用预训练检测器（比如YOLOv5s在人脸、手部、手机等目标上）半自动生成标注框，再手动修正。

我的做法是直接把模型改造为“多层目标并行检测”：

• 检测目标1：驾驶员全身/上半身区域，用于确定“谁是司机”。
• 检测目标2：手、手机、水杯、烟等手持物体，用于分心行为判断。
• 检测目标3：人脸、眼睛、嘴巴，用于疲劳状态判断。

这三个目标不一定要放在同一个模型里训练，但强烈建议眼睛和嘴巴状态单独训练一个子模型，因为闭眼/打哈欠这种小目标的尺度特征和大目标差很多，放在同一模型容易训练不充分。

3.3 数据标注的实操细节

标注工具我用的LabelImg，输出YOLO格式的txt文件，每行格式是：类别ID 中心点x 中心点y 宽度 高度，坐标值都归一化到0-1之间。

标注时最需要注意的是遮挡和相似目标。标注“手机”时，如果手和手机高度重叠，我建议把手机作为独立目标标注，不要把手和手机合并成一个框。因为后续行为判定逻辑需要知道手机是否靠近耳朵或嘴部。手部如果严重遮挡，可以单独标注为“hand”，不需要细分左右手，但条件允许的话分左右手对判断打电话和发短信会有帮助。

疲劳数据方面，我用了YawDD打哈欠数据集作为基础，再补充自采的闭眼/睁眼数据。自采数据时让我自己坐在驾驶位，用普通USB摄像头拍了几十段视频，包括正常睁眼、眯眼、完全闭眼、张嘴打哈欠、说话时张嘴。然后把视频抽帧，逐帧标注出眼睛的“open”/“closed”状态和嘴巴的“open”/“close”状态。

标注一个容易忽略的点：同一批数据最好固定标注人员，或者两个人标注完再做交叉校验。否则同一个“眯眼”状态，不同人可能一个标成open、一个标成closed，训练出来的模型在阈值附近的样本上会很飘。

4. 训练驱动注意力的YOLOv5模型：参数配置与调优过程

4.1 训练文件配置与关键命令

我建了一个driver.yaml，用来指定数据集路径和类别名称：

train: /data/driver_dataset/images/train val: /data/driver_dataset/images/val nc: 10 names: ['safe_driving', 'text_right', 'text_left', 'call_right', 'call_left', 'operate_radio', 'drink', 'reach_behind', 'hair_makeup', 'talk_passenger']

主行为模型训练命令如下：

python train.py \ --img 640 \ --batch 16 \ --epochs 150 \ --data driver.yaml \ --weights yolov5s.pt \ --cache

这里cache参数表示将图片预先缓存到内存中，能够显著减少训练时频繁读盘造成的等待。img设为640是平衡速度和精度的经验值，如果摄像头画面里的人脸和手部占比较小，可以试试训练时用800左右，但推理速度会相应下降。

4.2 超参数调优的真正重点

YOLOv5的官方超参文件里有lr0、momentum、weight_decay、hsv_h等一堆参数。很多人喜欢直接去调这些，但实际上对训练结果影响最大的可能不是这些数值，而是数据本身和anchors设置。

训练自定义数据集时，一定要让YOLOv5自动重新计算anchors。系统会在训练开始时用k-means算法在当前训练集上重新聚类生成一组anchors。如果你不放心，可以手动触发：

python train.py --data driver.yaml --weights yolov5s.pt --noautoanchor

然后查看anchors生成结果，如果发现聚类出来的宽高比和你的小目标（比如眼睛、手机）相差很大，就要考虑是不是标注框精度的问题。闭眼这种小目标我建议用yolov5m甚至yolov5l模型，或者在检测层增设针对小目标的高分辨率检测头。

4.3 类别不均衡与过拟合处理

驾驶员行为数据里“safe_driving”和“talk_passenger”类别样本量会远超“drink”“reach_behind”等类别。直接训练会导致模型对少数类召回率很低。我的处理方式是：

• 对少数类做重复抽样，让每一轮epoch里少数类样本被重复看到。
• 调整YOLOv5损失函数中的类别权重，把少数类的cls loss权重适当调高。
• 数据增强时对少数类做更多的旋转、平移、裁剪变化，增加样本多样性。

训练过程中还要注意过拟合。我自己训练时，前80个epoch表现很好，到后30个epoch验证集mAP不升反降，这就是过拟合征兆。处理办法是设置early stopping patience，或者把mosaic增强在最后阶段关闭。YOLOv5的mosaic增强在末段可以设置为0，例如在训练脚本里动态调整：前80个epoch使用mosaic=1.0，后20个epoch改为mosaic=0.0，这样能让模型在接近真实分布上做最后的精调。

最终我的主行为模型在验证集上mAP@0.5约为0.93，打电话、喝水、抽烟这几类召回率都在0.88以上。这个精度其实还有提升空间，但已经满足实际告警需求了。

5. 疲劳检测子模块：闭眼、打哈欠与PERCLOS统计

5.1 疲劳检测的方案选择

疲劳检测不是简单“检测到闭眼就报警”，而是需要在一个时间窗口内综合判断。业界最常用的指标是PERCLOS（单位时间内眼睛闭合时间所占的百分比）。除此之外，打哈欠频率和连续闭眼时长也是重要辅助指标。

我采用双模型方案：

• 主模型：检测驾驶员行为类别。
• 疲劳子模型：检测眼睛（open/closed）和嘴巴（open/closed），区域由人脸检测框裁剪后送入小模型。

这样做的原因很简单：人脸区域的闭眼/张嘴状态在640x640的整体画面里太小了，直接在大图上检测小目标效果不好；先做face detection，再把眼睛嘴巴区域剪出来做状态分类，准确率高很多，也方便独立优化。

5.2 PERCLOS核心公式与阈值设定

PERCLOS的定义是统计一定时间内眼睛闭合帧数占总帧数的比例。公式：

PERCLOS = 闭眼帧数 / 窗口总帧数

针对驾驶员疲劳预警，我设置的判定规则如下：

具体实现时，我用了一个滑动窗口列表来保存过去60秒内每一帧的状态，窗口滑动更新。伪代码如下：

# 维护一个长度为窗口内期望帧数的队列 state_queue = deque(maxlen=1800) # 60s * 30fps def update_eye_state(is_close): state_queue.append(is_close) close_count = sum(state_queue) perc = close_count / len(state_queue) * 100 return perc

这个实现要注意取样间隔问题。不同摄像头帧率不同，如果队列长度固定而帧率变了，窗口实际覆盖的时间长度就不对。所以我建议用时间戳来计算而不是用帧数：记录每帧的眼睛状态和时间戳，统计时只取过去60秒内的记录。

5.3 打哈欠判定的细节

打哈欠检测我用的是嘴巴张开程度+持续时间双条件判定。当嘴巴检测为“open”且维持超过1秒，认为是一次哈欠；如果嘴巴只是快速说话、咳嗽，通常张开状态不会持续超过1秒。这里有一个实测中的坑：司机大声说话、唱歌时，嘴巴持续张开的时长很容易超过1秒，误报率明显上升。

为降低误报，我在判定哈欠时增加了“连续哈欠间隔”和“眼睛状态”两个辅助条件：如果同一时间窗口内眼睛没有持续闭合，就降低哈欠置信度；如果60秒内连续出现3次以上哈欠，才触发疲劳告警。这样比单纯检测一个“张嘴”动作可靠得多。

6. Deepsort接入的实战细节与跟踪稳定化

6.1 Deepsort跟踪的核心原理回顾

DeepSORT（Deep Simple Online and Realtime Tracking）是在SORT基础上的改进版本。SORT依靠卡尔曼滤波预测目标运动状态，再用匈牙利算法基于IOU关联检测框和已有轨迹。DeepSORT在其基础上补充了外观特征匹配，通过一个ReID网络提取目标的外观特征，计算特征之间的余弦距离，当IOU关联失效时仍然可以依靠外观特征把同一个目标对应上，解决目标遮挡后ID Switch的问题。

接入整个系统的流程是：

from deep_sort_pytorch.deep_sort import DeepSort deepsort = DeepSort( "weights/deepsort/ckpt.t7", max_dist=0.2, max_iou_distance=0.7, max_age=70, n_init=3, nn_budget=100 )

参数含义可以理解为：

• max_dist：特征最大余弦距离，超过这个值则认为不是同一个目标。
• max_iou_distance：关联时允许的最大IOU距离，太小了会丢失目标。
• max_age：轨迹最大保留帧数，超过该帧数仍未匹配则轨迹删除。
• n_init：轨迹需要连续匹配成功的帧数，达到后才认为轨迹有效。
• nn_budget：存放历史特征的样本数量。

实际运行中，我建议先把检测结果做置信度过滤，只保留高于0.5的框进入跟踪器，否则一些低置信度的误检框会污染轨迹，导致ID频繁跳变。

6.2 如何让跟踪结果服务行为判定

跟踪器输出的每个目标会带一个唯一ID，ID对应的轨迹上关联了目标类别、检测框、帧序号。在行为判定模块里，我需要把“手机”和“手”的关系、把“脸”和“眼睛状态”的关系都建立在“同一个目标/同一个区域”上。

一个实用的做法是：只保留跟踪器输出的“人”这个最大目标作为司机，并把该目标的人脸检测框位置与手、手机、水杯等目标做空间距离计算。

我定义了一个简单的关系判断逻辑：

# 判断手机是否靠近耳朵（是否在打电话） if phone_center and face_center: horizontal_distance = abs(phone_center.x - face_center.x) vertical_distance = abs(phone_center.y - face_center.y) if horizontal_distance < 0.15 * frame_width and vertical_distance < 0.2 * frame_height: potential_call = True

这个距离阈值要根据摄像头安装位置调整。后装DMS摄像头通常安装在方向盘上方或仪表台，手机放在耳边时和脸的水平距离很小，垂直距离略大；如果是放在大腿上看屏幕，那手机和脸的垂直距离会很大，不会被误判为打电话。

6.3 跟踪导致的问题与解决

第一阶段跑完，我发现跟踪器对“人”的检测框稳定，但对“手机”、“水杯”这种小目标的跟踪并不稳定，表现是ID频繁切换。原因是小目标的ReID特征不明显，而且运动幅度大。解决办法是我对非人体目标不做过长的轨迹关联，而是直接使用检测框做短时缓存。也就是说，只有“司机”这一主目标走完整DeepSORT流程，手机、水杯等小目标只做最近三帧的IOU关联。这样既保留了对主目标的稳定跟踪，又减少小目标ID切换给行为判定带来的干扰。

7. 系统联调、实测表现与误报排查

7.1 整体运行流程与告警规则

系统主程序跑起来后的流程是：

• 打开视频流或摄像头。
• 每隔一帧送入YOLOv5主模型，得到行为类别和检测框。
• 根据前一步输出的人脸框，裁剪眼睛嘴巴区域，送入疲劳子模型。
• 将检测框送入DeepSORT，获取目标轨迹。
• 行为判定模块结合轨迹、距离关系、时间窗口触发告警条件。
• 满足告警条件则输出告警信息并截图保存。

行为判定规则可以做成一个独立的JSON配置，方便现场调参。比如：

{ "call_duration_threshold": 3.0, "drink_duration_threshold": 3.0, "smoke_duration_threshold": 3.0, "eye_close_threshold": 2.0, "yawn_threshold_per_minute": 3, "perc_threshold": 40.0 }

这样去现场部署时，不需要改代码，只调配置文件就能适配不同客户对灵敏度要求不一致的情况。

7.2 实测数据：帧率、延迟与检测精度

我在自己的测试环境上做的实测结果如下：

帧率基本能满足实时处理需求。如果CPU环境部署，强烈建议把模型导出成ONNX，用OpenVINO推理，或者直接上TensorRT做INT8量化，这样才能在Jetson、RK3568这类边缘设备上达到实时效果。

7.3 实测中出现的误报场景与排查思路

误报是这类监控系统的生命线，误报率太高，客户就把系统关了。我遇到的误报场景以及排查思路大致如下：

一是副驾驶入镜干扰。后排坐人时，系统偶尔把副驾驶的脸当成司机。解决方法是划定驾驶区域ROI：根据摄像头安装位置和车内空间，把检测框中心点限制在预设的驾驶员座椅区域。超出区域的目标直接不进入行为判定。

二是司机摸脸、整理头发被误判为打电话。因为手部靠近脸部时，手和脸的相对距离满足“靠近”条件。我增加了一个前置条件：必须先检测到手机，并且手机框与脸部区域有交集，才判定为打电话。单纯手靠近脸不再触发。

三是喝水动作被识别为打电话。水杯和手机都是小目标，有时跟踪轨迹ID不稳定，导致水杯偶尔被当作手机。解决方式是把目标类别信息加入跟踪器的特征判断，只对同类目标做关联。

四是司机戴墨镜导致闭眼检测失效。夜间或逆光下，眼睛区域画面非常暗，疲劳子模型会把墨镜或阴影误判为闭眼。我针对这个场景增加了图像预处理：对裁剪出的眼睛区域做直方图均衡化，然后训练模型时会加入一些加了暗化增强的样本。但这个无法完全解决，最好的办法是使用带红外补光的DMS摄像头。

五是张嘴边说话误判为打哈欠。解决办法上面讲过，增加哈欠连续时长条件，并且看同一窗口内眼睛是否闭合，双条件综合判断。

7.4 告警截图与事件管理

实测中发现，逐帧告警没有意义，生产环境需要的是“事件”。所以我在告警输出层做了聚合：如果同一个ID在连续10秒内反复触发同类告警，只生成一条事件；事件里附带最清晰的一张截图、告警起止时间、行为类型和置信度。这样监控中心看到的不是刷屏的告警流，而是一条条可确定的事件记录，方便运输公司做安全台账。

另外，事件数据我同时以JSON格式输出到本地文件，并提供一个HTTP POST回调接口，便于接到已有车队管理系统。回调服务端如果5秒内没有返回200，客户端会重试三次，避免网络抖动导致事件丢失。

8. 交付文件说明与后续改进方向

8.1 zip压缩包结构解析

拿到压缩包后，先看目录结构：

driver-distraction-warning-system/ ├── README.md # 项目说明、环境安装、运行步骤 ├── requirements.txt # Python依赖清单 ├── models/ # YOLOv5相关模型定义文件 ├── utils/ # 数据处理、模型工具函数 ├── deep_sort/ # DeepSORT跟踪代码 │ ├── deep_sort.py # DeepSORT主模块 │ └── configs/ # 跟踪参数配置 ├── weights/ # 训练好的权重文件 │ ├── yolov5s_driver.pt # 主行为检测模型权重 │ ├── eyes_mouth.pt # 疲劳状态检测权重 │ └── deepsort/ # ReID模型权重 ├── data/ # 数据集配置和标注样例 ├── detect.py # 主程序入口 ├── rule_engine.py # 行为判定规则引擎 └── edge_export/ # ONNX/TensorRT快速导出脚本

weights里的模型文件是整个包的核心资产。detect.py运行前需要按README里提示修改视频路径或摄像头编号，以及配置文件里的参数。

8.2 二次开发方向：边缘部署与多传感器融合

这个项目做完之后，有几个方向值得继续深入。

第一个是边缘端部署。YOLOv5本身有很好的部署生态，把训练好的模型导出到ONNX，再用TensorRT转成engine文件，在Jetson Orin NX这类设备上可以做到30fps以上。INT8量化后模型体积和延迟都大幅下降，但要注意校准数据集的选择，如果用错了校准图片，精度会掉得厉害。

第二个是加入方向盘角度、车速、车道偏移等车辆CAN数据。视觉检测只能判断“行为动作”，但结合车辆动力学数据才能更准确判断“驾驶风险”。比如司机在高速上闭眼2秒，系统除了给出疲劳预警，还可以根据车速计算车辆在这2秒内行驶了多少米，自动提升告警等级。

第三个是接红外DMS摄像头。普通USB摄像头在夜间和逆光条件下对眼睛细节的捕捉非常有限，而疲劳检测极度依赖眼睛细节。带红外补光的DMS摄像头能极大提升夜间疲劳状态的检测准确率，这是实测中效果最明显的硬件升级。

第四个是把告警事件做成闭环管理。现在系统是单向输出告警，后续可以在事件管理平台上增加司机确认、管理人员审核、绩效考核等功能，形成一个完整的安全管理闭环。

8.3 我做这个项目的一些体会

整套系统从搭建环境到完成实测，最花时间的不是写代码，而是数据标注和阈值调优。代码层面YOLOv5和DeepSORT都是成熟框架，开箱即用；但真实场景里的灰尘、逆光、墨镜、副驾驶聊天这些变化，全靠数据质量和规则设计来兜底。如果是从零复现这个项目，我建议不要把精力花在魔改网络结构上，先把数据集做扎实，把规则阈值调成符合该项目实际场景的水平，效果提升会非常明显。

这个项目后面还可以继续扩展的地方很多，比如用时序模型（如LSTM或Transformer）对行为序列做建模，让系统不只是识别“单手打电话”这个静态动作，而是能预判“司机即将分心”的趋势。不过那属于进阶内容了，等这套检测和跟踪平台稳定跑起来之后再升级也不迟。

本文还有配套的精品资源，点击获取