企业官网建设流程全解析

简介：基于Python深度学习的人脸识别系统毕业设计项目，配套完整代码与文档说明，面向计算机专业学生，专门用于毕业设计、课程设计或期末大作业，也适合作为入门深度学习的练手项目。资源包内共103个文件，约20.98MB，文件类型覆盖Python源码（19个.py）、预训练模型（3个.hdf5，包括Xception和ResNet）、图像样本（png/jpg/jpeg）、XML配置、GIF演示、Word版手册等，各类型分工明确，压缩包结构一目了然。目前已有655人学习下载，热度稳定。项目围绕人脸表情识别展开，训练流程完整，支持FER2013、CK+、JAFFE等公开数据集；除模型构建与训练外，还包含数据标注、数据增强等关键环节演示，非常适合理解深度学习完整流程。文档说明配有代码注释与环境搭建指引，部署简单，运行流畅，界面美观，功能齐全，答辩或展示时可以直接演示，具有很高的实用参考价值。

1. 从“人脸识别系统”这个毕设题说起：它到底要你交付什么

每年毕业季都能看到大量“基于Python深度学习的人脸识别系统设计与实现”这类题目，很多同学拿到题第一反应是去GitHub找个开源项目改改界面，结果答辩时被问一句“你用的什么损失函数训练的”就卡壳。这个题目的本质不是让你复现一个大厂的刷脸产品，而是把一个完整工程拆成“数据采集、模型训练、系统集成、性能评测”四块，每一块都能讲清楚原理、亮出代码、给出实验数据。Python生态让这件事的入门门槛低到一台普通笔记本就能跑通，但真正让答辩组认可的分水岭，通常在于你有没有把阈值怎么定、误识率怎么测、模型为什么选这个不选那个这类细节讲明白。这篇笔记就按毕业设计最常见的交付路径，从方案选型讲到模型落地、再讲到那些只有真跑过才知道的坑。

2. 方案选型：为什么是深度学习，以及你的系统该拆成哪几个模块

2.1 传统方法与人脸识别早期的局限，以及深度学习解决了什么

早期的人脸识别系统很多基于LBP（局部二值模式）或Haar特征加SVM分类器，做法是先提取手工设计的纹理特征，再送进分类器判断身份。这种方案在光照稳定、人脸正对镜头的门禁场景下能跑到90%左右的准确率，但一旦出现侧脸、刘海遮挡、或者光线从头顶打下来形成半张脸阴影，特征就会剧烈跳动，识别结果变成玄学。深度学习方法则不同，它把“特征是什么样”这件事交给卷积神经网络去学，从原始像素直接映射到一个高维特征向量，同一个人不同照片的特征向量距离近，不同人的距离远，这一步把之前手工调特征的血泪经验全部抹平了。

对毕设而言，选深度学习不是因为它听起来高级，而是它有一个实打实的好处：公开的预训练模型非常多，你不必从零训一个几千万参数的卷积网络。以FaceNet类模型为例，一个在百万级人脸数据上预训练好的InceptionResNet或MobileFaceNet骨干网络，权重可以直接拿来做特征提取器，你只需要在它的输出层接一个分类头或者直接引用特征做比对，就能在实验室环境下获得足够好的识别效果。这也是我认为这个题目最稳妥的技术路线：不是“从零训一个CNN”，而是“用预训练模型做特征提取，再做比对和系统集成”。

2.2 系统模块划分：注册库、识别引擎、管理端三者缺一不可

一个能交给答辩组演示的人脸识别系统，至少包含三个模块。第一是注册模块，用户录入照片后系统把照片送入特征提取器生成一个特征向量（通常是128维或512维浮点数组），连同用户ID一起存进数据库。第二是识别模块，摄像头或图片输入经过人脸检测、对齐、特征提取三步，得到当前人脸的特征向量，然后和注册库里的所有特征做相似度比对，取最高分并判断是否超过阈值。第三是管理端，负责展示识别日志、管理注册用户、调整阈值参数。这三个模块如果都揉在一个脚本里硬写，后续想换模型或加功能会非常痛苦，我一般会用类封装特征提取器，用SQLite存特征和日志，再用Flask或PyQt做一层界面，模块之间职责清晰。

