64位OpenGL+GLUT环境配置与链接排错指南

简介：面向计算机图形学课程实验与OpenGL入门开发的64位GLUT库包，主要解决64位工程缺少匹配GLUT头文件与链接库、易出现32/64位不兼容的问题。包内共4个文件，以h头文件、dll动态库、lib导入库及keep占位文件为主，压缩包约127KB，体积轻便，便于纳入课程项目或本地图形实验环境。头文件提供GLUT接口声明，dll与lib分别支撑运行时调用和编译期链接，适合搭配OpenGL完成窗口创建、输入处理、菜单与基础几何绘制等练习。已有1785人学习，说明其在图形学初学者与教学场景中有一定参考度。对于需要快速搭建64位OpenGL-GLUT开发环境、排查链接配置问题的读者，这份库文件可作为基础组件，减少因库版本不匹配导致的编译与运行故障，帮助把精力集中在渲染流程与图形算法实现上。

1. 从 glut32.lib 链接失败说起：64 位 OpenGL 图形课环境到底差在哪

上个月有人拿着一个 OpenGL 实验工程找我，说代码一个字没改，换台机器就报LNK1104: 无法打开文件“glut32.lib”，把库名改成 glut64.lib 之后又变成LNK2019: 无法解析的外部符号 __imp____glutInitWithExit@12。这类 OpenGL + GLUT 的环境问题在计算机图形学课程里出现频率极高，根源往往不在代码，而在“位数”这两个字上——教材配套的 GLUT 是 32 位产物，而现在的 IDE 默认给你建的是 x64 配置。这份 64 位 GLUT 资源解决的正是这一段：提供能在 x64 工具链下正常编译链接的头文件、导入库和动态库，让第一次实验课不用耗在环境上。它适合三类人：要跑通课程实验的初学者、要复现老教材代码的人、以及只想快点看到那个黑色窗口出现几何体的人。下面按“包里有什么 → 怎么配 → 参数怎么调 → 哪里会翻车”的顺序拆。

2. 拆开这个 64 位包：头文件、lib、dll 三件套的分工与取舍

2.1 编译期与运行期：三件套到底谁管谁

很多人把这三个文件当成一个整体拷来拷去，出问题就说不清是哪一层挂了。实际上它们的职责边界非常清晰，先把这个理清楚，后面所有报错都能对号入座。

关键认知是：.lib在 64 位 Windows 下绝大多数是导入库，不是静态库。它只有几十 KB，里面是一个个跳转桩，告诉链接器“这个符号运行时要到 glut64.dll 里去找”。所以你把.lib加对了只能保证编译链接通过，.dll没放对位置照样一运行就崩，而且崩得比链接错误更难查。我一般会让学生先确认工程目录里是否同时存在这两个文件，再看编译能不能过，避免在一堆错误信息里混着排查。

.dll的搜索顺序也要留个印象：可执行文件所在目录 → 系统目录 →PATH环境变量里的目录。这个顺序决定了最省事的做法是把 dll 丢在.exe旁边，因为 IDE 调试时工作目录默认就是工程目录，x64\Debug\下生成的 exe 会去自己所在目录找 dll。

2.2 原版 GLUT 与 freeglut：64 位下为什么绕不开这个选择

原始 GLUT 由 Mark Kilgard 维护，最后一个广泛流传的版本是 3.7，早已停止更新，官方也没有提供 64 位二进制产物。市面上流传的“glut64 位包”基本都是社区重新编译的版本，另一条路是直接换成 freeglut——它是 GLUT API 的开源重实现，长期维护，且自带 x64 构建。

这两条路在 API 层面高度兼容，日常的glutInit、glutCreateWindow、glutDisplayFunc写法完全一致，差别集中在边角：

我在实际工程里更倾向 freeglut，理由是它的 x64 支持是“设计如此”而不是“凑合能用”，而且glutMainLoopEvent让主循环能被外部控制，写交互式作业时灵活得多。但如果你拿到的资源包就是重编译版 GLUT，也完全能用，只要记住一条铁律：头文件和 lib 必须来自同一家。第 5 章的第一个坑就是混用导致的。

2.3 三种落位方式，选项目内相对路径最稳

