简介这套基于OpenCV与YOLOv8的实时车速检测和车辆跟踪系统项目面向计算机视觉与深度学习方向的毕业设计、课程设计可应用于交通监控、智能交通、道路安全管理等场景核心解决车辆识别、目标跟踪与动态测速的综合实现问题。资源共16个文件以Python源码、YOLO模型配置、TXT需求说明、XML工程配置及MP4演示视频为主压缩包约87.89MB目录内含代码、配置、说明与运行演示结构清楚便于按步骤还原项目。目前已有140人学习下载。内容覆盖从YOLOv8车辆检测、OpenCV图像处理到多目标跟踪、速度计算的完整链路同时给出依赖清单与核心入口代码演示视频可直观呈现车辆检测与测速效果。代码对检测、跟踪、工具与说明模块进行了分区支持本地视频输入方便二次开发与调参可快速验证不同场景下的检测跟踪结果。适合需要参考可运行完整方案、快速上手的开发者用于毕业设计、课设复现或研究目标检测与跟踪技术。1. 这个题目真正的难点不在检测模型而在跟踪和测速标定拿到“OpenCV和YOLOv8实时车速检测车辆检测跟踪系统”这类毕设题多数人第一反应是先跑通 YOLOv8 检测看到视频里能画出车辆框就觉得完成了大半。实际上检测只是这条流水线的第一公里。整套系统要解决三个递进的问题车在哪里、哪辆车是哪辆、这辆车开得多快。YOLOv8 解决第一个ByteTrack 这类跟踪器解决第二个OpenCV 负责视频解码、坐标换算和结果渲染最后把“目标位移除以时间”落成一个稳定的速度值。适合的人群很明确做毕设答辩需要现场演示效果、或想基于路侧摄像头做实时测速 Demo 的开发者。我先给结论检测模型不需要自己从零训练测速标定和跟踪 ID 稳定性才是让系统从“能出数”变成“数据可信”的分水岭下文按这条主线展开。2. 选型拆解与测速原理检测、跟踪、标定三层的取舍一个看似简单的“测速”动作背后至少叠了三层技术选择每一层选错了后面都要返工。检测层用 YOLOv8 基本没有争议跟踪层是 ByteTrack 还是 DeepSORT 需要想清楚测速层用虚拟线圈还是单目测距则直接决定你要写多少几何代码。2.1 检测层YOLOv8 的预训练权重、模型规格和 OpenCV 的定位YOLOv8 是 Ultralytics 维护的 anchor-free 目标检测框架backbone 里用 C2f 模块替代了之前的 C3neck 是 SPPF 加 PAN-FPNhead 直接预测目标的边界框和类别概率不再依赖 anchor 预设。相比 YOLOv5它在训练收敛速度和中小目标召回率上有明显提升对车辆这种中等尺度目标来说属于杀鸡用牛刀但也正因为如此你不需要为了毕设去复现网络结构直接用官方预训练权重做迁移即可。模型规格从 n、s、m、l、x 依次变大精度和推理时间同步上升。我的建议是默认用 YOLOv8s在 GTX 1660Ti 这种入门级显卡上640 输入分辨率能做到 30 FPS 以上精度比 YOLOv8n 高出一截又不会像 YOLOv8m 那样在 CPU 上直接卡死。如果你的演示机器没有独立显卡用 YOLOv8n 并配合后面要讲的跳帧策略才能保住实时性。OpenCV 在这个系统里不是“主角中的主角”但缺了它整个流程就断了。视频流读取用 cv2.VideoCapture模型输入前要把 BGR 转成 RGB检测结果要在原图上绘制矩形框和速度文本最后用 VideoWriter 把结果写成本地视频。更关键的是测速所需的像素坐标换算完全基于 OpenCV 的几何函数比如画虚拟线圈、计算中心点、做透视变换。换句话说OpenCV 负责所有“图像即坐标”的工作YOLOv8 负责把像素区域变成“有语义的框”。2.2 跟踪层为什么选 ByteTrack 而不是 DeepSORT检测模型每一帧都在独立工作不会知道上一帧的框和这一帧的框是不是同一辆车。跟踪器的任务就是给每个检测框分配一个跨帧稳定的 ID。常见方案有两个ByteTrack 和 DeepSORT。DeepSORT 在卡尔曼滤波之外还引入了一个 ReID 特征提取网络跨帧匹配时既要算运动相似度又要算外观相似度换来的好处是目标被遮挡后重新出现仍能找回原 ID代价是推理速度下降、配置复杂度上升。ByteTrack 的核心思路非常朴素高置信度框正常关联低置信度框也不直接丢掉而是放进第二次匹配里补救只靠 IoU 和卡尔曼预测位置做关联。它的作者在很多公开场景里证明了 ByteTrack 能在几乎不掉精度的情况下跑到 200 FPS 以上。对车速检测这个场景车辆是刚体、运动轨迹相对平滑、遮挡发生在车辆互相穿过时但很快会恢复ByteTrack 的 ID 稳定性已经够用而且不需要额外训练 ReID 模型毕设工作量能省下不少。对比维度ByteTrackDeepSORT是否依赖 ReID 特征不需要需要额外特征提取网络推理速度极快开销几乎可忽略较慢特征提取有额外耗时遮挡后恢复 ID一般靠 IoU 重新关联较强靠外观特征找回工程复杂度配置一个 yaml 即可需要加载 ReID 权重和特征匹配逻辑适用场景车辆跟踪、测速、人流计数跨摄像头追踪、需要长期 ID 保持的场景实际使用中我会在 ultralytics 的模型接口里直接指定 trackerbytetrack.yaml。这个配置里的 track_buffer 参数控制允许目标丢失多少帧后仍保留其 ID默认值 30在车速较快、目标经过画面只有几百毫秒的场景下建议调大到 60 左右否则检测短暂漏帧会让 ID 跳变直接影响测速。2.3 测速层虚拟线圈法和单目测距法的取舍检测和跟踪只是把车辆框了出来测速需要的是“物理世界里的距离和时间”。虚拟线圈法是最适合课堂演示和毕设的方案在画面上固定画两条线车辆中心点从第一条线到第二条线之间的时间差记为 t两条线对应的实际路面距离是提前量好的 d速度就是 d 除以 t。这里有一个关键换算画面上的像素距离必须映射到真实世界的米数。单目测距方案则是先标定相机内参、外参再把图像坐标投影到地面平面恢复每辆车的真实位置前后两帧位置差除以时间就是速度。听起来更“高级”但外参标定时摄像头每动一下就要重新标定而且车辆离摄像头远近不同时像素尺度会变化处理不好误差反而比虚拟线圈法更大。我的建议是答辩时想把工作量说厚可以在虚拟线圈法基础上补一个四点透视变换把路面区域投影成鸟瞰图这样既保留了虚拟线圈的简单性又能应对摄像头俯视角度带来的尺度偏差。标定的具体操作在视频画面里找到路面上的两个可识别点比如车道分界线的首尾、路灯间距、或者自己在路面上贴的标记物量出实际距离再算出一米对应多少像素。如果摄像头有较大俯角先在画面里选四个点围出矩形路面区域用 cv2.getPerspectiveTransform 得到变换矩阵把这一区域投射成正视图再在正视图上量距离。这样测速误差通常能控制在 5% 以内比直接拿斜视画面拍脑袋标定靠谱得多。3. 环境与工程骨架Ubuntu 20.04 CPU 版怎么搭项目怎么分层很多人的第一个翻车点不在算法在环境。尤其是“Ubuntu 20.04 搭建 YOLOv8 环境 CPU 版本”这个场景PyTorch 的安装源、OpenCV 的包冲突、模型权重的下载方式每一步都可能卡住半天。搭完环境后我强烈建议把工程按模块拆开否则后面调线圈位置、调跟踪参数都只能全文件搜索。3.1 Ubuntu 20.04 的 CPU 和 GPU 两套环境配置先用 conda 创建独立环境Python 版本选择 3.10。CPU 版本和 GPU 版本的区别只在 PyTorch 的安装方式上其余依赖完全一致。conda create -n yolov8 python3.10 -y conda activate yolov8 # CPU 版直接用默认 PyTorch 源或者清华源 pip install torch torchvision # GPU 版需要装 CUDA 11.8 对应的预编译包 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 共同依赖使用清华 PyPI 镜像加速 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple ultralytics opencv-pythonYOLOv8 本体就是 ultralytics 这个包安装后首次运行会自动下载 yolov8s.pt 权重。如果网络不好可以让已经装过的同学把权重文件直接拷贝到项目 weights 目录下避免反复下载超时。OpenCV 这里直接装 opencv-python 即可不要同时再装 opencv-contrib-python两个包会互相覆盖库文件轻则报警告重则 import 直接报错。另外需要注意的是opencv-python 默认不带 CUDA 加速但 YOLOv8 的推理走的是 PyTorch 的 CUDA不经过 OpenCV所以毕设场景完全没必要折腾 OpenCV 的 CUDA 版本也不用走到源码编译 OpenCV 那一步。3.2 项目目录结构建议把检测、跟踪、测速拆成独立模块vehicle-speed-system/ ├── main.py # 主循环读视频、调模块、渲染结果 ├── config.yaml # 模型路径、线圈位置、实际距离、视频源 ├── modules/ │ ├── __init__.py │ ├── detector.py # YOLOv8 检测与跟踪的封装 │ ├── speed_meter.py # 虚拟线圈测速逻辑 │ └── visualizer.py # 绘制检测框、线圈、速度文本和 CSV 落盘 ├── weights/ │ └── yolov8s.pt ├── data/ │ └── test_video.mp4 └── outputs/ └── result_video.mp4这样分层的直接好处是调线圈位置时只需要改 config.yaml 里的 line_a、line_b 坐标完全不用碰检测代码反过来想换模型权重时只改 model_path 一个字段。另一个好处是答辩时老师问“你系统怎么设计的”你可以指着目录说“检测、跟踪、测速是三个独立模块通过配置文件解耦”这句话在答辩现场很加分。3.3 想用自己的数据集训练标注、转换和训练的最小流程如果毕设要求“训练了自己的模型”或者你想把 COCO 预训练权重换成只识别车辆的定制模型走的路线是采集或收集车辆图片用 labelme 标注矩形框导出 YOLO 格式划分训练集和验证集修改 data.yaml跑 training 命令。YOLO 格式的标注内容是五个值类别索引、归一化中心点 x、归一化中心点 y、归一化宽度、归一化高度。labelme 导出的 JSON 需要转换一次网上有成熟的 labelme2yolo 小工具或者自己写几十行脚本也能完成转换。图片数量上做车辆检测二分类或者四分类1000 张以上标注图配合预训练权重微调效果就能达到可演示水平。# data.yaml 内容示意 # train: ./datasets/vehicles/train # val: ./datasets/vehicles/val # names: [car, truck, bus, motorcycle] yolo detect train modelyolov8s.pt datadata.yaml epochs50 imgsz640 batch16训练结束后runs/detect/train 目录下会生成 results.csv里面包含每一轮的 box_loss、cls_loss、dfl_loss 和 mAP50 等指标。想画损失函数曲线图直接用 pandas 读取这个 CSV 然后绘图即可这是论文实验部分最标准的一张图不需要自己手动记录训练日志。4. 代码主线从视频帧到速度值五段代码打通全流程这一章直接给能跑通的完整实现思路。代码我按模块拆分先给主循环和测速类的核心逻辑最后补渲染和落盘。你复制到项目里时按第 3 章的目录结构放即可不需要额外安装第 3 章之外的依赖。4.1 初始化模型与主循环model.track 的 persist 参数是跟踪开启的关键YOLOv8 的官方接口里model.track 比 model.predict 多做了两件事一是维护每个检测框的 track_id二是按 tracker 配置执行跨帧关联。persistTrue 表示跨帧保持跟踪状态这个参数漏了每一帧的 ID 都会重新编号。import time import cv2 from ultralytics import YOLO # 读取配置参数实际开发中建议把这些值写到 config.yaml VIDEO_PATH data/test_video.mp4 MODEL_PATH weights/yolov8s.pt CLASSES [2, 3, 5, 7] # COCO 类别索引car, motorcycle, bus, truck cap cv2.VideoCapture(VIDEO_PATH) model YOLO(MODEL_PATH) while cap.isOpened(): ret, frame cap.read() if not ret: break # 检测 跟踪同时完成boxes.id 就是跟踪器分配的车辆 ID results model.track( frame, persistTrue, # 关键参数开启跨帧跟踪 trackerbytetrack.yaml, # 使用 ByteTrack 配置 conf0.35, # 置信度阈值低于 0.35 的框丢弃 iou0.5, # NMS 的 IoU 阈值 imgsz640, # 输入分辨率 classesCLASSES, # 只检测车辆相关类别 verboseFalse, # 关闭控制台日志 ) # 某些帧可能没有检测到任何目标必须判空 if results[0].boxes is None or results[0].boxes.id is None: continue boxes results[0].boxes.xyxy.cpu().numpy() ids results[0].boxes.id.cpu().numpy().astype(int) for box, track_id in zip(boxes, ids): x1, y1, x2, y2 box # 这里只输出框坐标实际渲染和测速在 4.2、4.3 中完成 print(fID{track_id}, box({x1:.0f}, {y1:.0f}, {x2:.0f}, {y2:.0f})) cap.release() cv2.destroyAllWindows()这段代码的核心参数有三个persist 必须为 True否则跟踪 ID 不生效trackerbytetrack.yaml 让 ultralytics 读取内置的 ByteTrack 配置classes[2,3,5,7] 将检测范围限定在车辆类别避免行人误触发测速。conf 阈值的设置值得多说一句太高校准困难太低会出现大量误检框干扰跟踪0.35 到 0.4 是车辆场景下比较平衡的区间。4.2 虚拟线圈测速中心点状态机与时间戳换算测速模块是整个系统的核心。思路是维护每个 ID 的状态未跨线、已跨起始线、已锁定。只有从“已跨起始线”进入“已跨终点线”的那一次才计算速度计算完立刻锁定该 ID防止同一辆车被重复计数。import time class SpeedMeter: def __init__(self, line_a, line_b, distance_m): self.line_a line_a # 起始线的 y 坐标 self.line_b line_b # 终点线的 y 坐标车从上往下开时 line_b line_a self.distance_m distance_m # 两条线对应的实际路面距离单位米 self.state {} # ID - waiting / crossing / locked self.cross_time {} # ID - 通过起始线的时间戳 self.speeds {} # ID - 最终速度 def update(self, track_id, center_y, frame_time): # 新目标初始化 if track_id not in self.state: self.state[track_id] waiting self.cross_time[track_id] None # 已计算过速度的目标不再处理 if self.state[track_id] locked: return None # 尚未跨线先判断是否压到起始线 if self.state[track_id] waiting and center_y self.line_a: self.state[track_id] crossing self.cross_time[track_id] frame_time # 已压起始线判断是否压到终点线 elif self.state[track_id] crossing and center_y self.line_b: dt frame_time - self.cross_time[track_id] if dt 0.15: # 过滤同一帧内两条线同时触发的异常情况 speed_kmh self.distance_m / dt * 3.6 self.speeds[track_id] speed_kmh self.state[track_id] locked return speed_kmh return None这个类用 center_y 与两条线比较前提是车辆在画面中沿 y 方向运动。如果摄像头横着放、车辆从左往右开就把比较对象改成 center_x。dt 0.15 的判断是防呆设计当一条车辆在某一帧里同时压过两条线说明两条线距离在画面上太近或者帧率太低此时算出的速度会大得离谱直接丢弃比输出一个脏数据好。distance_m 的单位是米dt 单位是秒计算出的速度单位是米每秒乘以 3.6 转成千米每小时这是测速输出常见单位答辩演示也直观。4.3 渲染与落盘OpenCV 画线、写文本、保存结果视频主循环里把检测框、测速结果和虚拟线圈画到画面上同时用 VideoWriter 把处理后的视频保存下来方便写进论文实验部分。import csv import time import cv2 from modules.speed_meter import SpeedMeter # 初始化测速器line_a380 为起始线line_b430 为终点线 # 实际路面距离 12 米请根据你的摄像头画面重新标定 speed_meter SpeedMeter(line_a380, line_b430, distance_m12.0) # 准备输出视频和 CSV frame_w, frame_h int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)), int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)) writer cv2.VideoWriter(outputs/result_video.mp4, cv2.VideoWriter_fourcc(*mp4v), 20.0, (frame_w, frame_h)) csv_file open(outputs/speed_log.csv, w, newline, encodingutf-8) csv_writer csv.writer(csv_file) csv_writer.writerow([track_id, speed_kmh, timestamp]) while cap.isOpened(): ret, frame cap.read() if not ret: break # 在每一帧里做检测跟踪见 4.1 # 假设得到 boxes 和 ids for box, track_id in zip(boxes, ids): x1, y1, x2, y2 box cx, cy (x1 x2) / 2, (y1 y2) / 2 # 车辆中心点用于跨线判断 speed speed_meter.update(track_id, cy, time.time()) # 绘制检测框和 ID 标签注意 putText 不支持中文 cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) label fID:{track_id} if speed is not None: label f {speed:.1f}km/h csv_writer.writerow([track_id, round(speed, 2), time.time()]) cv2.putText(frame, label, (int(x1), int(y1) - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) # 画两条虚拟线圈红色是起始线黄色是终点线 cv2.line(frame, (0, 380), (frame_w, 380), (0, 0, 255), 2) cv2.line(frame, (0, 430), (frame_w, 430), (0, 255, 255), 2) writer.write(frame) cv2.imshow(vehicle speed detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() writer.release() csv_file.close() cv2.destroyAllWindows()OpenCV 的 putText 不支持直接渲染中文字符强行写中文会变成问号乱码。毕设演示界面如果非要中文可以用 PIL 先在内存里画好中文文本再贴到帧上但会增加不少代码量。我一般建议界面标签全部用英文答辩讲解时口头说中文即可省时省力。CSV 文件是论文数据的来源里面记录了每个 ID 的速度和出现时间后续做误差分析或画速度曲线直接读这个文件就行。5. 避坑记录测速结果从“能出数”到“能信”的五个问题这个项目最磨人的不是把代码跑通而是跑通之后发现数据没法用。我把自己和身边人做同类系统时踩过的坑整理成五条每条按现象、原因、解决三步写清楚你可以直接用这些问题自查。5.1 跟踪 ID 频繁跳变同一辆车算出了两个速度现象一辆车跨过两条虚拟线圈期间跟踪 ID 从 12 跳到 13速度被记录两次一次 60km/h、一次 45km/h看起来像两次独立测量。原因ByteTrack 的 track_buffer 默认只有 30 帧车辆快速通过画面时如果连续几帧检测置信度偏低、匹配失败缓冲区超限后跟踪器会判定目标丢失重新出现时分配新 ID。此外 conf 阈值设得太高会让车辆在阴影处短暂漏检同样是 ID 断裂的诱因。解决把 bytetrack.yaml 里的 track_buffer 调到 60 到 90同时将 conf 阈值降到 0.3 到 0.35确保目标短暂“消失”后还能被关联回来。如果车辆在远处只有几十像素大小建议把 imgsz 从 640 提到 800小目标检测率提升后跟踪稳定性会同步改善。5.2 CPU 机器跑 YOLOv8s 只有两三帧演示体验直接翻车现象在无 GPU 的笔记本上跑 yolov8s推理速度只有 2 到 3 FPS视频像幻灯片车辆跨线判断严重滞后。原因YOLOv8s 在 CPU 上的单帧推理耗时约 0.2 到 0.4 秒还要算跟踪和绘制无法达到实时。这不是代码 else 的问题是模型算力需求超出硬件。解决换 YOLOv8n参数量约为 YOLOv8s 的三分之一imgsz 从 640 降到 480推理时间进一步压缩。仍不行就采用跳帧策略每两帧做一次检测中间帧用卡尔曼预测框位置速度计算只看中心点的跨线时间不会因为中间帧不检测而失效。另一个思路是放弃本地 CPU把推理放到 RK3588 这类边缘设备上通过 ONNX 导出模型部署毕设做到这一步可以当作加分项写进论文。5.3 虚拟线圈的像素距离和实际距离标错测速出现系统性偏差现象所有车辆测出来的速度都比真实值高 10km/h 左右误差分布非常一致不是随机波动。原因像素到米的映射关系标错了。最常见的情况是在画面里随意选了两个点量距离但这两个点的连线在路面上并不是车辆实际行驶路径的方向或者摄像头俯角导致画面不同位置的像素尺度不一致直接用整张图的统一比例尺进行计算。解决先用四点透视变换把路面区域投影成鸟瞰图再在鸟瞰图上选线圈和量距离如果只是普通俯拍角度不大的情况至少选取路面中央、车辆实际行驶轨迹上的两个标记点用车道线虚线的间距或者路灯间距做参考多测几组取平均值不要拍脑袋填一个数。5.4 时间戳用帧数除以 FPS 代替真实时间速度值跳来跳去现象车辆明明匀速行驶计算结果却在 55 到 75km/h 之间反复横跳。原因视频文件或 RTSP 流在读取过程中会丢帧、解码延迟不稳定用 frame_idx 除以固定 FPS 得到的时间戳与真实时间存在偏差。尤其在系统负载高时模型推理耗时波动很大帧间间隔根本不是固定的 0.05 秒。解决跨线时间戳全部改用 time.time() 真实系统时间在每帧处理时记录当前时刻测速只依赖时间戳差值。这也解释了为什么代码里 speed_meter.update 的第三个参数传的是 time.time() 而不是 frame_idx 除以 FPS。处理离线视频文件时如果希望结果可复现可以在读取时就打印每帧对应的真实时间戳再回填到测速逻辑里。5.5 车辆变道或加塞时中心点偏移测速结果明显偏低现象一辆车从画面右侧斜着插到左侧跨越虚拟线圈时中心点走了很长的蛇形路径计算出的速度远低于实际值。原因虚拟线圈假设车辆沿线圈法线方向行驶实际行驶距离等于两条线之间的垂直距离。但车辆斜向行驶时真实路径长度大于两线圈的垂直距离而速度公式里用的是固定距离所以速度被低估。解决在跨线前后各取 5 帧中心点做均值平滑减少单帧抖动把线圈区域宽度拓宽让其覆盖整个车道宽度避免车辆压线瞬间因位置突变导致误判。如果检测区域有多条车道最稳妥的做法还是对路面做透视变换将斜视画面校正为正视图后再对每个车道分别布置虚拟线圈此时运动方向与坐标系正交距离误差被限制在最小。6. 从能跑到能答辩误差验证、状态机和边缘部署系统跑起来只是起点答辩时老师最喜欢追问的是“你这数据准不准”“误差从哪里来”。所以最后阶段必须补上验证环节并把代码里容易引起质疑的重复计数问题彻底修掉。6.1 用已知车速视频验证整套系统误差找一个相对空旷的路段用手机或摄像机固定机位录制一段视频同时让朋友以已知车速匀速通过两次一次 40km/h、一次 60km/h。跑完系统后把 CSV 里的测量速度和真实车速做对比算出平均绝对误差。最终结果表大概长这样测试序号实际车速(km/h)系统测量值(km/h)绝对误差(km/h)14041.31.326058.71.338083.23.2只要绝对误差稳定在 5km/h 以内答辩时拿出这张表格配合一段标注了实测速度的演示视频说服力远高于空口说“模型效果很好”。6.2 两个低成本升级点状态机锁车和边缘部署重复计数是虚拟线圈系统最容易在答辩现场出丑的问题。我用的方案已经在 SpeedMeter 里体现了就是 WAITING、CROSSING、LOCKED 三态状态机一个 ID 一旦计算出速度状态立刻转为 LOCKED后续任何帧都不会再触发计算。这比单纯用时间间隔过滤可靠得多因为它不依赖“这辆车是不是刚算过”而是直接绑定 track_id。如果还想往上走一步把模型导出为 ONNX再在 RK3588 或 NVIDIA Jetson 上通过 TensorRT 加速推理检测帧率能跑到 50 FPS 以上这时整个系统才真正接近可落地的路侧监控产品。我个人的教训是做这个毕设时花在“调模型”上的时间远少于“调标定和跟踪参数”那些在路面上量距离、观察 ID 跳变的下午才是系统从“演示能用”变成“数据可信”的关键。把标定的照片、量距离的过程和追踪 ID 的变化截图放进论文附录比贴一大堆训练曲线更有说服力。希望帮到你。本文还有配套的精品资源点击获取