这里有个选型细节值得展开。人脸检测（把人脸从画面里框出来）和身份识别（判断框里是谁）是两个不同任务，很多新手混为一谈。检测可以用OpenCV的Haar级联，也可以用MTCNN、RetinaFace这类深度检测器；识别则用前面说的预训练特征提取器。毕设场景下我建议检测用RetinaFace或MTCNN，它们对侧脸和小人脸的召回率比Haar高不少，而且和后续对齐步骤能串成一条pipeline。如果你只是想在答辩现场用笔记本摄像头做实时演示，MTCNN加MobileFaceNet的组合在CPU上也能跑到每秒十几帧，足够流畅。

3. 数据集与预处理：先把你的人脸“对齐”了再谈识别的准确率

3.1 不要一上来就自己造数据：公开数据集与自采数据的搭配套路

很多做毕设的同学第一反应是拿手机拍十几个同学的照片做训练集，这很不现实。深度学习模型动辄需要几万张人脸才能训练出稳定的识别能力，单个学生的采集能力根本不够。常见的做法是两条腿走路：模型的特征提取部分用公开数据集（比如LFW、CASIA-WebFace或VGGFace2）预训练好的权重，你的自采数据只用来微调分类层或作为注册库和测试集。这意味着你不需要自己造一个大型训练集，只需要准备两类东西——一类是注册库照片，每个人三五张清晰正脸；一类是测试集照片，包含同一批人的不同角度、光照、表情照片，用来测准确率和误识率。

自采数据时有个容易被忽略的点：注册库照片的质量比数量重要。一张模糊的、反光的、口罩遮住下巴的照片进注册库，识别阶段根本没法救。我一般会拍一段视频再从视频里抽帧，每张采样间隔0.5秒并改成统一尺寸，这样拿到的同一人多张照片在角度和表情上会有自然差异，特征向量也会更稳定。千万不要用同一张照片复制粘贴成“三张”——那在特征层面完全重复，起不到丰富注册库的作用。

3.2 人脸对齐为何是避免模型翻车的“后悔药”：检测到关键点后的裁剪与归一化

人脸识别流程里，对齐这个步骤经常被赶进度的同学直接跳过，后果是识别准确率莫名其妙掉好几个点。人脸对齐的目标是把眼睛、鼻子、嘴角这些关键点标准化到大致相同的坐标位置，消除头部姿态和图像旋转带来的差异。MTCNN或RetinaFace跑完检测后，会同时输出左眼、右眼、鼻尖、左嘴角、右嘴角一共五个关键点坐标，接下来说话的代码就是用仿射变换把这五个点映射到一个标准模板上。

import cv2 import numpy as np def align_face(image, landmarks, output_size=(112, 112)): # 标准模板坐标：参考ArcFace论文中的五点在112x112图像上的位置 dst = np.array([ [38.2946, 51.6963], [73.5318, 51.5014], [56.0252, 71.7366], [41.5493, 92.3655], [70.7299, 92.2041] ], dtype=np.float32) src = np.array(landmarks, dtype=np.float32).reshape(5, 2) # 计算仿射变换矩阵：输入是检测到的关键点，目标是模板坐标 tform = cv2.estimateAffinePartial2D(src, dst, method=cv2.LMEDS)[0] aligned = cv2.warpAffine(image, tform, (output_size[0], output_size[1])) return aligned

这段代码里最关键的是dst模板坐标，它来自ArcFace论文，112×112是人脸识别领域最常用的输入尺寸之一。estimateAffinePartial2D用的是LMEDS方法，能在部分关键点检测不准时剔除离群点，比普通的最小二乘拟合鲁棒很多。warpAffine做完之后，人脸的眼睛基本保持在水平方向，尺寸也被统一，后续送入特征提取器时就不会因为尺度差异产生偏差。操作里还有一个容易被忽略的参数：output_size必须和你的特征提取器训练时的输入尺寸一致，MobileFaceNet用的是112×112，FaceNet的InceptionResNet用的通常是160×160，对不上会导致精度明显下降。

对齐做完后我还习惯做一次像素归一化，常见做法是把像素值缩放到 [-1, 1] 区间。以PyTorch为例就是(image / 255.0 - 0.5) / 0.5，这一步是为了让输入分布接近预训练模型见过的分布。

3.3 数据增强为什么只做一半：离线增强与在线增强的分工

