企业官网建设流程全解析

简介：这份资源面向使用VSCode搭建OpenGL开发环境的C++初学者，以LearnOpenGLForVSCode项目为模板，将GLFW、GLAD依赖库下载、编译器选择、include/lib路径配置等分散步骤，整合为一个可直接编译运行的工程骨架，帮助开发者绕过环境配置中的常见坑，无论是自学还是课程实验都能降低起步门槛。压缩包共17个文件，体积仅440KB，内容涵盖main.cpp示例源码、glad/GLFW/KHR相关头文件、libglfw3.a静态库、glfw3.dll动态库，以及c_cpp_properties.json、tasks.json、launch.json三个VSCode关键配置文件，分别控制编译器路径、构建任务和调试器；Makefile提供自动化构建入口，main.exe可快速预览输出，main.o等中间文件则直观呈现了编译产物。已有357人学习下载，适合图形编程入门者在Windows平台快速上手。资源还保留了.gitignore等工程细节，读者既可以对照源码与配置理解VSCode运行C++的机理，也能在此模板上继续扩展纹理映射、光照模型等进阶实验，是兼顾实践与学习的轻量级参考。

1. 用 VSCode 搭建 OpenGL 环境：为什么一个 zip 包能省掉一整晚

“用 VSCode 搭建 OpenGL 环境”，十个字看着简单，动手就会发现它横跨四件事：编译器选型、GLFW 下载、GLAD 生成、VSCode 三个配置文件的联动。每一项单独看都有教程，串在一起却处处打架——MinGW 路径带空格导致命令转义失效，glad.c 忘了参与编译导致一堆 undefined reference，glfw3.dll 没复制到 exe 旁边直接弹出找不到入口。标题里的 LearnOpenGLForVSCode.zip，要解决的正是这一整条链路。下文按选型、配置、链接、排错、进阶的顺序拆完这套方案，适合刚看完 LearnOpenGL 前几章、正卡在第一个窗口的读者，也适合想从 Visual Studio 切到轻量编辑器的开发者。

2. 开工前先选型：MinGW-w64、GLFW、GLAD 怎么凑成一套

2.1 编译器选型：为什么这里选 MinGW-w64 而不是 MSVC

VSCode 不负责编译，也不负责调试，它只负责把命令交给外部工具链。Windows 上做 C/C++，常见路线是 Visual Studio 的 MSVC 工具链和 MinGW-w64 的 GCC 工具链两条。如果你已经装了 VS，用 MSVC 当然没问题，但代价是 tasks.json 里的命令需要从一个带 vcvars 环境变量的窗口里启动 cl.exe，否则编译器找不到 Windows SDK 头文件。GLFW 预编译包里那套 msVC 库目录，也只有在这种环境里才认得出来。

所以当你面对的是“VSCode + OpenGL”这个组合时，我一般直接选 MinGW-w64：解压到 C 盘根目录，把C:\mingw64\bin加进 PATH，tasks.json 直接调 g++，GLFW 预编译包也对应lib-mingw-w64那个目录。整条工具链没有环境变量窗口的依赖，写起来最顺手，这也是类似 LearnOpenGLForVSCode 这类免 CMake 方案里最常见的中层选择。

版本别太旧。OpenGL 代码本身只要 C++11 就能编，但后续你要接 clangd、GLM、交错编译时，GCC 版本太老会带来一堆和语言标准无关的麻烦。更新后先全局确认版本：

g++ --version

输出里最好看到x86_64-w64-mingw32字样；如果是 32 位前缀，后面链接 GLFW 的 WIN64 预编译库大概率会直接失败。另一个容易忽略的点是 PATH 里同时存在多个 MinGW 时，g++ 到底指向哪个编译器，先跑这条命令，比编译报错后再排查省事得多。

2.2 GLFW 用预编译包还是自编译？我劝你先用前者

GLFW 官网提供 Windows 预编译二进制包，解压后能看到include/GLFW/glfw3.h、lib-mingw-w64目录和glfw3.dll。有人会问，既然 GLFW 也走 CMake，为什么不在本地自己编一份？因为在 VSCode 里搭 CMake 就违背了这个标题“免 CMake、免 VS”的初衷：你还要装 CMake、跑 configure、再处理一遍路径，门槛比 OpenGL 本身还高。对 LearnOpenGL 教程前八章来说，预编译动态库完全够用。