文件该放哪，这里有三种方案，按推荐度从高到低排。

第一种，项目内相对路径。在工程根目录下建third_party/glut/，里面分include/GL/和lib/x64/、bin/x64/。好处是整个文件夹拷给同学就能直接编译，不依赖任何全局配置。目录长这样：

your_project/ ├── src/ │ └── main.cpp ├── third_party/ │ └── glut/ │ ├── include/ │ │ └── GL/ │ │ └── glut.h │ ├── lib/ │ │ └── x64/ │ │ └── glut64.lib │ └── bin/ │ └── x64/ │ └── glut64.dll └── your_project.vcxproj

第二种，用户级目录，比如放在文档目录下统一管理，多个工程共用。缺点是换机器或换人就断了，交付场景不推荐。第三种，系统目录（把 dll 塞进System32），这是我最不推荐的做法。64 位程序读System32、32 位程序读SysWOW64，两个目录名字和实际位数的对应关系本身就是反直觉的，一旦塞错版本，全机器所有用到 GLUT 的程序都会以 0xc000007b 崩掉，而且卸载时极难清理干净。

提示：用相对路径时，IDE 里的“附加包含目录”和“附加库目录”要写成$(ProjectDir)third_party\glut\include这种带宏的形式，否则工程一挪位置就失效。

3. 在 Visual Studio 里跑通第一个 x64 窗口：配置、编译与第一帧

3.1 先切平台，再动手加库

这一步被跳过，后面所有配置都是白做。很多人一上来就加glut64.lib，结果链接时报LNK1112: 模块计算机类型“x64”与目标计算机类型“x86”冲突，或者干脆链接通过但运行时闪退。

正确顺序是：打开“配置管理器”（右键解决方案 → 配置管理器），把“活动解决方案平台”切到x64。如果下拉框里没有 x64，就新建一个，从 Win32 复制设置。切完再确认工程属性的“配置”是Debug还是Release——注意这里的库选择对 Debug/Release 并不敏感，因为导入库本身不含调试信息，两者可以用同一个.lib，但如果你手上还有别的静态库（比如自己写的数学库），就要分开了。

切完平台后，看一眼属性页顶部的“平台”字段，应该显示x64，而不是Win32。这个字段和解决方案平台是两个独立的下拉框，偶尔会不同步，血泪经验是每次改完都回头扫一眼。

3.2 包含目录、库目录、附加依赖项三步走

四个配置项都需要动，少一个都不行。全部在“项目属性 → 链接器 / C/C++”下：

三个库各有分工：glut64.lib提供窗口与事件循环，opengl32.lib提供核心渲染函数，glu32.lib提供gluPerspective、gluLookAt这类高层工具函数。后两个是 Windows SDK 自带的，正常情况下都有 x64 版本。如果报LNK1104: 无法打开文件“glu32.lib”，说明 SDK 安装不完整，重装或修复 SDK 组件即可，这不是 GLUT 包的问题，别在这里绕。

另外强烈建议在 Debug 配置下把子系统保持为控制台，因为 GLUT 初始化失败时往往只在控制台打印一行freeglut failed to open display之类的信息，窗口模式下看不到就没法查。

3.3 最小可运行骨架：初始化、回调、主循环

配置完之后先别急着写大作业，用一个旋转三角形的骨架验证环境。代码要能一口气跑通，任何多余的东西都先去掉。