数据增强是深度学习训练里绕不开的手段，但人脸识别场景下它的用法和其他图像分类不太一样。分类任务可以对整张图做随机旋转、翻转、色彩扰动；人脸识别如果用同样的增强过头了，反而会让模型学歪——比如上下翻转一张人脸，在语义上它就不是一张正常的人脸了。我一般只保留水平翻转、小角度旋转（正负15度以内）、亮度对比度微调和高斯噪声，并且把增强放在在线阶段，也就是每次迭代随机变换，而不是预先在硬盘上生成一大批增强后的图片。

离线增强适合你自采的数据量特别少且需要扩充注册库人脸数量的场景。比如每个人只有两张照片，想扩充到八张，可以把每张做水平翻转、旋转5度和-5度、亮度调高和调低，这样确实能增加注册库的覆盖度。但要明确一点：增强出来的样本和原始样本在特征空间里高度相关，它能让识别更稳定，却不能让模型突然学会识别一个从未见过的人。真正决定模型泛化能力的还是预训练权重本身。

在线增强的实现不复杂，PyTorch里用torchvision.transforms把几个变换组合起来即可。这里想强调的是，毕设论文里数据增强部分通常要写一段实验对比，说明“用了增强和不用的准确率差异”，所以不要只在代码里默默加上，记得留一组不加增强的对照组数据用于写分析。

4. 模型训练与识别引擎：从加载预训练权重到特征比对的完整链路

4.1 选骨干网络和损失函数：MobileFaceNet配ArcFace为什么是“最不折腾”的组合

骨干网络的选择直接决定你的系统是能在CPU上跑、还是必须配一张昂贵显卡。毕设演示环境如果只是普通笔记本，我强烈建议优先考虑MobileFaceNet或MobileNetV2这类轻量网络，它们在保持不错精度的情况下，单张112×112人脸的推理时间在CPU上可以控制在30到50毫秒。反过来，ResNet50这类大网络精度确实更高，但CPU推理速度会掉到每秒几张图，实时演示会很尴尬。

损失函数这块，人脸识别最常用的是ArcFace，它是在Softmax基础上做的改进，核心思想是给类别特征加上角度间隔，让类内更紧凑、类间更分离。如果你用的是ArcFace预训练权重，输出层通常不是一个几百人的Softmax分类器，而是一个512维的特征向量。你需要关注的是编码方式和归一化——特征层一般会做L2归一化，比对时用余弦相似度。很多开源权重包里会附带完整的模型定义和加载脚本，毕设时不必自己手写ArcFace损失，而是理解它的作用，然后用现成的权重做特征提取。

4.2 训练自己的分类头：让系统认识“你实验室里的那些人”

预训练模型的骨干参数通常不需要重新训练，你要做的是把它的输出层换掉，用你自己的注册人员数据做微调。这一步的典型做法是加载预训练权重，冻结所有卷积层，只训练最后的全连接分类层；如果数据量足够多（比如每人50张以上），也可以解冻最后几个卷积层做整体微调。对毕设而言，冻结训练是最稳妥的，一是训练速度快，二是不会因为数据少把小样本类别的特征学偏。

import torch import torch.nn as nn import torch.optim as optim from torch.utils.data import DataLoader, Dataset from torchvision import transforms class FaceRecognitionModel(nn.Module): def __init__(self, backbone, embedding_size=512, num_classes=20): super().__init__() # 去掉backbone原来的分类层，保留特征提取部分 self.backbone = backbone self.embedding = nn.Linear(embedding_size, embedding_size, bias=False) self.head = nn.Linear(embedding_size, num_classes) def forward(self, x, return_embedding=False): feat = self.backbone(x) feat = nn.functional.normalize(feat, p=2, dim=1) # L2归一化 if return_embedding: return feat return self.head(feat) # 加载预训练权重，只保留不含分类层的部分 backbone = torchvision.models.mobilenet_v2(pretrained=False) # 这里换成你实际下载的ArcFace/MobileFaceNet权重文件 checkpoint = torch.load("mobilefacenet_arcface.pth", map_location="cpu") backbone.load_state_dict(checkpoint["state_dict"], strict=False) model = FaceRecognitionModel(backbone)