你只需要盯住三个文件：glfw3.h负责声明，libglfw3dll.a负责链接，glfw3.dll负责运行时。第一遍学习我建议用动态库方式，理由很直接：改完代码重新编译后，新的可执行文件直接利用显卡驱动上下文，不用重新链接进库；而静态库方案要把-lopengl32 -lgdi32 -luser32这些系统库一并照顾到，新手容易漏一个就报一串未定义。

注意，动态库模式在编译阶段依然要用libglfw3dll.a这个导入库文件。它的作用是告诉链接器“glfwInit 这些符号在 glfw3.dll 里”，最后的可执行文件本身不含 GLFW 代码，真正加载动作发生在程序运行时。把这一点想明白，后面遇到“编译过了但运行报找不到 dll”就知道去哪找原因。

2.3 GLAD 生成器：OpenGL 为什么额外需要一个小库

OpenGL 不像 Windows API 那样把函数都放在一个系统导出的库文件里。GL 3.0 之后，glGenVertexArrays、glShaderSource这些函数全部由显卡驱动在运行时动态导出，代码里直接调用会找不到函数入口。GLAD 的工作就是把这些指针加载逻辑提前生成好，生成结果就是那一对.c/.h源文件。

在 GLAD 在线生成页面里，你需要选三组选项：API 选 OpenGL 3.3 或 4.6，Profile 选 Core，Language 选 C/C++。很多人纠结选 3.3 是不是过时了。我的习惯是第一遍学习固定选 3.3，因为 LearnOpenGL 教程就是按 3.3 Core 写的，老显卡兼容性也更好；等跑通之后想尝鲜 4.6 再重新生成，代码基本不用改。

生成完要留意你拿到的是 GLAD1 还是 GLAD2，两者结构不一样：GLAD1 生成include/glad/glad.h和src/glad.c，GLAD2 生成include/glad/gl.h和src/gl.c，加载函数的名字也有差别。网上教程大多写 GLAD1，如果你按新生成器下载完却照旧代码写头文件，第一步就会编译失败。

2.4 解压后的目录规划：少踩一半的坑

把工具链和依赖库理清楚之后，建一个干净的工程目录。压缩包解压出来的内容别散在桌面，按下面结构整理：

OpenGLForVSCode/ ├─ .vscode/ │ ├─ tasks.json │ ├─ launch.json │ └─ c_cpp_properties.json ├─ include/ │ ├─ glad/glad.h │ ├─ KHR/khrplatform.h │ └─ GLFW/glfw3.h ├─ lib/ │ └─ libglfw3dll.a ├─ src/ │ ├─ main.cpp │ └─ glad.c ├─ build/ # exe 输出目录 └─ glfw3.dll

两个原则：路径不要出现中文，尽量也不要出现空格。如果你把项目放在C:\Program Files\xxx下面，后面 tasks.json 里-I和-L参数会为路径转义付出额外代价。我默认放C:\dev\OpenGLForVSCode。glad.c 必须放在src/里，而不是放在 include 目录，因为它是源码文件而不是头文件，后面 tasks 里要显式参与编译。

3. 在 VSCode 写 OpenGL 前：三个 JSON 配置和第一个窗口

3.1 tasks.json：把 g++ 的编译命令固定下来

先搞清楚三份配置的分工：tasks.json 告诉 VSCode 怎么编译，launch.json 告诉调试器怎么启动程序，c_cpp_properties.json 负责让编辑器里的代码提示和实际编译器一致。很多人一上来就试 F5，结果发现编译命令不对，其实吃亏在没有先把任务链路看明白。

Ctrl+Shift+P 搜索“C/C++: Edit Configurations”可以生成基础配置，但 tasks.json 通常自己建。在项目根目录建.vscode/tasks.json，内容如下：

{ "version": "2.0.0", "tasks": [ { "label": "Build OpenGL Target", "type": "shell", "command": "g++", "args": [ "-g", "src/main.cpp", "src/glad.c", "-Iinclude", "-Llib", "-lglfw3dll", "-lopengl32", "-lgdi32", "-luser32", "-o", "build/main.exe" ], "group": { "kind": "build", "isDefault": true }, "options": { "cwd": "${workspaceFolder}" } } ] }