// main.cpp —— 64 位 GLUT 环境自检骨架 #include <GL/glut.h> // 头文件来自 third_party/glut/include/GL #include <cstdio> static int gWinW = 800; static int gWinH = 600; static float gAngle = 0.0f; // 每帧渲染：清屏 -> 设置模型视图 -> 绘制 -> 交换缓冲 static void display() { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glLoadIdentity(); glTranslatef(0.0f, 0.0f, -5.0f); // 沿 z 轴后移，保证三角形在视锥内 glRotatef(gAngle, 0.0f, 0.0f, 1.0f); glBegin(GL_TRIANGLES); glColor3f(1.0f, 0.2f, 0.2f); glVertex3f(-1.0f, -1.0f, 0.0f); glColor3f(0.2f, 1.0f, 0.2f); glVertex3f( 1.0f, -1.0f, 0.0f); glColor3f(0.2f, 0.2f, 1.0f); glVertex3f( 0.0f, 1.0f, 0.0f); glEnd(); glutSwapBuffers(); // 双缓冲必须交换，否则看到的是空白 } // 窗口尺寸变化：重设视口 + 投影矩阵 static void reshape(int w, int h) { if (h == 0) h = 1; // 最小化时 h 可能为 0，防止除零 gWinW = w; gWinH = h; glViewport(0, 0, w, h); glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluPerspective(45.0, (double)w / (double)h, 0.1, 100.0); // 视场角/宽高比/近远裁剪面 glMatrixMode(GL_MODELVIEW); } // 定时器驱动旋转，interval 单位毫秒 static void timer(int /*value*/) { gAngle += 1.5f; if (gAngle > 360.0f) gAngle -= 360.0f; glutPostRedisplay(); // 标记需要重绘 glutTimerFunc(16, timer, 0); // 约 60 FPS } static void keyboard(unsigned char key, int /*x*/, int /*y*/) { if (key == 27) exit(0); // ESC 退出，原版 GLUT 没有平滑退出接口 } int main(int argc, char** argv) { glutInit(&argc, argv); // 必须先调用 glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH); glutInitWindowSize(gWinW, gWinH); glutCreateWindow("64-bit GLUT check"); glutDisplayFunc(display); glutReshapeFunc(reshape); glutKeyboardFunc(keyboard); glutTimerFunc(16, timer, 0); glutMainLoop(); // 阻塞，直到进程退出 return 0; }

逐段说明关键点。glutInit必须第一个调用，它负责解析命令行参数并初始化内部状态，argc/argv要原样传进去。glutInitDisplayMode的位标志决定帧缓冲格式，这里选了双缓冲 + RGBA 颜色 + 深度缓冲，缺GLUT_DEPTH的话后面开深度测试会全黑。glutCreateWindow之后才注册回调，顺序颠倒会让回调不生效，虽然不报错但窗口里什么都没有。glutMainLoop是阻塞式的事件循环，进去之后不会返回，这也是原版 GLUT 想退出只能exit(0)的原因。

reshape里那行if (h == 0) h = 1看似小事，但窗口最小化时确实会以 0 高度回调一次，宽高比算出来是inf，投影矩阵就废了，恢复窗口后画面直接变形。这个坑我在不止一个学生的作业里见过。

3.4 不想点属性页：命令行与 CMake 的替代路线

手点属性页容易漏，而且换台机器又要重来。工程要交付的话，用 CMake 描述依赖更省心，也能顺带把 x64 生成器写死。