代码里的load_state_dict(..., strict=False)是一个必须注意的细节。预训练权重通常包含完整的分类层参数，而你自定义的模型中head的num_classes和原来不一样，用strict=False可以忽略不匹配的层。模型前向传播时做了两步：先过骨干网络拿到一个512维向量，再做L2归一化，这样特征是单位向量，余弦相似度就直接等价于点积，后续比对阈值更容易设置。训练分类头时，输入图片按112×112对齐裁剪，标签是每个人的ID，用交叉熵损失优化，学习率建议从1e-3起步，跑10到20个epoch就能收敛。

训练完成后，你要把self.head丢掉，只保留self.backbone和self.embedding，因为推理阶段我们不需要分类输出，只需要特征向量。这一步很多新手会忘记，导致保存模型后加载报维度错误。

4.3 特征比对与阈值设计：误识率与拒识率这对“跷跷板”

识别引擎的核心就是一个数据库查询问题：把当前人脸特征和库里所有人脸特征做余弦相似度，取最高值。关键是这个最高值要大于多少才判定为“同一个人”。阈值设高了，陌生人会被拒之门外，但同时也会把注册过的熟人误拒；阈值设低了，常见情况是任何人都能刷脸通过。这就是误识率（FAR）和拒识率（FRR）之间的跷跷板关系。

我建议在完成训练后专门做一轮阈值标定实验：准备一张包含注册人员和非注册人员的测试集，把相似度从0.3到0.8每隔0.05扫一遍，统计每个阈值下的误识率和拒识率，画出曲线后取交点或根据应用场景取一个倾向值。门禁场景通常更看重低误识率，阈值取0.6到0.65；办公打卡场景则更看重便捷性，阈值放到0.5到0.55也能接受。这个实验数据放在毕业设计论文里是非常好的“系统性能分析”部分，一定要留截图和表格。

5. 系统集成：把模型装进一个能演示的人脸识别门禁系统

5.1 用SQLite做注册库：特征向量序列化时最容易翻车的格式坑

识别引擎调通后，下一步是把代码串成一个系统。注册库我用SQLite，单文件、零配置、答辩时可以直接把数据库文件拷到演示电脑上。建表逻辑很简单，一张用户表存ID和姓名，一张特征表存用户ID和特征向量，但特征向量的存储格式有讲究。

import sqlite3 import numpy as np def save_feature(user_id, feature_vector, db_path="face.db"): # feature_vector 是 numpy 数组，float32 的512维向量 conn = sqlite3.connect(db_path) # 使用BLOB存原始二进制，比存文本JSON快而且省空间 blob = feature_vector.astype(np.float32).tobytes() conn.execute( "INSERT OR REPLACE INTO features (user_id, embedding) VALUES (?, ?)", (user_id, blob) ) conn.commit() conn.close() def load_all_features(db_path="face.db"): conn = sqlite3.connect(db_path) rows = conn.execute("SELECT user_id, embedding FROM features").fetchall() # 读取时必须用 np.frombuffer 恢复成 numpy 数组 features = {} for user_id, blob in rows: features[user_id] = np.frombuffer(blob, dtype=np.float32) conn.close() return features

这段代码里最值得说的坑就是np.frombuffer。如果你用np.load或直接把numpy数组转成列表再存JSON，加载回来时dtype可能会从float32变成float64，特征维度对不上、比对结果全乱。用BLOB存原始字节，读写都走.tobytes()和.frombuffer()，只要保证 dtype 一致，就不会出现这种莫名其妙的问题。还有一个细节：SQLite的INSERT OR REPLACE需要预先在user_id字段上建唯一索引，否则同一个用户反复注册会累积多条旧特征，导致识别时一个人对出两个ID。

5.2 摄像头实时识别的循环结构：抽帧比逐帧处理更省CPU还能保持流畅

实时识别如果对摄像头每一帧都做完整的人脸检测加特征提取，CPU很快就会被占满，系统界面也会卡顿。常见的做法是异步抽帧：摄像头线程以较高帧率抓帧并放进队列，识别线程每隔100毫秒左右从队列取最新的一帧做一次完整识别。这样画面是流畅的，识别也不会滞后到让人等半秒以上。

