简介：VSCode 的基本操作与 C/C++ 开发环境配置，是不少自学者入门时最先卡壳的一环。这套资料面向刚接触 VSCode 的学生、转行开发者，以及需要在本机跑通 C/C++ 编译调试流程的初学者，重点梳理插件选择、编辑器设置、编译器与调试器衔接等上手阶段的高频困惑。压缩包共 1132 个文件，总量约 230.42MB，以大量 png、jpg 操作截图配合 Markdown 笔记还原关键步骤，并附有 Shell 脚本、YAML、Dockerfile 等配置样例，方便对照自身系统逐项核查。目前已有 4845 人学习下载。读者可从中获得完整的学习脉络：从界面认识、快捷键与工作区设置，到 C/C++ 插件安装、tasks.json 与 launch.json 编写，再到断点调试及常见报错排查。读者也可以借助附带脚本减少重复摸索，因此这套资料适合作为长期查阅的案头参考。

1. 装 VScode 配 C/C++ 环境，最先卡住的往往不是扩展

装 VScode 配 C/C++ 环境，最常见的一幕是：扩展装上了，代码也能高亮，一按 F5 就卡在找不到 gdb，或者编译单文件正常、一链接多文件就翻车。这套环境在 Windows 上太常见了，适合刚接触 C/C++、想要轻量编辑器又不想一上来就背重型 IDE 的开发者。装不好不会立刻报错，而是用头文件波浪线、终端能编译但 VScode 里找不到 g++、调试器启动失败这类问题慢慢消耗时间。先把编译器版本线、安装目录和 PATH 定下来，再谈扩展和调试配置，后面能省不少后悔药。

2. 安装 VScode 与首个工作区：安装包、中文界面和终端入口

2.1 安装包选择：User Installer 和 System Installer 的取舍

VScode 的安装包常见分两种：User Installer 和 System Installer。名字看起来只是权限差别，实际会影响后面code命令能不能用、扩展装到哪个用户目录、多人共用一台机器时配置是否互相干扰。个人开发机我一般选 User Installer，安装和更新都不需要管理员权限，扩展和用户设置落在当前用户目录，出问题也好清理；如果是实验室公用机、或者团队统一装机，才考虑 System Installer，装到公共目录，所有用户共享一份程序本体，但用户设置仍然是分开的。

安装过程中有几个选项别一路下一步。添加到 PATH决定安装完后在终端里能不能直接敲code打开项目；通过 Code 打开的右键菜单决定你以后是拖文件夹还是右键打开；文件关联按需勾选，不勾也不影响编译。安装路径尽量用纯英文、不带空格的目录，例如D:\dev\VScode，不是玄学，而是后面任务和调试器参数里会反复写路径，空格和中文容易在脚本、命令行参数里被拆开。装完先重开一个终端验证：

# 查看 VScode 命令行是否进入 PATH code --version # 列出当前已安装扩展，后面装完 C/C++ 扩展可以再用一次 code --list-extensions

code --version能输出版本号和提交号，说明命令行入口正常；如果提示“不是内部或外部命令”，通常是安装时没勾选 PATH，或者装完没有重开终端。code --list-extensions用来做扩展盘点，输出为空也正常，说明还没装扩展。这里不要急着去改系统环境变量，先重开终端；还不行就重新运行安装包，选“修复”或重新勾选 PATH，比手工猜安装目录稳。

提示：安装路径不要放在Program Files这类带空格的目录下，后面tasks.json和launch.json里写路径时少一层转义麻烦。

2.2 首次启动：中文界面、工作区和设置文件

首次启动后，先决定界面语言。VScode 默认英文不影响编译，但如果要装中文界面，是在扩展面板里搜“中文（简体）语言包”这类语言扩展，装完按提示重启，再用命令面板执行Configure Display Language选择语言。注意，语言包只改界面显示，不改系统区域设置，也不影响 C/C++ 编译器的输出编码；后面终端里中文乱码，别第一时间怪语言包。

接着把工作区习惯定下来。VScode 最适合的方式是“打开文件夹”，不是单独拖一个.cpp文件进来。打开文件夹后，项目根目录下可以放一个.vscode目录，里面的tasks.json、launch.json、c_cpp_properties.json只对当前工作区生效，换项目不会互相污染。单文件打开也能编译，但调试配置、头文件搜索路径、多文件编译都会变得零散，后面排查问题时很难判断用的是哪份配置。