cmake_minimum_required(VERSION 3.15) project(glut_demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 只允许 64 位构建，避免和 32 位库混在一起 if(NOT CMAKE_SIZEOF_VOID_P EQUAL 8) message(FATAL_ERROR "This project requires a 64-bit toolchain") endif() set(GLUT_ROOT "${CMAKE_SOURCE_DIR}/third_party/glut") add_executable(glut_demo src/main.cpp) target_include_directories(glut_demo PRIVATE "${GLUT_ROOT}/include") target_link_directories(glut_demo PRIVATE "${GLUT_ROOT}/lib/x64") target_link_libraries(glut_demo PRIVATE glut64 opengl32 glu32) # 构建后把 dll 拷到 exe 同级目录，省得手动复制 add_custom_command(TARGET glut_demo POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different "${GLUT_ROOT}/bin/x64/glut64.dll" $<TARGET_FILE_DIR:glut_demo> COMMENT "Copying glut64.dll next to executable")

生成方式：cmake -S . -B build -A x64，然后cmake --build build --config Debug。-A x64这个参数不能省，默认生成器在不少环境下仍然给 Win32。CMAKE_SIZEOF_VOID_P那个判断是保险丝，一旦有人用 32 位工具链配置，直接在最开始就报错，比链接阶段再炸出来好排查得多。POST_BUILD那段自定义命令把 dll 自动拷到输出目录，是这个脚本里最值钱的部分——手动复制 dll 是最高频的低级失误之一。

4. 窗口、回调与渲染参数：GLUT 里真正要调的只有这几组

4.1 glutInitDisplayMode 的位标志怎么选

这个函数的参数是一堆位或运算，选错了直接表现为黑屏、闪烁或者没有立体感。常用的几个：

一个很典型的翻车是：画了立方体，六个面看起来像贴在一起，转起来发现后面那面盖住了前面。原因就是忘了GLUT_DEPTH，深度缓冲根本没申请，glEnable(GL_DEPTH_TEST)自然无效。这类问题不要怀疑矩阵，先看显示模式。

GLUT_DOUBLE和glutSwapBuffers()必须成对出现。只加了双缓冲但忘了交换，看到的是第一帧之后就再也不变的画面；只交换但没加双缓冲，交换调用变成空操作，画面疯狂闪烁。

4.2 回调注册顺序与 reshape 的真实调用次数

GLUT 的回调注册本身没有严格顺序要求，只要在glutMainLoop之前完成即可。但有几个行为容易被误解。

glutReshapeFunc注册的回调在窗口创建后会至少被调用一次，即使你没有手动改变窗口大小。这意味着投影矩阵的初始化可以完全放在 reshape 里，不必在main里再写一遍。反过来说，如果你在main里设了投影矩阵，又在 reshape 里用另一套参数覆盖，最终生效的是后者，这种“两处都设”的写法很容易在调试时看花眼。

glutDisplayFunc回调里的绘制只在被标记为“需要重绘”时才触发。改变窗口大小、遮挡后恢复、调用glutPostRedisplay()都会触发。如果你的动画只在窗口拖动时才动，八成是定时器里漏了glutPostRedisplay()——这行是“请求重绘”，不是“立即重绘”，实际渲染发生在事件循环的下一轮。

glutKeyboardFunc只处理 ASCII 可见字符和少数控制键，ESC 对应 27。方向键、F1~F12、PageUp 这些要注册glutSpecialFunc，glutSpecialFunc的回调里拿到的不是 ASCII 码，而是GLUT_KEY_LEFT之类的常量。用键盘码判断方向键永远是错的。

4.3 定时器与帧率：glutTimerFunc 的精度边界

glutTimerFunc(毫秒, 回调, 传给回调的值)是最常用的动画驱动。单位是毫秒，但这个值不是硬实时保证，它只承诺“不早于这个时间”，实际延迟受系统调度影响，一般会多出几毫秒。

所以设 16 想跑 60 FPS，实测往往在 55~60 之间波动，做精确计时的话要在回调里自己读glutGet(GLUT_ELAPSED_TIME)算真实时间差，用时间差推进动画，而不是每次固定加一个角度。这两种写法的差别在慢机器上非常明显：固定步长会导致动画“加速”，基于时间的则是恒速。

glutGet(GLUT_ELAPSED_TIME)返回的是自glutInit以来经过的毫秒数，是个整数，精度足够做帧动画。另一个常用的是glutGet(GLUT_WINDOW_WIDTH)和GLUT_WINDOW_HEIGHT，在某些驱动下这个值和 reshape 传进来的值会有几像素差异，如果要做像素级精确的拾取（比如鼠标点选物体），以 reshape 的值为准更保险。

原版 GLUT 的定时器没法取消，一旦启动就会一直跑下去，直到进程结束。freeglut 里给glutTimerFunc传 0 可以停掉，或者用glutSetOption(GLUT_ACTION_ON_WINDOW_CLOSE, GLUT_ACTION_GLUTMAINLOOP_RETURNS)配合glutLeaveMainLoop()做干净退出。如果你的作业需要“暂停动画”功能，这点就是原版 GLUT 和 freeglut 的分水岭，得提前选好。

4.4 顶点数组与遗留管线：兼容模式下的边界

GLUT 本身只负责窗口和事件，渲染部分走的是 OpenGL。这份 64 位包里配的通常是 Windows 自带的opengl32.dll，它提供的是兼容上下文，版本上限一般到 1.1，加上扩展能摸到更高，但核心 profile 那套glGenVertexArrays是拿不到的。

这意味着两件事。第一，glBegin/glEnd这种立即模式可以放心用，教学代码全部基于这套写法。第二，如果作业要求用现代 OpenGL（着色器、VBO、VAO），光靠这份 GLUT 包不够，还需要 GLEW 或 glad 之类的加载器来取函数指针，因为opengl32.dll只导出 1.1 的函数符号，更高版本的入口点必须运行时查询。

即便如此，顶点数组（glVertexPointer+glDrawArrays，注意不是 VBO）在 1.1 里就有了，能显著减少函数调用次数。把几千个顶点从glBegin/glEnd改成顶点数组，帧率提升是肉眼可见的。这是个性价比很高的过渡手段：既不用引入额外依赖，又能把绘制循环从“每顶点一次函数调用”降到“一次调用画一批”。

5. 排错清单：64 位下最常见的五个翻车现场

5.1 LNK2019 找不到 __imp____glutInitWithExit@12

现象：库路径都配好了，编译时其他函数都正常，唯独启动相关的符号报无法解析，且符号名带__glutInitWithExit前缀。

原因：头文件和 lib 不是同一家。原版 GLUT 3.7 的头文件里，glutInit被宏定义成了__glutInitWithExit，目的是在退出时做清理；而 freeglut 的 lib 里导出的是标准名glutInit，没有这层包装。反过来，用 freeglut 的头文件配原版 GLUT 的 lib，会报找不到标准的glutInit。两种组合的错误信息不一样，但根子是同一个。

解决：确认include/GL/glut.h和lib/x64/*.lib来自同一个包。判断方法很简单，用文本编辑器打开头文件，搜一下有没有freeglut字样或GLUT_VERSION定义；再在命令行跑dumpbin /exports glut64.lib | findstr glutInit，看看导出的符号名带不带__前缀。两边对得上就没问题。

5.2 运行时报“找不到 glut64.dll”或 0xc000007b

现象：链接全过，F5 一按，弹窗提示缺少 dll，或者更糟——直接一个 0xc000007b 的应用无法正常启动，没有任何细节。

原因：两种可能。一是 dll 根本不在搜索路径里，IDE 调试时工作目录和 exe 目录可能不是同一个，取决于工程属性的“调试 → 工作目录”设置。二是 dll 的位数不对，把 32 位的 dll 放到了 64 位程序旁边。0xc000007b 这个错误码基本等价于“位数不匹配”，因为 64 位进程无法加载 32 位映像。

解决：第一步，把 dll 复制到 exe 所在目录（x64\Debug\），而不是工程根目录。第二步，确认 dll 位数，用dumpbin /headers glut64.dll | findstr machine，64 位会显示8664 (x64)，32 位显示14C (x86)。第三步，实在找不到就开 Process Monitor 过滤NAME NOT FOUND+.dll，看它到底在哪些目录里找过。

5.3 窗口出来了但一片空白，或者只有第一帧

现象：窗口标题正常，尺寸也对，就是里面全黑；或者能看到图形但拖一下窗口就变空白，再拖回来又好了。

原因：按发生频率排，第一是忘了glutSwapBuffers()，双缓冲下画面永远停在后备缓冲里；第二是缺GLUT_DEPTH或没调glEnable(GL_DEPTH_TEST)，深度测试开着但没深度缓冲，行为未定义；第三是投影矩阵的远近裁剪面设置不合理，几何体整个落在视锥外面，gluPerspective的 near 设成 0 更是典型的数学错误。

解决：先在最简骨架上加一句glClearColor(0.2f, 0.2f, 0.3f, 1.0f)，如果窗口变成深蓝灰色，说明渲染管线通了，问题在几何体或矩阵；如果还是纯黑，问题在缓冲交换。用这个二分法能在一分钟内定位到层。另外glGetError()在调试阶段值得每帧调一次，虽然它会拖慢性能，但能第一时间抓到“非法枚举值”这类静默失败。

5.4 Debug 配置能跑，Release 一运行就崩

现象：同一个工程，Debug 下一切正常，切到 Release 后要么启动崩溃，要么画面错乱。

原因：GLUT 的导入库本身和运行库模式无关，出问题的通常是两处。一是 Debug 和 Release 用了不同的输出目录，dll 只拷到了x64\Debug，Release 目录里没有；二是 Release 下编译器优化暴露了未初始化变量，典型的是全局的角度、位置变量没赋初值，Debug 下恰好是 0，Release 下是垃圾值。

解决：先把 dll 复制逻辑用 3.4 节的 CMake 命令自动化，从源头消掉第一类。第二类靠把glRotatef、glTranslatef的参数全部显式初始化来避免，同时在 Release 下把警告等级提到/W4，未初始化变量的警告会直接点出来。

5.5 高 DPI 屏幕下窗口模糊、鼠标坐标偏移

现象：在缩放比例 150% 的显示器上，GLUT 窗口被系统拉伸放大，画面发虚；做鼠标交互时，点击位置和绘制位置对不上，越靠右越明显。

原因：老版 GLUT 和 freeglut 的部分构建不声明 DPI 感知，系统会按 96 DPI 渲染再位图拉伸，文字和线段全糊。鼠标坐标方面，GLUT 的回调传的是窗口客户区坐标（左上角原点，y 向下），而 OpenGL 的视口是左下角原点、y 向上，两个坐标系没有做转换。

解决：鼠标部分的转换是固定的，glY = windowHeight - glutY，窗口高度取 reshape 存下来的值。DPI 部分，能在清单文件里解决就不要靠代码，给工程加一个带dpiAware的 manifest，或者在程序入口前调SetProcessDPIAware()，让系统按物理像素渲染。如果用的是自己构建的 freeglut 新版，通常已经内置了这块处理，换版本比打补丁更省事。

6. 从实验 demo 到课程大作业：一份能跨机器复现的工程骨架

骨架验证完之后，多数人要面对的是“怎么把三角形扩成一个像样的场景”。这里给一套我反复用过、交付时几乎不出问题的组织方式。

目录上，src/只放业务代码，third_party/放 GLUT 三件套，assets/放纹理和模型数据，全部用相对于工程根的路径引用。所有资源路径写成assets/xxx.png这样的相对形式，运行目录固定为 exe 所在目录，这样无论工程被拷到谁的机器上，只要目录结构不变就能跑。千万不要用D:\作业\xxx.png这种绝对路径，交上去必然加载失败。

渲染组织上，把每一帧的开关顺序固定成一套模板，顺序错了排查成本极高：

static void renderFrame() { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluPerspective(45.0, (double)gWinW / gWinH, 0.1, 200.0); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); gluLookAt(0, 2, 8, 0, 0, 0, 0, 1, 0); // 相机位置/注视点/上方向 glEnable(GL_DEPTH_TEST); // 先开深度测试再画不透明物体 glDepthFunc(GL_LEQUAL); drawOpaqueScene(); glEnable(GL_BLEND); // 透明物体放最后，且要关深度写入 glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); glDepthMask(GL_FALSE); drawTransparentScene(); glDepthMask(GL_TRUE); glDisable(GL_BLEND); glutSwapBuffers(); }

顺序上最容易错的是透明物体。如果先画透明再画不透明，透明部分的颜色会被后面的物体覆盖，看起来“透明失效”。正确做法是所有不透明物体画完再画透明，并且透明阶段关闭深度写入（glDepthMask(GL_FALSE)）但保留深度测试，这样透明面之间不会有前后遮挡错误。这个开关组合我建议直接背下来，比每次现场推要快。

光照的开关同理，glEnable(GL_LIGHTING)之后所有glColor3f都会失效，颜色改由材质决定，必须切到glMaterialfv设置。这个切换点经常成为“加了光照颜色全变灰”的原因，不是光照参数错了，是绘制代码还在用颜色函数。

交付前我一般会跑一遍这张表：

这份 64 位 GLUT 资源真正的价值不在于那几个文件本身，而在于它把“位数匹配”这个隐形的坑一次性填掉了，剩下的精力才轮得到图形学本身。从那以后我每次搭图形学环境，都强制先跑一遍最小三角形骨架，确认窗口、缓冲、定时器三条线全通，再去动真正的场景代码；跳过这一步直接上大作业，最后分不清是矩阵算错了还是库没配好，那种两头堵的滋味不好受。希望帮到你。

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