import cv2 import queue import threading import time def capture_loop(cap, frame_queue): while True: ret, frame = cap.read() if not ret: break if frame_queue.qsize() < 2: # 队列里只保留最新帧，避免堆积 frame_queue.put(frame) def identify_loop(frame_queue, model, threshold=0.6): while True: frame = frame_queue.get() faces = detect_faces(frame) # 用MTCNN或RetinaFace检测 for box, landmarks in faces: aligned = align_face(frame, landmarks) embedding = model.get_embedding(aligned) user_id, score = match_user(embedding, threshold) if user_id: draw_result(frame, user_id, score) cv2.imshow("Face Recognition", frame) if cv2.waitKey(1) & 0xFF == ord('q'): break

frame_queue.qsize() < 2这个条件是为了让消费者永远拿到比较新的帧，而不是处理积压的旧画面。如果队列里已经有一帧还没处理完，新的帧就不放了，直接丢旧换新。这种做法在长时间运行时能保证内存不涨，也不会因为摄像头帧率高于识别速度导致延迟越来越大。实际演示时这个线程模型能带来很直观的体验提升——画面流畅，识别结果一出现就能看到。

5.3 管理端UI选得简单反而加分：Flask做Web界面比Tkinter演示更显工程完整度

毕设里的人脸识别系统到底该用桌面GUI还是Web界面，取决于你的题目描述偏向“系统设计”还是“算法研究”。如果题眼强调“系统设计与实现”，我建议用Flask做一个轻量Web页面，展示实时识别画面、注册人员管理、识别日志查询三个页面。好处是前后端分离的思路能写进论文，而且评审演示时用浏览器打开比在桌面上弹出一个Tkinter窗口更有“系统感”。

Flask后端不用承担模型推理，推理进程可以单独跑，通过共享数据库和Web服务通信。识别线程把每次识别结果（时间、用户ID、相似度分数）写入SQLite的日志表，Web端读日志表按时间倒序展示。这样做的解耦效果是：摄像头识别服务挂了或者没启动，Web页面照样能看历史记录和管理用户，不至于一个异常让整个演示崩掉。

6. 避坑与排查：这些坑我替你踩过了，出现同样现象时直接照这个流程查

6.1 特征向量维度对不上：报错总是模棱两可的“size mismatch”

现象是加载预训练模型后，第一次跑前向传播就报维度错误或者输出特征长度和论文对不上。原因通常是加载模型时没有注意原权重输出特征维度是512还是128，或者backbone被替换后最后的全连接层输出尺寸与预期不一致。解决方法是打印模型结构核对最后一层输出维度，如果你的backbone是从MobileNetV2改造来的，注意MobileNetV2原始分类层输出是1280，需要再接一个Linear映射到512，很多开源实现这一步命名方式不同，加载权重时用strict=False后容易悄悄丢掉这一层，导致输出变成1280维。

6.2 识别准确率在演示现场突然崩塌：光照是最大变量再加追不上的人脸检测

现象是实验室里测得好好的，搬到答辩现场就频繁误识或拒识。原因多半出在检测环节而不是识别环节：现场灯光从侧面打过来，MTCNN把人脸框得偏了，对齐后关键点错位，特征向量直接跑偏。解决方法是不要只依赖单帧检测，连续三帧检测框的位置和大小变化超过一定阈值就视为不稳定，等稳定了再取帧做特征提取。另外，如果现场有显示器或玻璃反光，试着调整摄像头角度避免直射光源，这是最便宜的后悔药。

6.3 SQLite并发写冲突：“database is locked”的尴尬瞬间

现象是识别线程和Web线程同时往日志表写数据时，偶尔报database is locked。原因是SQLite默认对跨连接并发写支持有限。解决方法是让所有数据库操作集中在同一个连接里，或者给写操作加一个重试装饰器。我一般用后者，代码并不多但对体验提升明显。

import sqlite3 import time from functools import wraps def retry_on_locked(func): @wraps(func) def wrapper(*args, **kwargs): for _ in range(5): try: return func(*args, **kwargs) except sqlite3.OperationalError as e: if "database is locked" in str(e): time.sleep(0.05) continue raise return wrapper

time.sleep(0.05)的间隔给其他线程释放锁留出时间，重试五次基本能覆盖全部冲突。如果还不行，就把数据库改成WAL模式，读写并发能力会好很多。

6.4 训练损失降了但识别依然差：检查你是否跳过了最关键的L2归一化