命令面板用Ctrl+Shift+P打开，常用入口都从这里进：Preferences: Open User Settings (JSON)打开用户设置，Preferences: Open Workspace Settings (JSON)打开当前工作区设置。用户设置适合放字体、自动保存、终端默认配置；工作区设置适合放编译器路径、C++ 标准这类跟项目强相关的参数。可以先在用户设置里放一份轻量配置：

{ // 编辑器字号，按屏幕调整，不影响编译 "editor.fontSize": 15, // 焦点变化时自动保存，减少忘记保存导致的旧代码编译 "files.autoSave": "onFocusChange", // 默认集成终端，Windows 下常用 PowerShell "terminal.integrated.defaultProfile.windows": "PowerShell" }

这段配置只解决使用体验，不解决 C/C++ 编译。editor.fontSize是界面参数；files.autoSave建议用onFocusChange，切到终端或调试面板时自动保存，能避免“明明改了代码，编译出来还是旧结果”的假故障；terminal.integrated.defaultProfile.windows指定集成终端类型，后面验证gcc、g++是否在 PATH 里，最好就在这个终端里做。改完设置不用重启，但换终端类型后要新开一个终端会话。

2.3 扩展与终端：把 C/C++ 入口放到手边

C/C++ 扩展是后面智能提示、调试配置的基础，但不要在编译器还没装好时就反复重装扩展。扩展面板里搜C/C++，选官方发布的那一个，装完在扩展详情里能看到它依赖的调试能力；如果团队项目锁定了扩展版本，可以在扩展详情页的版本下拉里回退，别直接删了重装最新版。版本回退常见于老项目：新扩展对某些旧编译器路径的推断更严格，表现就是头文件突然全红，回退一版就安静了。

装完扩展后，把终端拉出来。Ctrl+`` 打开集成终端，先确认当前目录是不是工作区根目录。很多人后面tasks.json` 里写相对路径失败，就是因为终端和 VScode 打开的不是同一个文件夹。可以先用命令确认：

# 确认当前终端所在目录 Get-Location # 确认 VScode 命令行入口仍然可用 code --list-extensions | Select-String -Pattern "cpp"

Get-Location输出的是当前终端路径，应该和 VScode 左侧资源管理器根目录一致；Select-String用来过滤扩展列表里带cpp的项，能看到 C/C++ 扩展相关条目就说明装上了。这里只是确认入口，不是编译验证；真正的编译器验证要等 MinGW-w64 配好 PATH 之后再做。扩展装早了不会坏，但别把“扩展列表里有名字”当成环境已经跑通。

3. 配置 C/C++ 编译器：MinGW-w64 的解压目录、PATH 和版本验证

3.1 选 MinGW-w64 构建变体：x86_64、posix 线程和 seh 异常

VScode 本身只是编辑器，C/C++ 能不能编译取决于外面的编译器。Windows 上常见做法是装 MinGW-w64 工具链，但 MinGW-w64 不是只有一个包，构建变体选错，后面会表现为线程库链接失败、异常处理异常、gdb 调试断不下来。选包时重点看三个参数：架构、线程模型、异常模型。下面这张表是常见取舍，不是版本号，具体发行包以你拿到的压缩包说明为准。

我一般选x86_64 + posix + seh这一线，原因是它和 VScode 的 C/C++ 扩展、gdb 调试路径最不容易打架。win32线程模型不是不能用，但在某些标准库线程和异常场景下更容易出现链接期问题；sjlj异常模型兼容性广，但 64 位下性能不如seh。如果你拿到的是已经编译好的独立压缩包，解压后目录里一般有bin、include、lib，bin下面能看到gcc.exe、g++.exe、gdb.exe，这就是后面要写进 PATH 的目录。

3.2 解压与目录规划：为什么不要放 Program Files 和中文路径

编译器目录规划比安装包本身更影响后面排错。我习惯统一放D:\dev\mingw64，bin目录就是D:\dev\mingw64\bin。不要放C:\Program Files，路径里的空格会让某些任务参数、调试器路径在拼接时被拆开；不要放中文目录，C/C++ 扩展和 gdb 对非 ASCII 路径的处理并不总是一致；也不要放在下载目录里临时用，后面清理下载文件时容易把工具链一起删掉。解压可以用 PowerShell，zip 包直接展开：

# 创建统一的开发工具目录，已存在则忽略 New-Item -ItemType Directory -Force D:\dev | Out-Null # 将下载的 mingw64.zip 解压到 D:\dev，最终得到 D:\dev\mingw64 Expand-Archive -Path "$env:USERPROFILE\Downloads\mingw64.zip" -DestinationPath D:\dev -Force # 查看 bin 目录下是否有 gcc、g++、gdb Get-ChildItem D:\dev\mingw64\bin\gcc.exe, D:\dev\mingw64\bin\g++.exe, D:\dev\mingw64\bin\gdb.exe

Expand-Archive只处理 zip；如果拿到的是 7z 或别的压缩格式，用系统里现成的解压工具解到同一层级即可，目标结构不变。Get-ChildItem是验证解压结构，三个 exe 都在，说明工具链本体完整。这里不要急着把整个mingw64目录塞进 PATH，只加bin，因为 PATH 是找可执行文件的，不是找整个工具链根目录的。加错层级的表现是终端里能cd到目录，但敲gcc仍然找不到。

3.3 写 PATH：只改用户变量，保留旧路径

PATH 配置是 C/C++ 环境里最容易翻车的一步。常见错误有两种：一是直接覆盖用户 PATH，把原有路径冲掉；二是把D:\dev\mingw64而不是D:\dev\mingw64\bin加进去。我一般只改用户变量，不动系统变量，这样影响范围小，出问题也好回退。PowerShell 可以先读旧值，再追加，避免覆盖：

# 编译器 bin 目录 $mingwBin = "D:\dev\mingw64\bin" # 读取当前用户 PATH，不要读系统 PATH $oldPath = [Environment]::GetEnvironmentVariable("Path", "User") # 如果还没有加入，则追加到最前面，优先使用这份工具链 if ($oldPath -notlike "*$mingwBin*") { [Environment]::SetEnvironmentVariable("Path", "$mingwBin;$oldPath", "User") } # 输出确认 [Environment]::GetEnvironmentVariable("Path", "User")

这段脚本的关键点是第二个参数"User"：它只写当前用户环境变量，不需要管理员权限，也不会影响其他账户。把$mingwBin放在旧 PATH 前面，是为了让这份gcc、g++、gdb优先于系统里可能存在的旧版本；如果你机器上还有别的 IDE 自带编译器，PATH 顺序不对就会出现“终端里gcc --version是一个版本，VScode 任务里又是另一个版本”的鬼故事。改完必须重开终端，VScode 也要重启窗口，因为它启动时继承的是旧环境。

注意：不要手工把 PATH 里的旧内容全删了再粘贴新值，很多构建工具、包管理器都依赖原有路径。

3.4 验证 gcc、g++、gdb：三条命令和两个看结果的地方

PATH 改完后，新开一个 PowerShell 窗口验证。不要在旧终端里反复敲，旧终端不会自动刷新环境变量。三条命令分别看 C 编译器、C++ 编译器、调试器：

# 查看 gcc 版本和构建目标 gcc --version # 查看 g++ 版本，确认 C++ 编译器可用 g++ --version # 查看 gdb 版本，后面 launch.json 要用 gdb --version # 查看实际命中的路径，排查 PATH 顺序 where gcc where g++ where gdb

--version输出里能看到构建目标和版本信息，where输出的是实际命中的 exe 路径。两个地方要对着看：如果where gcc指向的不是D:\dev\mingw64\bin\gcc.exe，说明 PATH 顺序里还有旧工具链在前面；如果g++ --version正常但gdb --version找不到，说明你拿到的包可能只带编译器不带调试器，后面launch.json里写 gdb 路径就会失败。编译一个最小文件验证链接：

// D:\dev\hello\main.cpp #include <iostream> int main() { std::cout << "hello c++" << std::endl; return 0; }

在文件所在目录执行g++ -g main.cpp -o main.exe，再运行.\main.exe。-g生成调试符号，后面断点调试必须有；-o指定输出文件名，不指定时默认名字在 Windows 上容易和目录混淆。能编译、能输出，说明编译器、链接器、运行库这条链通了；还不能说明 VScode 的任务和调试配置通了，那是下一章的事。

4. 在 VScode 里配 C/C++：扩展、tasks.json、launch.json 和 c_cpp_properties.json

4.1 装 C/C++ 扩展：版本锁定与工作区信任

C/C++ 扩展负责智能提示、跳转、调试配置补全，但它不提供编译器。装扩展之前，先确认上一章的g++ --version在 VScode 集成终端里也能跑通；如果终端里能跑、扩展仍然报找不到编译器，再去看扩展设置和工作区信任。工作区信任会影响扩展能不能执行任务和调试，打开陌生项目时 VScode 会问是否信任，选信任当前工作区后，.vscode里的任务才会正常跑。

扩展安装后，不建议一上来就改一堆设置。先让扩展自己推断一次：打开一个.cpp文件，按Ctrl+Shift+P执行C/C++: Edit Configurations (UI)，看编译器路径能不能选到D:\dev\mingw64\bin\g++.exe。如果选不到，说明扩展没读到 PATH，或者工作区设置里写了一个不存在的路径。版本回退的场景也要知道：扩展更新后如果突然大量头文件报红，先看扩展详情里的版本列表，回退到上一个稳定版本，再检查c_cpp_properties.json里的compilerPath是否仍然有效。

4.2 tasks.json：把 g++ 编译参数固定下来

tasks.json解决“怎么编译”。没有它，你每次都要在终端里手敲g++；有了它，Ctrl+Shift+B就能按固定参数编译当前文件。下面这份配置放在工作区.vscode/tasks.json，编译当前打开的 C++ 文件，输出同名 exe：

{ "version": "2.0.0", "tasks": [ { "label": "build-cpp", "type": "shell", "command": "g++", "args": [ "-g", // 生成调试符号，F5 断点调试需要 "-Wall", // 打开常用警告 "-Wextra", // 打开额外警告，早发现类型和符号问题 "-std=c++17", // C++ 标准，和 c_cpp_properties 保持一致 "${file}", // 当前打开的源文件 "-o", "${fileDirname}\\${fileBasenameNoExtension}.exe" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": ["$gcc"], "detail": "编译当前 C++ 文件，生成同名 exe" } ] }

label是任务名，后面launch.json的preLaunchTask必须和它一模一样；command写g++而不是完整路径，前提是 PATH 已配好，如果你想锁定工具链，也可以写D:/dev/mingw64/bin/g++.exe。-g不能省，否则调试时没有符号；-Wall -Wextra不是必须，但能提前暴露未使用变量、隐式转换这类问题；-std=c++17是常见选择，老项目可能是c++11，新项目可以用更高标准，但要和智能提示配置一致。${file}是当前文件，${fileDirname}是当前文件所在目录，${fileBasenameNoExtension}是不带扩展名的文件名。Windows 路径里的反斜杠在 JSON 中要写成\\，这是转义，不是多写一个斜杠。

多文件项目不要指望这个任务自动编所有.cpp。它只编当前文件，适合单文件练习；多文件要么把args里的${file}换成多个源文件路径，要么直接上 CMake。新手最常见的翻车是：两个.cpp都写了函数，任务只编当前文件，链接时报“未定义引用”，然后去怀疑编译器坏了。先看任务实际执行了哪些文件，比反复重装工具链有用。

4.3 launch.json：gdb 路径和 preLaunchTask 要对齐

launch.json解决“怎么调试”。它要指定被调试的 exe、gdb 路径、工作目录，还要在启动前调用编译任务。下面这份配置放在.vscode/launch.json，调试当前文件：

{ "version": "0.2.0", "configurations": [ { "name": "g++ 调试当前文件", "type": "cppdbg", "request": "launch", "program": "${fileDirname}\\${fileBasenameNoExtension}.exe", "args": [], "stopAtEntry": false, "cwd": "${fileDirname}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "D:\\dev\\mingw64\\bin\\gdb.exe", "setupCommands": [ { "description": "为 gdb 启用整齐打印", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "build-cpp" } ] }

program必须和tasks.json的输出路径一致，否则会出现“编译成功但调试启动失败”；miDebuggerPath要写gdb.exe的完整路径，不能只写gdb，因为调试器启动时不一定继承你终端里的 PATH；preLaunchTask写build-cpp，和任务label对齐，这样按 F5 会先编译再调试。externalConsole为false时程序输出在 VScode 的调试控制台/集成终端里，需要交互输入的程序有时会不顺手，可以临时改成true用独立窗口，但改完要同步看cwd是否正确。stopAtEntry为false表示不在 main 入口自动停，想一启动就停可以改true。

4.4 c_cpp_properties.json：头文件波浪线不是玄学

c_cpp_properties.json解决智能提示的头文件搜索和标准推断。它不参与实际编译，但配置错了会满屏波浪线，让人误以为代码有错。下面这份配置把编译器路径、C++ 标准、IntelliSense 模式固定下来：

{ "configurations": [ { "name": "MinGW-w64", "includePath": [ "${workspaceFolder}/**", "D:/dev/mingw64/include/**" ], "defines": [], "compilerPath": "D:/dev/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }

compilerPath是最关键的字段，扩展会用它推断系统头文件路径；includePath里放工作区和工具链头文件目录，/**表示递归搜索；cStandard和cppStandard要和tasks.json里的-std一致，否则可能出现编译器能过、编辑器报红的情况；intelliSenseMode按平台、编译器、架构选，Windows 下 MinGW-w64 常见是windows-gcc-x64，换架构或换编译器要跟着改。这里不是路径越多越好，把不存在的目录写进去会让扩展反复扫描，打开大项目时明显变慢。

4.5 settings.json 兜底：团队项目把配置放进 .vscode

用户设置和工作区设置容易混。团队项目我一般把和 C/C++ 强相关的默认值放进.vscode/settings.json，跟着项目走，换机器不用重新配。下面这份是兜底配置，字段不多，但能减少“为什么你的 VScode 能跳转，我的不能”的争论：

{ // 让扩展默认使用这份编译器路径 "C_Cpp.default.compilerPath": "D:/dev/mingw64/bin/g++.exe", // 默认 C++ 标准，和任务、c_cpp_properties 对齐 "C_Cpp.default.cppStandard": "c++17", // 打开错误波浪线，关闭后问题会被藏起来 "C_Cpp.errorSquiggles": "enabled", // 头文件按 C++ 解析，减少 .h 文件误判 "files.associations": { "*.h": "cpp" } }

C_Cpp.default.*是扩展级默认值，适合在没有c_cpp_properties.json时兜底；C_Cpp.errorSquiggles不建议关，关了只是看不见错误，不是错误消失；files.associations把.h按 C++ 解析，对 C++ 项目减少误报。工作区设置优先级高于用户设置，所以团队项目里写了编译器路径，个人机器路径不同时要改工作区配置，不要只改用户设置然后奇怪为什么没生效。

5. 避坑与排查：C/C++ 环境最常见的五个翻车现场

5.1 现象：终端能编译，VScode 任务里报 g++ 找不到

现象很典型：在 VScode 集成终端里敲g++ --version正常，按Ctrl+Shift+B跑任务却提示“g++ 不是内部或外部命令”。原因通常不是编译器没装，而是任务使用的 shell 环境和终端不一致，或者 VScode 是在改 PATH 之前启动的，继承了旧环境。另一个常见原因是tasks.json里把command写成了完整路径但路径带空格没加引号，或者写成了 Linux 风格路径。

解决顺序我一般这样走：先关掉所有 VScode 窗口再重开，让新进程继承新 PATH；再在集成终端里执行where g++，确认命中路径；如果终端正常、任务仍失败，把tasks.json的command临时改成D:/dev/mingw64/bin/g++.exe做对照。能跑通说明 PATH 继承有问题，不能跑通再检查路径拼写。不要一上来就重装扩展，扩展不背这个锅。

5.2 现象：编译单文件正常，一链接多文件就报未定义引用

现象是单文件main.cpp能编译，加入add.cpp后链接报undefined reference。原因多数不是代码写错，而是tasks.json只把当前${file}交给g++，另一个.cpp根本没参与编译。C/C++ 的编译和链接是两步，单文件任务只覆盖了当前文件，多文件项目需要把所有源文件一起交给编译器，或者先用-c编成对象文件再链接。

解决方式看项目规模：两三个文件可以把args里的${file}换成${workspaceFolder}/src/*.cpp，让 g++ 一次接收多个源文件；文件多了直接上 CMake，别在tasks.json里维护一长串文件名。临时验证时可以在终端执行g++ -g src/main.cpp src/add.cpp -o app.exe，能过说明代码和编译器没问题，问题在任务参数。多文件项目还要注意头文件路径，#include "add.h"的搜索目录不对时，报错会先出现在编译阶段，而不是链接阶段。

5.3 现象：F5 启动调试失败，提示找不到 gdb 或程序不存在

现象是按 F5 后弹窗提示Unable to start debugging，或者调试控制台说找不到gdb.exe、找不到program。原因通常有两个：launch.json里的miDebuggerPath只写了gdb，调试器启动时没继承 PATH；或者program指向的 exe 和tasks.json输出文件名不一致，编译产物根本没生成。

解决时先看tasks.json的-o输出路径，再对照launch.json的program，两个路径必须指向同一个文件。miDebuggerPath写绝对路径，例如D:\\dev\\mingw64\\bin\\gdb.exe，并且确认这个文件真实存在。preLaunchTask的名字必须和任务label完全一致，大小写、空格都算。还有一点容易忽略：如果编译任务失败，调试仍然会尝试启动旧 exe，看起来像“调试器坏了”，实际是编译没通过。先看任务输出，再看调试。

5.4 现象：代码能编译，但编辑器里满屏红色波浪线

现象是终端编译通过，VScode 编辑器里#include <iostream>下面一条红线，或者标准库类型提示找不到。原因多半是c_cpp_properties.json的compilerPath不对，或者cppStandard和任务里的-std不一致。C/C++ 扩展用compilerPath推断系统头文件，路径为空或指向不存在的 exe 时，IntelliSense 就找不到标准库。

解决时先打开命令面板执行C/C++: Edit Configurations (UI)，看编译器路径能不能选到g++.exe；不能选就手工填绝对路径。再把cppStandard改成和tasks.json一致，例如都写c++17。如果只有某个第三方头文件报红，检查includePath是否包含它的根目录，别把整个磁盘加进去。波浪线是智能提示问题，不是编译器问题，改完配置后执行C/C++: Reset IntelliSense Database再等它重建索引。

5.5 现象：换了台机器，原来的 .vscode 配置全部失效

现象是项目从一台机器拷到另一台，.vscode目录还在，但编译和调试都报路径错误。原因很直接：tasks.json、launch.json、c_cpp_properties.json里写了绝对路径，比如D:/dev/mingw64/bin/g++.exe，新机器工具链不在同一位置。另一个原因是新旧机器的 VScode 扩展版本不同，旧配置里的某些字段被新版本忽略。

解决时不要把绝对路径当成跨机器配置。团队项目可以在.vscode/settings.json里写默认编译器路径，但每个人本地路径不同时，用工作区配置覆盖，或者把工具链统一装到约定的相对目录。换机器后先跑where g++和where gdb，再改三个配置文件里的路径；扩展版本差异大时，先回退到团队约定的版本，再排查配置字段。我的习惯是项目里放一份README记录工具链目录约定，比在聊天记录里翻路径可靠。

6. 装完怎么验证跑通：从 Hello World 到断点调试的完整验收

装完不要只看扩展图标亮没亮，按下面这张表走一遍，能省掉后面很多“好像能用”的侥幸。

断点调试最能暴露配置问题。按 F5 后如果直接跑完没停，先看红点是不是打在可执行代码行上，再看launch.json的program是否指向刚编译出来的 exe，最后看preLaunchTask有没有真正执行。程序需要输入时，externalConsole设为false可能在调试控制台里不方便，临时改true用独立窗口验证，但别忘了改回去。

多文件验收不要用单文件任务硬扛。准备main.cpp和add.cpp，在终端执行g++ -g main.cpp add.cpp -o app.exe，能链接成功再回头改任务配置。从那以后我每次配完 C/C++ 环境，都强制走一遍“编译、运行、断点、多文件”这四步，不跳步。这套 VScode 安装包、MinGW-w64 压缩包和三个配置文件模板，我整理在同一份资料里，按文末入口取用即可。希望帮到你。

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