关键在于src/glad.c不要漏掉。GLAD 生成的是一个普通 C 文件，它必须像main.cpp一样参与编译，否则链接阶段会报undefined reference to gladLoadGLLoader。-lgdi32和-luser32是 Windows 图形子系统的系统库，GLFW 在底层创建窗口和上下文时依赖它们；-lglfw3dll则对应上一章说的导入库，一定写在-l序列里。

链接顺序也要养成习惯：-l参数放在源文件之后，而且 GLFW 在前、系统库在后。GCC 链接器从右往左解析符号，系统库写成后面的原因就是让解析链条最后再闭合。

3.2 launch.json 里的调试器路径：一个字母都不能错

F5 启动调试时，VSCode 会用 launch.json 里的配置拉起 gdb。推荐用下面的模板：

{ "version": "0.2.0", "configurations": [ { "name": "OpenGL Debug", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/main.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": true, "MIMode": "gdb", "miDebuggerPath": "C:/mingw64/bin/gdb.exe", "preLaunchTask": "Build OpenGL Target" } ] }

preLaunchTask的值必须和 tasks.json 里的label一字不差，否则 F5 会报“找不到任务”。program指向 build 目录下的 main.exe，如果你把编译输出目录改成别的名字，这里要同步改。miDebuggerPath最容易出错，很多人凭感觉写gdb，但 VSCode 不会去 PATH 搜索，它只会找这个绝对路径。MinGW 解压位置不同，这个路径就要相应调整。

externalConsole我推荐设成true。OpenGL 程序自己会弹一个窗口，和调试用的控制台窗口分开，printf输出和 GLFW 的运行时错误都能稳定看到；设成false时所有输出挤在 VSCode 集成终端里，偶尔会被缓冲机制吞掉，排查问题时白费力气。

3.3 c_cpp_properties.json：代码提示的开关其实在这里

写完前两个文件，程序能编译能调试了，但编辑器里 glfwInit 可能仍然是虚的，鼠标悬停没有提示，右键也没有跳转到定义。这属于“vscode 配置 c/c++ 环境”里最容易被忽略的一层——IntelliSense 配置。新建.vscode/c_cpp_properties.json：

{ "configurations": [ { "name": "Win32", "includePath": [ "${workspaceFolder}/include" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "GLFW_INCLUDE_NONE" ], "compilerPath": "C:/mingw64/bin/gcc.exe", "cStandard": "c11", "cppStandard": "c++17", "intelliSenseMode": "linux-gcc-x64" } ], "version": 4 }

这里的compilerPath必须指向真实存在的编译器，C/C++ 插件要靠它推断系统头文件路径。intelliSenseMode写成linux-gcc-x64不是笔误，在 Windows 上用 MinGW 时这个模式名就是 GCC 语义，能正确匹配__GNUC__这类编译器宏。includePath 里的GLFW和glad目录都要能找到。如果之后你加了 GLM，这个列表还要继续追加。

有一个细节：defines里的GLFW_INCLUDE_NONE很关键。它告诉 GLFW 不要自行包含gl.h，避免和 GLAD 的头文件产生 OpenGL 函数声明的冲突。学会这招之后，即使你不看官方 FAQ，也能少踩一次重定义报错。

3.4 写第一个窗口：GLAD 加载顺序是生死线

三份 JSON 就位后，新建src/main.cpp，最小窗口代码如下：

#include <cstdio> #include <glad/glad.h> #include <GLFW/glfw3.h> int main() { if (!glfwInit()) { fprintf(stderr, "glfwInit failed\n"); return -1; } glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); GLFWwindow* window = glfwCreateWindow(800, 600, "VSCode OpenGL", nullptr, nullptr); if (!window) { fprintf(stderr, "glfwCreateWindow failed\n"); glfwTerminate(); return -1; } glfwMakeContextCurrent(window); if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)) { fprintf(stderr, "gladLoadGLLoader failed\n"); glfwTerminate(); return -1; } while (!glfwWindowShouldClose(window)) { glfwPollEvents(); glClearColor(0.2f, 0.3f, 0.3f, 1.0f); glClear(GL_COLOR_BUFFER_BIT); glfwSwapBuffers(window); } glfwTerminate(); return 0; }

这段代码唯一的顺序约束是：gladLoadGLLoader必须在glfwMakeContextCurrent之后调用，因为 GLAD 要通过当前 OpenGL 上下文去驱动加载函数指针。反过来典型翻车：先加载 glad 再创建窗口，直接得到 NULL 指针，后面所有 GL 调用都没反应，程序也不报错。

按 F5 如果能看到一个深灰色窗口，说明编译器、GLFW、GLAD、VSCode 四层配置已经全部打通。这一步成功了，后面的三角形、纹理、摄像机都只是往这个骨架里填内容。

4. 从编辑到渲染：链接顺序和 dll 位置只在四行命令里

4.1 拆解编译命令：参数顺序不是玄学

tasks.json 相当于把下一条命令存成了快捷方式。手动在终端里执行时，最终编译命令长这样：

cd C:/dev/OpenGLForVSCode g++ -g src/main.cpp src/glad.c -Iinclude -Llib -lglfw3dll -lopengl32 -lgdi32 -luser32 -o build/main.exe

-Iinclude负责找glfw3.h和glad.h，-Llib负责找libglfw3dll.a。这两组参数一个管头文件，一个管库文件，路径写错时错误信息完全不同：前者报 fatal error 找不头文件，后者报 undefined reference 找不到函数入口，排查时要分开看。

推荐顺序是：源码文件挨着写，然后是-I、-L，最后是-l序列。如果把-lglfw3dll写在src/main.cpp前面，链接器可能因为符号还没进入待解析队列而跳过这个库，结果就是明明写了库还是报 undefined reference。这条规则在 g++ 下有效，在 CMake 的 target_link_libraries 里不一定照搬，但 VSCode tasks 场景下记住它足够。

另一个坑在build/目录。tasks.json 只负责把 exe 写进 build 目录，不会自动创建这个目录。第一次编译报“cannot open output file”时，先看一下 build 文件夹存不存在，而不是急着改编译参数。

4.2 glfw3.dll 该放哪：运行时和调试器是两套逻辑

编译成功和运行成功是两回事。用动态库链接时，程序启动那一刻会加载 glfw3.dll，Windows 的查找顺序是：exe 所在目录、当前工作目录、System32、PATH。我们 exe 在build/下，所以最可靠的做法就是把 glfw3.dll 复制到build/旁边。

如果漏了这一步，弹出的报错是“由于找不到 glfw3.dll，无法继续执行代码”。把 dll 放到项目根目录不一定有用，尤其 launch.json 里的cwd指向 workspace 时，VSCode 调试进程的工作目录和 exe 目录不一致。最省心的方案：编译完成后手动复制一次，或者再建一个 task 用 copy 命令自动同步。

copy /Y glfw3.dll build\glfw3.dll

把这条命令作为 tasks.json 里第二个任务，依赖关系设为先编译后复制，就能避免每次都手抄。注意 cmd 的 copy 在路径有斜杠时可能提示“文件名、目录名或卷标语法不正确”，保持/Y在前、路径在后能减少一半麻烦。

4.3 从 LearnOpenGL 代码到 VSCode：三个改动和一段三角形

现在把 LearnOpenGL 第一个三角形代码迁到我们的工程里。原教程默认读者有 Visual Studio 和 CMake，迁到这套 VSCode 环境只需要改三处：

第一，头文件顺序固定为 glad 在前、GLFW 在后，并且保证GLFW_INCLUDE_NONE宏已定义，这是一道保险，防止两边重复声明 glGenVertexArrays。第二，所有着色器字符串里写#version 330 core，不要写 3.3 之前的老版本，否则 core profile 下直接编译失败。第三，GLAD 加载失败后不要继续渲染，把gladLoadGLLoader的返回值检查留在那里。

下面的代码块是着色器编译和主渲染循环的核心片段：

const char* vsSrc = R"(#version 330 core layout (location = 0) in vec3 aPos; void main() { gl_Position = vec4(aPos, 1.0); })"; const char* fsSrc = R"(#version 330 core out vec4 FragColor; void main() { FragColor = vec4(1.0, 0.5, 0.2, 1.0); })"; unsigned int vs = glCreateShader(GL_VERTEX_SHADER); glShaderSource(vs, 1, &vsSrc, nullptr); glCompileShader(vs); unsigned int fs = glCreateShader(GL_FRAGMENT_SHADER); glShaderSource(fs, 1, &fsSrc, nullptr); glCompileShader(fs); // 检查编译状态，避免字符串写错后查半天 int ok; char log[512]; glGetShaderiv(vs, GL_COMPILE_STATUS, &ok); if (!ok) { glGetShaderInfoLog(vs, 512, nullptr, log); fprintf(stderr, "vertex shader: %s\n", log); } unsigned int program = glCreateProgram(); glAttachShader(program, vs); glAttachShader(program, fs); glLinkProgram(program); glDeleteShader(vs); glDeleteShader(fs); // 主循环里每帧绘制 glUseProgram(program); glBindVertexArray(vao); glDrawArrays(GL_TRIANGLES, 0, 3); glfwSwapBuffers(window);

glShaderSource第二个参数传 1，表示字符串数组里只有一个字符串；把着色器源码拆成多个字符串是 GLSL 编译器的容错设计，通常配合数组拼接用，Single Math TY 处理比较罕见。glGetShaderiv的检查看起来多写几行，但每行都有回报：着色器编译器报错信息默认不打印，你看到的只有黑屏，加上这段后错误直接进调试控制台。

vao的创建我在这里省略了，它在前面的glGenVertexArrays和glBufferData那几行。建议第一次跑三角形时保持和教程一致，把顶点数据写死，不要在拿到第一屏之前就直接上模型矩阵。先看到一个橙色三角形，再谈后面的进阶内容。

5. 五个高频问题排查：从图形后端失败到代码提示失灵

5.1 failed to initialize graphics backend for opengl：驱动还是上下文

现象：程序运行后没有弹出窗口，终端输出failed to initialize graphics backend for opengl，有时还会带个WGL: Failed to make context current之类的补充信息。

原因：这个报错首先怀疑的是窗口创建环节。远程桌面、虚拟机、显卡驱动未更新，都会导致 GLFW 拿不到可用的 OpenGL 上下文；另外一个常见因素是你在glfwWindowHint里把版本要求写得太高，例如直接请求 4.6 Core，而当前机器只支持到 3.3。

解决：先用glfwDefaultWindowHints()还原，然后显式请求 3.3 Core，确认是不是版本拉太高。如果还是失败，更新显卡驱动，关掉远程桌面、物理机跑一次。核显和独显并存的机器，还要留意系统把渲染任务分给了核显，驱动支持不足时也会报这个错。

5.2 undefined reference 一串接一串：先查链接顺序

现象：编译能过，链接阶段开始刷undefined reference to glfwInit，后面跟着glGenVertexArrays、glShaderSource等一堆函数。

原因：分两种情况。glfwInit报 undefined reference，是-lglfw3dll没生效或路径不对；而glGenVertexArrays报错，多半是 glad.c 没参与编译，或者 GLAD 加载函数在代码里被跳过。出现一整串报错时，先数一数任务命令里有没有src/glad.c，再核对-l的顺序。

解决：把编译命令从 tasks.json 复制到集成终端手动跑一遍，按上一章的参数顺序核对。把-lglfw3dll移到-lopengl32前面，把-Iinclude和-Llib放在源码之后，命令变成一行标准形式，错误数量通常能减少大半。

5.3 找不到头文件：includePath 是直接原因吗

现象：编译第一行就报fatal error: GLFW/glfw3.h: No such file or directory，或者glad/glad.h找不到。

原因：tasks.json 里-Iinclude写的是相对路径，这个相对路径以cwd为基准。当你在别的项目里复制了这份配置，include 目录不存在时就会触发。GLAD 的头文件目录是include/glad/glad.h，引入时写#include <glad/glad.h>，路径里不能多一层目录。

解决：终端先执行dir include\glad和dir include\GLFW，确认目录结构存在。再检查调度时大小写，Windows 虽然不敏感，但 glfw3.h 和 glfw3.h 写错的情况仍然偶发。确认目录无误后重启 VSCode，让 IntelliSense 重新扫描，两个头文件的问题通常同步解决。

5.4 右键没有跳转到定义、函数名灰色：IntelliSense 数据库问题

现象：代码里glfwInit是正常高亮的，但右键没有跳转到定义，鼠标悬停也不显示签名；glGenVertexArrays颜色发灰，感觉编辑器没把它当有效符号。

原因：这类“vscode c++ 没提示”的问题九成出在 c_cpp_properties.json 的 compilerPath 和 includePath。IP 里有 GLAD 目录但编译器路径写错时，C/C++ 插件无法解析系统头文件，连带所有来自 GLFW 的符号都变灰。另一个原因是 clangd 插件和 VSCode 内置 IntelliSense 同时启用，两套引擎互相打架。

解决：Ctrl+Shift+P 打开命令面板，搜“C/C++: Reset IntelliSense Database”，重置完再看。如果接了 clangd，就在设置里禁用C_Cpp.intelliSenseEngine，让 clangd 单跑；反之只保留内置。最后检查c_cpp_properties.json里的compilerPath指向gcc.exe，不是g++.exe，两者语法基本一致但插件有时对 g++ 识别更慢。

5.5 窗口一闪而过：先别急着 return 0

现象：F5 和双击 exe 都只看到黑色控制台窗一闪，OpenGL 窗口还没出现就退出了。

原因：最常见的是glfwCreateWindow返回空，代码里又没有检查，直接往下走glfwMakeContextCurrent崩溃退出。其次是主函数的 while 循环条件写错，比如把glfwGetWindowAttrib(window, GLFW_VISIBLE)当成了窗口存活条件，窗口显示正常但循环直接跳过。

解决：程序开头把所有初始化返回值打印到 stderr，然后从终端手动运行 exe，让异常信息停在屏幕里。Windows 下调试用externalConsole: true，窗口会独立显示，退出时可以回看全部输出。不要依赖system("pause")这种护身符，它掩盖的是缺少错误检查，不是解决问题。

6. 进阶练习：物体移动轨迹线，以及把 glGetError 变成习惯

6.1 物体移动轨迹线：不是画一条线，是把旧位置留下来

窗口和三角形稳定之后，很多人想实现“物体移动轨迹线”的效果。常见做法不是让三角形拖一条线，而是维护一个历史位置数组，每帧把位置追加进一个 GL_LINE_STRIP 的 VBO。核心片段如下：

std::vector<float> trace; // 每次更新物体位置后 trace.push_back(currentX); trace.push_back(currentY); glBindBuffer(GL_ARRAY_BUFFER, traceVBO); glBufferData(GL_ARRAY_BUFFER, trace.size() * sizeof(float), trace.data(), GL_DYNAMIC_DRAW); glBindVertexArray(traceVAO); glDrawArrays(GL_LINE_STRIP, 0, (GLsizei)(trace.size() / 2));

GL_DYNAMIC_DRAW说明这个缓冲区会被频繁更新，驱动会把它放到更适合动态写入的显存位置。线宽在 core profile 下受限制，别指望glLineWidth(10)在 Windows 上一定生效，需要时可以用三角形条带模拟。移动过程的模型矩阵更新放在glm::translate里做，我在这里不做演示细节，因为先把 trace 方案跑通，你就已经理解 VBO 的两种用途了。

6.2 验证 OpenGL 版本与 glGetError 的一分钟习惯

我现在每次 GLAD 加载完之后会打一次版本号，确认驱动到底提供了什么：

fprintf(stderr, "OpenGL %s, GLSL %s\n", glGetString(GL_VERSION), glGetString(GL_SHADING_LANGUAGE_VERSION));

然后在第一个着色器函数后面加一个 glGetError 检查：

GLenum err; while ((err = glGetError()) != GL_NO_ERROR) { fprintf(stderr, "OpenGL error: 0x%04x\n", err); }

这十秒钟能避免很多黑屏翻车，尤其是从着色器编译错误到绘制调用失败这一类问题，报错永远比瞎猜快。那些我曾经在没加这些检查时浪费掉的周末，不值得你再踩一次。希望帮到你。

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