现象是微调时训练集准确率99%，但实际测试相似度分数普遍偏低或偏高。原因很常见：训练阶段特征做了L2归一化，推理阶段却拿未归一化的特征去做余弦相似度计算，或者相反。解决方法是强制规定统一流程：特征提取器输出的向量必须先做normalize再存库、再比对，训练和推理两个阶段都要保持同一套归一化逻辑。可以把归一化写进模型源码的forward里，不要留给调用方去手动处理，从根上杜绝这种不一致。

6.5 长时间运行后内存不断上升：queue使用不当让老帧堵死了系统

现象是演示跑了十几分钟后系统越来越卡，最终画面定格。原因是识别线程处理速度跟不上摄像头抓帧速度，队列越积越长，帧对象一直不释放。解决的思路已经在前面的代码里体现过：入队前判断队列长度，超过阈值就丢弃旧帧。这个看起来简单的qsize() < 2判断，是长时间运行系统里最值得写的一行防御性代码。

7. 进阶：把识别精度“量化”出来，顺便把推理速度再压一档

模型跑通、系统稳定之后，想让这份毕设从“能跑”升级到“能答辩”，最有效的一件事是做一个正式的评估实验。我习惯的做法是留出一批独立测试照片，每张都标注真实身份ID，然后遍历所有阈值，画出一条ROC曲线，横轴是误识率，纵轴是真正率。论文里用这条曲线说清楚“本系统在误识率为1%时拒识率是多少”，比任何一段文字都更有说服力。具体操作是写一个评估脚本，把测试集里所有人脸两两比对，记录所有同人对和异人对的相似度分数，然后按阈值统计两类错误率。

def evaluate_thresholds(embeddings, labels, thresholds): # embeddings: dict, key是图片ID, value是特征向量 # labels: dict, 图片ID对应的真实身份 from sklearn.metrics import roc_curve import numpy as np ids = list(embeddings.keys()) scores, y_true = [], [] for i in range(len(ids)): for j in range(i + 1, len(ids)): sim = float(np.dot(embeddings[ids[i]], embeddings[ids[j]])) scores.append(sim) y_true.append(1 if labels[ids[i]] == labels[ids[j]] else 0) fpr, tpr, _ = roc_curve(y_true, scores) return fpr, tpr

roc_curve直接帮你把每个阈值下的误识率（FPR）和真正率（TPR）算出来，你只需要把特征向量和标签整理好。这里有一个实际建议：测试集不要只包含“正脸且光照均匀”的照片，额外加入戴眼镜、低头、逆光这类难样本，让曲线里的差异更明显。只有两张照片对出来的得分属于“同人对”，很容易把阈值标定带偏。

另一件值得做的事是把推理压到更小更快，为论文里的“系统性能”部分添一笔。常见做法是启用ONNX Runtime加速：把训练好的模型导出成ONNX格式，跨平台而且CPU上推理速度比PyTorch原生快一截。导出时用torch.onnx.export设opset_version=11，固定输入尺寸112×112，动态轴只保留batch维。转完后用onnxruntime.InferenceSession加载，跑起来你会发现CPU占用明显下降，实时识别帧率可能从12帧涨到20帧以上。注意ONNX导出时如果需要L2归一化也一并导出，尽量把模型的后处理包含进去，避免在外部用numpy再手动算归一化引发精度差异。

还有一个更朴素的优化手段：把视频帧从BGR转换到RGB的时机提前。摄像头读到的是BGR格式，人脸识别模型训练时用的是RGB，如果每帧都在循环体内做cv2.cvtColor会被重复调用，可以把转换挪到预处理线程里跟缩放一起做，或者在模型内部用torchvision.transforms组合好。这些优化单独拎出来都只是几毫秒的提升，但合在一起，答辩演示时“丝滑感”会非常明显。

这套方案整体走下来，数据、模型、系统、评测全链路都有了，投入的时间成本集中在第一次处理CUDA安装和预训练权重下载上。我用类似架构带过好几届毕业设计，最深的体会是：这个题目的翻车点从来不是深度学习本身，而是特征归一化不一致、阈值凭感觉拍脑袋、以及对齐步骤被跳过这类“看着小、影响大”的细节。如果你时间紧张，至少把阈值标定实验和ROC曲线做了——它既是论文里最亮眼的数据，也是你答辩时最理直气壮的底牌。希望这篇笔记能帮你少走几步弯路。

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