Eclipse搭建C语言开发环境：CDT与MinGW配置指南

简介这份面向 C/C 初学者及具备基础 Eclipse 操作经验开发者的开发文档聚焦 Windows 平台下借助 Eclipse、CDT 与 MinGW 搭建可用的 C 语言开发环境重点解决编译器缺失、环境变量设置、CDT 参数不匹配以及首个工程难以跑通等入门障碍。压缩包内共 1 个 docx 文件大小约 903KB以图文结合的配置说明为主体便于离线查阅与按主题检索。目前已有 2217 人学习反映出该配置主题在入门阶段仍有较高关注度。文档围绕 Eclipse、CDT 与 MinGW 的协同使用展开内容覆盖软件准备、安装配置、环境变量调整、CDT 参数设置、工程创建、编译运行及调试思路并对常见配置错误给出针对性提示能够帮助读者理解各组件之间的依赖关系建立从环境搭建到工程成功运行的完整认知适合课程实验、个人自学、机房环境部署及教学备课参考。1. 为什么还在用 Eclipse 写 C一份能照着敲的环境文档接手别人留下的老工程时最耗时间的往往不是读代码而是把编译链在一台干净机器上重新拉起来。手上这份Eclipse 搭建 C 语言开发环境的开发文档解决的正是这件事它把 Eclipse 本体、CDT 插件、MinGW 编译器三者的下载、解压、环境变量、CDT 参数和首个工程的创建串成一条线按顺序走完就能得到一个能自动编译、能在控制台看到输出的 C/C 工作区。它适合两类人一类是机器上本来只拿 Eclipse 写 Java、想顺手把 C 也接进去的人另一类是在没有大型构建系统的条件下维护一批单文件或小规模 C 程序的人。文档基于 Eclipse SDK CDT 与 MinGW 的组合写成Windows 路径分隔符、PE 解析器、make 命令替换这些细节都落在具体操作上而不是泛泛而谈。2. 三件套的选型逻辑Eclipse、CDT、MinGW 谁管什么很多人第一次配这套环境失败不是因为手笨而是没分清三个部件各自的职责边界出问题时不知道往哪一层查。Eclipse 是壳CDT 是壳里那套 C/C 业务逻辑MinGW 才是真正把.c变成.exe的人。这三者任何一层没接上表现都是「点了构建没反应」或者「构建成功但跑不起来」症状相似、病因完全不同。2.1 Eclipse 本体与 CDT 插件的关系Eclipse 的本质是一个插件平台加一个工作台Workbench。它自己不认识printf也不认识#include所有跟 C/C 有关的能力都由 CDTC/C Development Tools提供。CDT 往里塞的东西大致分五块项目类型Managed Make 工程和 Makefile 工程、带语法高亮和索引的编辑器、构建器Build、错误解析器Error Parser、调试器前端对 GDB 的封装。关键认知在这里CDT 只负责「组织构建」它把源文件列表、头文件搜索路径、编译选项翻译成一条条命令行然后交给外部程序去执行。真正调用cc1、as、ld的是 MinGW 里的 gcc。所以会出现一种很典型的现象——Eclipse 里 C/C 菜单齐全新建工程也正常一构建就报找不到编译器。这时候去折腾 CDT 的设置是白费力气问题在系统 Path 上。还有一层容易被忽略CDT 版本必须和 Eclipse 主版本配套。文档里给的方案是从 Eclipse SDK 官网下载页拿主程序再到 CDT 下载页拿与之匹配的版本。版本错配的典型表现是 Eclipse 启动直接弹出一屏红字说某个org.eclipse.cdt.*插件依赖无法解析然后工作台起不来。这时候唯一的办法是换回匹配的 CDT而不是去改eclipse.ini里的内存参数。2.2 MinGW 提供的到底是编译器还是运行时MinGW 全称是 Minimalist GNU for Windows它提供的不是单一程序而是一整套工具链gcc-coreC 编译器驱动、gcc-gC 前端、binutilsas汇编器、ld链接器、ar打包工具等、mingw32-make构建工具、mingw-runtime与w32apiWindows 平台的头文件和导入库。一条.c走到.exe的链路是这样的gcc 驱动读命令行 →cc1做预处理和编译生成汇编 →as汇编成目标文件 →ld按顺序链接运行时库和系统导入库 → 输出 PE 格式的可执行文件。任何一环缺件都会在链接阶段炸出来最常见的报错是undefined reference to xxx看着像代码写错实际是库没链上或者库的顺序不对。MinGW 和另一类 POSIX 模拟环境的最大区别在于它生成的是原生 Windows 程序不依赖中间层 DLL 去做系统调用翻译跑起来跟用 MSVC 编出来的东西在系统层面没差别。这也是文档选它作为 CDT 后端的原因——CDT 的错误解析器对 gcc 风格的输出最熟而 MinGW 输出的就是标准 gcc 格式。至于LIBRARY_PATH、C_INCLUDE_PATH、CPLUS_INCLUDE_PATH这几个变量职责是给编译器指路去哪找.a/.lib库文件、去哪找 C 头文件、去哪找 C 标准库头文件。严格说gcc 装在标准位置时会自动去自己安装目录下的include和lib里找这几个变量更多是给「机器上有多套工具链」或者「装在非标准路径」的场景兜底。文档把它们都列出来属于把边界情况一次性配齐的思路。2.3 两条下载路线SDKCDT 与打包版 IDE文档给了两条路线选哪条取决于你机器上是否已经有 Eclipse。路线组成适合谁代价AEclipse SDK CDT主程序解压再下配套 CDT 解压合并已经有 Eclipse、只想加 C/C 能力必须自己保证版本配套BEclipse IDE for C/C一个已打包 CDT 的发行包全新机器、不想折腾版本体积大带的 Java 工具用不上路线 A 的操作要点是「合并」而不是「替换」。Eclipse SDK 解压到C:\下会得到一个eclipse文件夹CDT 解压出来同样是一个叫eclipse的文件夹里面有plugins和features。解压时选择合并覆盖让 CDT 的插件文件落进同一个plugins目录如果手滑选成整目录替换原来的 Eclipse 主程序就被覆盖没了启动直接失败。路线 B 简单得多压缩包解开就能用里面已经含了配套的 CDT。缺点是你没法控制 CDT 的具体版本遇到需要特定 CDT 行为的场景就只能换包。无论走哪条路线都有一个前置条件机器上得有可用的 JDK并且JAVA_HOME和Path配好。Eclipse 自己是 Java 程序缺 JDK 的表现是双击eclipse.exe之后弹一个对话框说找不到 Java 运行时然后退出。这一步在文档里被放在「下载准备」里篇幅不大但它是唯一一个「不做就完全起不来」的前置。3. 装机与环境变量Path、LIBRARY_PATH、C_INCLUDE_PATH 一次配对安装这一段是整套流程里最容易留下隐患的地方因为大部分步骤是「解压即完成」看不出对错真正的问题会在几天后某个新工程里突然冒出来。我的习惯是把安装拆成三步走先定目录、再配变量、最后在命令行独立验证。第三步不能省它是后面所有排错的分界线。3.1 解压式安装的目录约定Eclipse 和 CDT 都是免安装的绿色包解压到哪就在哪运行。文档假设解压到C:\于是得到C:\eclipse\里面包含eclipse.exe、eclipse.ini、plugins\、features\、configuration\。这个configuration目录存的是 OSGi 框架的运行时状态第一次启动时生成后面如果启动异常删掉它让 Eclipse 重建能解决相当一部分「昨天还好好的今天打不开」的问题。eclipse.ini是启动参数文件控制 JVM 路径、堆大小、GC 策略。改它之前先备份因为格式要求很死——-vm参数必须单独占一行JVM 路径必须写在下一行写在同一行会被忽略且不报错。MinGW 走的是安装程序装到C:\MinGW装完目录下会有bin、include、lib、libexec四个关键目录。bin里是可执行文件include里是头文件lib里是静态库和导入库。装完之后建议先在资源管理器里点进去确认bin目录下确实有gcc.exe和mingw32-make.exe有些精简包会缺g等到写 C 才发现就晚了。工作区workspace的位置不要放在C:\eclipse下面。原因很实际将来升级 Eclipse 时最省事的做法是删掉旧目录解压新的工作区放在里面就一起没了。注意整套路径里不要出现空格和中文。C:\Program Files\这种带空格的路径会让 CDT 生成的构建命令行在引号处理上出岔子中文路径则在错误解析和链接阶段都可能出问题且报错信息往往指向别处。3.2 系统变量 Path 与用户变量三件套Path 的作用是让系统在任何目录下都能找到gcc.exe。在「系统属性 → 高级 → 环境变量」里编辑系统变量Path在末尾追加C:\MinGW\bin;。这里有个细节文档特意强调了如果原来的 Path 值不是以分号结尾追加时必须在C:\MinGW\bin;前面补一个分号做分隔否则最后两段路径会粘成一个不存在的路径。图形界面操作容易手滑我一般用 PowerShell 直接改顺便规避另一个坑——setx命令在值超过 1024 个字符时会静默截断Path 稍微长一点就会中招而且不可逆。# 以管理员身份运行 PowerShell $mingwBin C:\MinGW\bin $oldPath [Environment]::GetEnvironmentVariable(Path, Machine) # 先判断是否已经存在避免重复追加导致 Path 越来越长 if ($oldPath -notlike *$mingwBin*) { # 用 .NET 方法写入不受 setx 的 1024 字符限制 [Environment]::SetEnvironmentVariable(Path, $oldPath;$mingwBin, Machine) Write-Host 已追加 $mingwBin } else { Write-Host Path 中已存在跳过 }这段脚本做了三件事读取机器级 Path、做幂等判断、写回。Machine这个作用域参数对应「系统变量」如果换成User就是用户变量。幂等判断看着多余但调试期间反复执行几次就会明白它的价值——重复追加会让 Path 变成一长串重复项排查时非常干扰视线。接下来是三个用户变量。文档给的取值是LIBRARY_PATH为C:\MinGW\libC_INCLUDE_PATH为C:\MinGW\includeCPLUS_INCLUDE_PATH为一串以分号分隔的目录。最后这个变量的值最需要注意# C 标准库头文件分布在不同层级的目录里必须全部列出 [Environment]::SetEnvironmentVariable(LIBRARY_PATH, C:\MinGW\lib, User) [Environment]::SetEnvironmentVariable(C_INCLUDE_PATH, C:\MinGW\include, User) # 注意c 后面的版本号目录示例中的 3.2.3随 gcc 版本变化 # 必须去 C:\MinGW\include\c\ 下看一眼实际目录名再填 $cxxInclude ( C:\MinGW\include\c, C:\MinGW\include\c\3.2.3, C:\MinGW\include\c\3.2.3\mingw32, C:\MinGW\include\c\3.2.3\backward, C:\MinGW\include ) -join ; [Environment]::SetEnvironmentVariable(CPLUS_INCLUDE_PATH, $cxxInclude, User)CPLUS_INCLUDE_PATH里那个带版本号的目录是硬编码的装完新版本 MinGW 之后旧值就失效了而且不会报错表现是某些 C 标准头找不到。我一般会把C:\MinGW\include\c这一层也加进去多一层兜底。还有一点必须说清楚改完环境变量已经打开的 Eclipse 不会自动感知。Eclipse 在启动时把当时的进程环境整份继承下来之后系统变量怎么改都跟它无关。所以改完变量的第一件事是彻底退出 Eclipse 再重新启动不是关窗口是确认进程真的退出了。3.3 命令行验证工具链是否真的通了在打开 Eclipse 之前先用命令行把工具链单独验一遍。这一步是整个排错体系的锚点如果命令行能编问题就在 Eclipse 配置层如果命令行都编不了问题就在系统和 MinGW 本身压根不用打开 Eclipse 浪费时间。:: 1. 确认路径解析到的是哪一份可执行文件机器上有多套工具链时尤其重要 where gcc where g where mingw32-make :: 2. 看版本和内置的搜索路径输出里会列出 include 和 library 的实际搜索顺序 gcc -v mingw32-make -v :: 3. 确认 JDK 可用Eclipse 自身的运行前提 java -versionwhere比gcc -v更值得先跑因为它告诉你系统到底找到的是哪一个gcc.exe。机器上装过其他编译器套件的话Path 里排在前面的会赢这时候你配的C:\MinGW\bin就是个摆设。gcc -v的输出末尾会打印一串搜索目录那才是编译时真正生效的路径比对着环境变量猜测靠谱得多。命令行能出版本号只是第一步还要实际编一个文件。准备一个最小用例/* hello.c —— 只依赖标准库用来验证工具链端到端可用 */ #include stdio.h int main(void) { printf(hello from mingw\n); return 0; }cd /d C:\work\hello :: -Wall 打开常用警告-g 生成调试符号这两项建议从第一个工程就带上 gcc -Wall -g hello.c -o hello.exe :: 直接运行产物确认 exe 能起得来 hello.exe三条命令走通、屏幕上打出hello from mingw说明编译器、链接器、运行时库、Path 全部正常。这一步编不过的话去看gcc -v打印的搜索路径和where gcc的结果八成是路径没生效或者 MinGW 装漏了组件。4. CDT 参数配置与第一个工程从 PE Parser 到自动编译工具链在命令行层面验证通过之后剩下的工作都是「让 CDT 正确调用它」。这一层出问题的表现形式很固定构建时提示找不到make、构建成功但可执行文件不被识别、运行菜单里没有本地应用选项。这三个症状对应三个不同的配置点逐个处理就行。4.1 Preferences 里的 Binary Parser 与 Make 命令先解决 make。CDT 发起构建时默认调用的命令名是make而 MinGW 提供的构建工具叫mingw32-make.exe。名字对不上构建直接失败控制台里会看到类似Cannot run program make的提示。文档给的解法很务实不去改每个工程的构建命令而是把C:\MinGW\bin\mingw32-make.exe复制一份改名成make.exe。这样 CDT 的默认命令名不用动所有新建工程开箱即用。:: 复制一份并改名为 make让 CDT 的默认命令名能找到它 copy C:\MinGW\bin\mingw32-make.exe C:\MinGW\bin\make.exe :: 验证两个名字都应该能出版本号 make -v mingw32-make -v这个做法的代价要说清楚升级或重装 MinGW 时make.exe会被覆盖掉得重新复制一遍而且如果机器上还有别的构建工具也提供了make.exe且排在 Path 前面你调到的就不是这一份。所以复制完之后立刻用where make确认路径别等到出问题再回头查。另一条路是改工程配置右键工程 → Properties → C/C Build → Builder Settings把 Build command 从make改成mingw32-make。这条路干净但每个新工程都要改一次托管工程还得进.cproject里翻。两种做法各有取舍我一般在新机器上用复制法快速起步等项目稳定了再切回改配置的写法。再解决 Binary Parser。CDT 构建完之后要去读产物文件解析出里面的符号和段信息用于错误定位、可执行文件识别、断点设置。解析器要跟产物的二进制格式匹配Windows 下 gcc 产出的是 PE/COFF 格式所以必须选 PE Windows Parser。入口在 Window → Preferences → C/C → New CDT Project Wizard → Makefile Project → Binary Parser不同 CDT 版本的菜单层级略有差异认准 Binary Parser 这一项即可。勾选PE Windows Parser把ELF Parser等其他选项取消掉。文档明确要求「将其他选项取消选择」原因是不取消的话 CDT 会依次尝试多个解析器遇到不匹配的格式时在错误日志里刷一堆解析失败的信息干扰真正的错误。提示这个 Preferences 只对新建工程生效。已经建好的工程要单独改右键工程 → Properties → C/C Build → Settings → Binary Parsers同样勾 PE Windows Parser。改了首选项却发现老工程还是认不出 exe十有八九是漏了这一步。4.2 新建托管工程与 Hello World 的目录结构Eclipse 里所有代码都必须挂在一个 Project 下不能对着一个孤立的.c文件直接编译。这是它的项目模型决定的也意味着「临时写两行试试」这种场景得先建个工程。新建入口是 File → New → C Project或 C Project。对话框里有几个关键选择Project type 分两类。Executable下的Hello World C Project属于托管工程Managed MakeCDT 会根据你选的工具链自动生成 makefile源文件增删、编译选项改动都自动反映到构建里不用手写一行 makefile。Makefile project则要求你自己维护 makefileCDT 只负责调用。新手直接用托管工程省掉一整套 makefile 语法学习成本。Toolchain 要选MinGW GCC。这一步如果没选对后面构建时会调到一个不存在的编译器报错信息跟 Path 没配好的表现几乎一样。建完之后看左侧 Project Explorer目录结构大致是这样hello/ ├── .project # 工程元数据工程名、性质nature、构建器 ├── .cproject # 工具链配置编译器路径、包含目录、编译选项、解析器 ├── src/ │ └── hello.c # 源码目录 └── Debug/ ├── src/ # 每个源文件对应的 .o 目标文件 ├── makefile # CDT 自动生成的构建脚本 └── hello.exe # 最终产物.project和.cproject是两个隐藏文件它们才是工程的真实定义。.cproject里存了工具链的绝对路径和 ID所以把整个工程目录拷到另一台机器上经常会失效——那台机器的 MinGW 路径或者 CDT 版本对不上就得重新配。想跨机器复用不要拷工程目录拷源码目录重新建工程更省事。4.3 编译、运行与输出位置托管工程的构建是自动触发的只要 Project → Build Automatically 处于勾选状态保存文件就会触发一次增量编译。构建信息输出在下方的 Console 视图里切到 CDT Build Console 页签编译错误会在编辑器左侧的行号旁打红叉鼠标悬停能看到完整报错。自动构建的好处是反馈快坏处是文件多的时候每次保存都跑一遍机器慢会卡。工程大起来之后我会把自动构建关掉改成手动点锤子图标或者按 CtrlB。运行的方式是右键可执行文件 → Run As → Local C/C Application程序的stdout会打到 Console 视图里。这里有个容易被误判的点如果程序是从 Run 菜单的运行配置启动的工作目录Working directory默认可能是工程根目录而不是Debug目录程序里用相对路径读文件就会读不到。运行配置的 Arguments 页签里可以显式指定工作目录和命令行参数需要读外部文件时一定要在这里设。产物位置也值得记一下托管工程默认把.o、makefile、.exe全部放在Debug/下。想改成Release或者自定义目录在 Project Properties → C/C Build → Builder Settings 里改 Build directory同时记得把编译选项从调试版带-g换成优化版否则发布出去的二进制会带着调试信息、体积偏大。5. 避坑与排查make 找不到、红叉不消失、控制台空着这套环境的报错有个共同特点不同的根因会给出高度相似的提示。所以排查不能靠猜得按「系统环境 → 命令行 → Eclipse 环境 → 工程配置 → 代码」这个由外到内的顺序逐层排除每层用一个明确的判据确认通过再往下走。5.1 五类高频翻车现场现象一构建时提示Cannot run program make: Launching failed工程上一个文件都没编。原因CDT 找不到名为make的可执行文件。可能是C:\MinGW\bin没进 Path可能是进了 Path 但 Eclipse 是在改 Path 之前启动的也可能是mingw32-make.exe没被复制成make.exe。解决先开一个新的命令行窗口跑where make。有输出说明系统层没问题那就是 Eclipse 进程环境陈旧彻底退出重启没输出说明复制或 Path 这两步有一步没做成回去补。别在 Eclipse 的错误日志里找线索这里的信息量不如命令行一条where。现象二构建完全成功Console 里一路绿灯但右键 exe 时 Run As 菜单里没有 Local C/C Application。原因CDT 没认出这个文件是可执行程序。绝大多数情况是 Binary Parser 选错了——选成 ELF Parser 去解析 PE 格式的 exe解析失败后 CDT 就不把它当成可运行产物。解决进 Project Properties → C/C Build → Settings → Binary Parsers只勾PE Windows Parser取消其他全部然后 Clean 一次重新构建。Clean 这一步不能省因为解析结果有缓存改完配置不重新构建的话界面上的表现不会变。现象三程序跑起来了但 Console 里一个字都没有或者窗口一闪就没了。原因分两种。一种是程序本身没有输出或者输出被缓冲没刷出来另一种是 Console 视图当前停在别的页签上比如停在 CDT Build Console程序的标准输出其实在另一个 Console 里。解决先看 Console 视图右上角有没有多个 Console 图标点开切换。确认不是页签问题之后在main返回前加一行fflush(stdout);或者改用fprintf(stderr, ...)输出——stderr是无缓冲的能立刻看到。如果连stderr都没输出那就是程序压根没进main回去检查运行配置里指定的可执行文件路径是不是旧产物。现象四工程放在带中文或者空格的目录下构建报No rule to make target或者链接阶段报找不到文件。原因CDT 生成的 makefile 和传给 gcc 的命令行参数在路径含空格时引号转义处理不完整路径被从空格处截断成了两段。中文路径则可能在编码转换环节出问题报错信息里的路径看着是对的实际传给编译器的字节已经变了。解决把工作区和工程目录整体挪到纯英文、无空格的路径下比如C:\work\。这是唯一彻底的办法改配置绕不过去。挪完之后要在 Eclipse 里重新 Import 工程不能直接在旧工作区里改路径。现象五改了 Path 和环境变量命令行里gcc -v正常Eclipse 里构建还是报找不到编译器。原因Eclipse 启动时把父进程的环境整份复制走了之后系统变量怎么改都不影响已经在跑的进程。更隐蔽的一种情况是从任务栏固定图标或者开始菜单启动 Eclipse它继承的是启动器缓存的环境比直接从命令行启动更陈旧。解决完全退出 Eclipse任务管理器确认eclipse.exe进程消失再从命令行启动一次eclipse.exe这样它继承的是当前 shell 的最新环境。确认这样能行之后以后再从图标启动就没问题了因为系统环境已经刷新。5.2 一份可以照抄的自检顺序上面五条覆盖了大部分场景但真正卡住人的往往是「不知道属于哪一条」。这时候按固定顺序走一遍比对着报错信息瞎猜快得多。第一步开一个全新的命令行窗口不是已经开着的旧窗口跑where gcc和gcc -v。这一步验证的是系统层跟 Eclipse 一点关系没有。第二步在命令行里手工编译那个最小hello.c。这一步验证编译器、链接器、运行时库是否完整。编不过就到此为止去修 MinGW。第三步跑where make。没有输出说明复制那一步漏了补上。第四步完全重启 Eclipse新建一个Hello World C Project工具链选 MinGW GCC其他全默认直接构建。新工程能过说明问题在原工程的.cproject配置上新工程也过不了说明 Preferences 层的 Binary Parser 或者 make 命令有问题。第五步进 Preferences 确认 PE Windows Parser 已勾选、其他解析器已取消再进 Project Properties 确认同样的设置Clean 后重新构建。这个顺序的价值在于每一步都有一个明确的通过判据不会出现「改了一堆设置不知道哪个起了作用」的局面。血泪经验是不要在没做第一步的情况下直接去动 Eclipse 的配置那样改十次有九次是白改。6. 把环境验证成可复用模板编译选项、调试符号与目录约定环境配通只是起点。真正省时间的是把验证过的配置固化成模板下一个工程直接复制不用重新走一遍 Preferences。我一般会建一个名为c-template的空工程工具链选 MinGW GCC然后在 Project Properties → C/C Build → Settings → Tool Settings 里把编译选项一次配好之后所有新工程都从这个模板复制。选项作用什么时候调整-Wall打开常用警告始终开启-Wextra补充一批不常用但有用的警告始终开启-g生成调试符号GDB 断点依赖它调试阶段必开发布版去掉-O0关闭优化保证单步调试时行号对得上调试阶段用发布版换-O2-stdc99指定语言标准避免不同 gcc 版本默认值不一致按项目要求固定这些选项在 Eclipse 里对应的位置分散在 Dialect、Warnings、Debugging、Optimization 四个分类下配好之后可以只复制.cproject到新工程比每次手点快得多。不过.cproject里含工具链 ID 和绝对路径跨机器复制之前得确认目标机器上的 CDT 版本和 MinGW 路径一致不一致就得重新配一遍。命令行层面的等价写法是这样用来验证 Eclipse 里配出来的命令行到底长什么样:: 调试版带符号、无优化、开全套警告 gcc -Wall -Wextra -g -O0 -stdc99 src\hello.c -o Debug\hello.exe :: 发布版去符号、开优化体积和速度都会明显变化 gcc -Wall -Wextra -O2 -stdc99 src\hello.c -o Release\hello.exe对比这两条命令的输出文件大小能直观看出-g带来的开销。我在排查「Eclipse 里编出来的程序和命令行编出来的行为不一致」这类玄学问题时就是靠把 Eclipse 的构建命令行打印出来Project Properties → C/C Build → 勾选 Build command 相关选项或者直接看Debug/makefile和这两条对照通常一次就能定位到差异在哪个编译选项上。从那以后我每次配新环境都会先在命令行把hello.c编通、把where gcc和where make的结果截图存下来再打开 Eclipse。这样后面任何一步出问题都能立刻判断是环境层还是 IDE 层不至于在一堆设置里反复横跳。希望帮到你。本文还有配套的精品资源点击获取