★ FEATURED ARTICLE 很多刚接触 C/C 的朋友第一反应是装一个全功能的 IDE把编辑器、编译器、调试器打包在一起用。但实际上把 GCC 和 Sublime Text 拆开组合成一套独立的 C/C 开发环境在很多场景下反而更轻、更好用也更贴近编译原理本身。这篇文章就是基于 GCC 和 Sublime 从零搭建这套环境从下载编译器、配置环境变量到手写构建系统、定位编码和路径问题会把每一步背后的原因和坑都讲清楚。适合看这篇文章的人主要有三类刚开始学 C/C、但希望搞清楚编译过程而不是靠 IDE“一键运行”的人经常写算法题、只需要快速编译测试单文件的人以及电脑配置不算高受够了 IDE 启动慢和工程文件臃肿的人。当然如果你现在正准备做一个真正的大型软件项目建议还是用成熟的 IDE 来管理工程和调试这套轻量组合的价值在于“让你掌控编译的每个细节”而不是替你做所有事情。1. 想清楚为什么选“编辑器加编译器”而不是开箱即用的 IDE1.1 谁是这套环境的真正目标用户先说一个我观察到的真实现象不少用 IDE 的初学者遇到编译错误时只知道截图问别人“这里为什么报错”却说不清编译、链接到底是什么。换成 Sublime GCC 之后编译命令是自己写的报错信息直接贴在眼前哪怕只是加一个-Wall参数都能明显感觉到自己对错误的掌控感变强了。这套环境最适合的是这几类场景学习 C 语言或 C 语法阶段代码量不大不需要工程管理。刷算法题、写竞赛程序每次只需要编译运行一个或者几个文件。电脑性能有限Sublime 启动时间和内存占用都远低于主流 IDE。想进一步理解编译流程预处理、编译、汇编、链接每一条命令都看得见。它也明确不适合一些场景大型项目里上百个源文件需要依赖管理、需要图形化断点调试、需要重命名重构等高级 IDE 功能这些不是 Sublime 的强项。所以这篇文章不是说“你必须抛弃 IDE”而是说“你应该多掌握一套可控、可迁移的工具组合”。1.2 GCC 和 Sublime 的分工逻辑很多新人会把“开发环境”理解成一个大一统的软件但拆开看会更清晰GCC 是编译器集合负责把.c或.cpp文件转换成机器可执行的程序。gcc主要用于 Cg主要用于 C二者在链接 C 标准库时有差异。Sublime Text 是编辑器负责代码高亮、编辑操作、调用构建命令。真正让两者连起来的是“构建系统Build System”本质上就是一份告诉 Sublime“按下快捷键后执行什么命令”的配置文件。这套组合的底层逻辑和 CI/CD 很像不是靠一个黑盒按钮而是把“如何编译”这件事显式地写出来。哪天你换到 Linux 服务器上开发学到的这些编译参数和思路依然完全适用IDE 的工程文件却很难带走。工具组合启动速度配置成本项目管理调试体验适合场景主流 IDE较慢低开箱即用强图形化断点大型项目、刚入门且不想折腾的人Sublime GCC极快中需手动配置弱命令行 gdb学习编译原理、刷题、轻量开发VSCode GCC较快中需要配 tasks中较好平衡型选择插件生态丰富我的建议是不要把这套环境当作 IDE 的“残缺替代品”而是当作理解编译原理的实践课。等你在 Sublime 里手动配置过一次 GCC 参数后再回去用 IDE反而会更容易看懂 IDE 的构建日志。2. 先把 GCC 装好MinGW-w64 的获取、PATH 配置与验证2.1 Windows 上安装 MinGW-w64 的关键步骤Linux 和 macOS 系统自带或可快速安装 GCC这里先重点讲 Windows因为 Windows 上安装 GCC 的坑最多。Windows 本身不自带 GCC常用的是 MinGW-w64 项目它就是 GCC 在 Windows 上的移植版本。下载时要注意几个点这些坑我基本都踩过确认系统是 64 位还是 32 位绝大多数现代电脑都是 64 位选择x86_64版本。选择异常处理模型时新手推荐seh64 位下的标准选择而不是sjlj线程模型建议选posix比win32更接近 Linux 下的 GNU 环境后面用 C 标准线程库时兼容性更好。下载完成后解压到一个“全英文、无空格”的路径。我建议解压到类似C:\mingw64这种目录避免后续构建系统拼接路径出幺蛾子。解压完成后先确认目录里是不是真的有编译器本体。正常情况下你应该能看到C:\mingw64\bin\gcc.exe C:\mingw64\bin\g.exe C:\mingw64\bin\gdb.exe这里特别提醒gdb.exe是调试器如果你之后想用命令行调试一定要确认它存在。有些精简版只带编译器不带调试器到时候会花时间补装。2.2 环境变量配置与验证方法安装完成后要让终端能直接找到g。Windows 的做法是把C:\mingw64\bin加入系统环境变量的Path中。具体流程右键“此电脑” - “属性” - “高级系统设置” - “环境变量”。在“用户变量”中找到Path点击编辑。新建一条填入C:\mingw64\bin然后一路确定。关闭所有已经打开的命令行窗口重新打开一个新的。这里最容易被忽略的就是第四步环境变量修改后已经打开的终端窗口不会自动刷新。你自己如果之前开着“命令提示符”改完环境变量后直接在里面输入g --version大概率还是报“不是内部或外部命令”。不用怀疑配错了先把所有窗口都关掉再重开。验证命令如下g --version如果能看到版本信息例如g (MinGW-W64 ...) 12.2.0说明安装成功。再顺手确认一下gcc --version和gdb --version这三条都有输出编译器环境就算基础可用了。2.3 Linux 和 macOS 下的等效操作如果用的是 Linux安装通常只是几条命令的事sudo apt update sudo apt install gcc g gdb makemacOS 上最简单的是安装命令行开发者工具xcode-select --install这会安装 Apple 包中的clang以gcc开头的命令通常会被链到clang。如果想用真正的 GNU GCC一般建议通过homebrew安装不过这里不展开了。重点是无论哪个平台核心验证方式都一样在终端执行g --version。2.4 验证编译器对 C 标准的支持很多人在后面报错不是因为没装好 GCC而是因为 GCC 默认使用的 C 标准太老。GCC 不同版本的默认语言标准不一样。举例来说老版本默认可能是gnu98或gnu11如果你用了auto、lambda、if constexpr等新特性就可能报语法错误。所以建议在编译命令里显式指定标准g -stdc17 test.cpp -o test你可以先写一个简单测试文件验证#include iostream #include vector int main() { std::vectorint v{1, 2, 3}; for (auto x : v) { std::cout x ; } std::cout \n; return 0; }然后按上面的命令编译。如果能正确输出1 2 3说明编译器和你指定的 C17 标准都能正常工作。这一步其实是在提前排除“标准版本太老”这一类莫名其妙的问题。2.5 常见错误g 不是内部或外部命令这可能是初学者遇到的最频繁报错完整的排查链路是这样的在终端输入where g。能返回路径说明系统可以找到不能返回说明环境变量里根本没有可用条目。如果where g有结果再执行g --version。有版本输出就说明可用若提示不是可执行程序说明那个路径下的g.exe损坏或者不是正常的 MinGW 文件。检查Path里的条目是不是精确到了bin目录。有人把C:\mingw64加进去了甚至把自定义下载目录加进去了都不对必须是存在gcc.exe、g.exe的那个文件夹。确认修改环境变量后是否关闭了所有旧终端、重新打开了新终端。如果这些都对但还是找不到后面多半是 Sublime 的问题如果 Sublime 在环境变量修改前就已经启动它内部的环境变量也是旧的需要重启 Sublime 再试一次。这一步很多人会忽略因为终端里已经验证通过了Sublime 却还报错。3. Sublime Text 侧的准备工作包管理器与基础设置3.1 版本选择与 Package Control 安装Sublime Text 本身是商业软件但可以下载评估版无限制使用。建议直接用 Sublime Text 4不要停留在 3。原因在于 Sublime Text 4 对多光标、自动补全、主题渲染都有明显改进而且部分插件资源也开始向 4 倾斜。装好 Sublime 后第一件事是装包管理器 Package Control。Sublime Text 4 的安装方式很简单打开命令面板快捷键是CtrlShiftP。输入Install Package Control回车。等待右下角弹出成功提示即可。如果你看到的是老版本 Sublime Text 3可能需要在控制台粘贴官方提供的安装代码。流程是 Ctrl打开控制台粘贴脚本回车。但既然能用新版本我建议直接升到 4少折腾一些兼容性问题。Package Control 的作用类似于 IDE 里的插件市场。安装完成后再呼出命令面板输入Package Control: Install Package就可以搜索并安装扩展。理想状态下整个过程不需要重启编辑器插件会自动加载。3.2 推荐安装的包不要贪多够用就好很多人一上手就开始疯狂装插件结果每个插件都在角落里弹提示写代码的专注度反而下降了。我个人的建议是最开始只装这几个包名作用备注Easy C提供一些常用的 C 代码片段补全适合新手记忆常用代码结构SublimeLinter代码静态检查框架配合下面一个包使用SublimeLinter-gcc调用 g 做实时语法检查需要配置 g 路径ConvertToUTF8解决打开 GBK 编码文件乱码国内老项目很实用SideBarTools增强侧边栏的文件操作功能装了之后右键菜单更顺手不建议一开始就装一堆补全包因为 Sublime 的定位是极简轻快。如果你发现某个包没有及时更新或者明显拖慢了启动速度直接移除即可。Sublime 的插件市场生态很成熟但“朴素”才是它的核心竞争力。3.3 基础设置Tab 缩进、换行符、字体安装完包管理器后建议先做几个基础设置。打开方式Preferences - Settings会弹出一个 JSON 配置文件。默认设置是只读的我们在右侧的用户设置文件里覆盖即可。例如{ tab_size: 4, translate_tabs_to_spaces: true, font_size: 10, highlight_line: true, save_on_focus_lost: true, default_line_ending: unix, trim_trailing_white_space_on_save: true }这些配置的作用分别是把 Tab 统一为四个空格这是主流项目的代码规范编辑器失去焦点时自动保存避免忘记CtrlS保存时自动去掉行尾多余空格默认使用 Unix 换行符避免在 Windows 和 Linux 之间切换时出现行尾风格混乱。default_line_ending是很多新手容易忽略的设置。如果默认换行符是 Windows 的CRLF而将来你把代码提交到 Linux 服务器或者 CI 环境可能会出现\r导致的执行错误。尽早统一为unix会省掉不少跨平台麻烦。3.4 文件关联与侧边栏项目管理写 C/C 时建议直接用“文件夹”方式打开你的代码目录File - Open Folder。这样侧边栏会显示整个目录树便于查看多个源文件和头文件。项目并不需要类似 IDE 那样生成.sln之类的工程文件一个普通文件夹就足够了。如果你在不同的项目之间切换可以用Project - Add Folder to Project管理。Sublime 的项目文件是.sublime-project本质上就是一个 JSON 配置后续可以在里面配置特定项目的构建参数这个后面讲构建系统时会涉及到。4. 构建系统让 Sublime 一键调用 GCC 的灵魂配置4.1 新建一个 C 构建系统文件打开Tools - Build System - New Build System...Sublime 会创建一个 JSON 模板保存时命名成类似C17.sublime-build的文件。保存后这个构建系统就会出现在Tools - Build System菜单中。这个 JSON 文件的核心价值是把“编译运行当前文件”这个动作按键化。按下CtrlBSublime 就会用你定义的shell_cmd去执行命令。命令的执行逻辑完全由你掌控。先解释 Sublime 内置的几个变量这些在拼接命令时非常常用变量含义示例${file}当前文件的完整路径C:\Users\xxx\main.cpp${file_path}当前文件所在目录C:\Users\xxx${file_base_name}当前文件名去掉扩展名main${folder}当前项目根目录打开文件夹时生效${packages}用户包目录插件经常使用在 Windows 下Sublime 执行命令时默认走cmd /c。也就是说你写的命令会被拼接成一条 shell 命令执行所以支持、||这类操作符。4.2 单文件编译运行最快能跑通的方式如果你写的是单文件程序比如刷题或学习语法推荐直接用这个配置{ shell_cmd: g -stdc17 -Wall -g \${file}\ -o \${file_path}/${file_base_name}.exe\ start cmd /c \\${file_path}/${file_base_name}.exe\ pause\, working_dir: ${file_path}, file_regex: ^(..[^:]*):([0-9]):?([0-9])?:? (.*)$, selector: source.c, source.c }这一条命令拆开理解g -stdc17 -Wall -g以 C17 标准编译开启常见警告生成调试信息。${file}传入当前文件路径注意路径外面有引号这是为了防止路径中有空格。-o ${file_path}/${file_base_name}.exe将可执行文件输出到当前目录名字和源文件保持一致。 start cmd /c ...编译成功后新开一个命令提示符窗口运行程序并在运行结束后暂停防止交互式程序一闪而过。file_regex是用于解析编译错误输出的正则表达式。GCC 的报错格式一般是main.cpp:5:9: error: ‘cout’ was not declared in this scope通过这个正则Sublime 就能把“文件名、行号、列号”提取出来让报错信息在底部面板里可以直接点击跳转。selector告诉 Sublime当 build system 设置为“自动”时遇到 C/C 源文件就优先使用这个构建方案。如果你不想每次都弹出一个新窗口运行程序而只想在面板里看到编译结果可以换成更简单的配置{ shell_cmd: g -stdc17 -Wall -g \${file}\ -o \${file_path}/${file_base_name}.exe\, working_dir: ${file_path}, file_regex: ^(.*):([0-9]):([0-9]):\\s(.*)$, selector: source.c, source.c }这种配置下编译成功时面板干干净净编译失败时错误信息直接在面板里显示。如果只是检查语法甚至可以在命令后面加-fsyntax-only只做语法和语义检查不生成可执行文件速度更快一点。4.3 项目级编译接上 Makefile 或 CMake当代码量增加到多个.cpp文件时单条g命令会变得又长又乱这时候就该用构建工具了。最传统的是 Makefile。如果你在项目目录里已经有 Makefile构建系统可以简化成这样{ shell_cmd: make, working_dir: ${folder:${file_path}}, file_regex: ^(..[^:]*):([0-9]):?([0-9])?:? (.*)$, selector: source.c, source.c }这里使用${folder:${file_path}}意思是优先取项目根目录取不到再用当前文件所在目录。working_dir很重要因为make默认在当前目录下找 Makefile。如果项目使用 CMake我一般会预先执行一次cmake -S . -B build然后构建系统配置成{ shell_cmd: cmake --build build, working_dir: ${folder:${file_path}}, file_regex: ^(..[^:]*):([0-9]):?([0-9])?:? (.*)$, selector: source.c, source.c }这样按CtrlBSublime 就会调用 CMake 的构建命令而不需要你手动去记忆 target 名称。4.4 多个构建方案的切换用 variant 区分编译、运行、清理Sublime Text 4 支持在一个.sublime-build文件中定义多个variant。简单理解就是同一个文件中可以包含“编译运行”“仅编译”“清理”等不同操作按下CtrlShiftB时手动选择。示例{ build_systems: [ { name: C 17 编译运行, shell_cmd: g -stdc17 -Wall -g \${file}\ -o \${file_path}/${file_base_name}.exe\ start cmd /c \\${file_path}/${file_base_name}.exe\ pause\, selector: source.c, source.c }, { name: C 17 仅编译, shell_cmd: g -stdc17 -Wall -g \${file}\ -o \${file_path}/${file_base_name}.exe\, selector: source.c, source.c }, { name: 清理当前目录, shell_cmd: del /q \${file_path}\\\*.exe \${file_path}\\\*.o, selector: source.c, source.c } ] }配置好后Tools - Build System菜单会自动出现名为“C 17 编译运行”的并行选项CtrlB使用列表中的第一个CtrlShiftB可以弹出选择。这个方法适合我把“编译”和“编译运行”分成两个独立的操作避免每次想在面板看编译结果时程序又另外弹出一个窗口。4.5 为什么这些编译参数要这样写写到这里我把参数背后的原因说明白因为很多初学者只会抄配置不知道每次改动会带来什么影响。-stdc17限定语言标准。如果不指定编译器会用默认标准老版本下的默认标准往往偏低明明是正确的 C17 代码却报错。显式声明标准等于告诉编译器“按这个规则来”。-Wall打开常见警告。它不是“把警告当错误”而是尽量显示潜在问题。比如变量未初始化、比较类型不匹配等这类问题在大型项目中往往是 bug 的温床。-g生成调试信息。加上这个选项可执行文件会变大一些但是后续用 GDB 调试时才能看到源码行号和变量值。-o指定输出文件名。默认情况下编译器会生成a.exe这类默认名称多次编译容易互相覆盖。显式指定为源文件同名方便识别。路径加引号几乎所有“编译失败cannot open output file”的问题都是因为路径里有空格而路径没有加引号。这套参数非常通用即使之后从 Sublime 迁到终端、脚本、CI逻辑也都一样。5. 真实踩坑记录从乱码到路径名空格一次排查到位5.1 中文乱码UTF-8 与 GBK 的相爱相杀中文乱码可能是国内开发者在 Windows 环境里遇到的最让人头痛的问题。现象也很典型源码里的中文注释在 Sublime 里看着正常一编译运行输出窗口变成乱码。问题根源是编码不一致。GCC 默认读取 UTF-8 编码的源文件而 Windows 传统的命令提示符默认代码页可能是936GBK。如果源代码文件本身是 GBK 编码编译器会误解某些中文字符如果控制台是 GBK 而程序输出 UTF-8 字符串也会乱码。我的处理方法是按顺序做三件事所有新写的源码统一保存为 UTF-8 编码。Sublime 右下角能看到当前编码确保是 UTF-8。Windows 终端尝试切换到 UTF-8 代码页在运行程序前输入chcp 65001。老项目实在改不了编码的在编译命令里显式告诉 GCC 源文件和执行环境各自的编码例如-finput-charsetGBK -fexec-charsetUTF-8。如果只是为了打开别人发的 GBK 老代码不要在 Sublime 里硬看装上ConvertToUTF8插件会更省心。乱码问题表面看是编码转换本质上就是“编译器读入时的编码”和“终端显示时的编码”要配对。搞清楚了这一点以后在任何环境下都能冷静处理。5.2 PATH 修改后终端还是找不到 g明明按照步骤把C:\mingw64\bin加进了Path重新打开终端后输入g --version依然提示“不是内部或外部命令”这是很常见的挫败时刻。排查顺序如下先确认环境变量确实生效新开窗口输入echo %PATH%查看输出里有没有C:\mingw64\bin。如果没有说明你编辑的是某个被误建的高优先级变量或者根本没有点“新建”只是打开了编辑框却未生效。用文件管理器打开C:\mingw64\bin确认g.exe真的存在。有些下载包解压后是多层目录真正的bin在第二层或者第三层。如果上面都正常回忆一下你是不是从“已经打开的旧终端”里执行的命令。修改环境变量对旧进程无效必须完全关闭后重开。最后如果 Sublime 里还是不行重启 Sublime。Sublime 启动时读取的环境变量是当时的系统状态不会实时感知你后来添加的路径。这个坑 90% 是最后两个原因没重开终端或者没重开 Sublime。5.3 文件名或目录带空格导致的编译失败有一次我在测试时把项目放在C:\Users\test\my project\目录下文件名叫hello world.cpp。在 Sublime 里按CtrlB报错信息是g: fatal error: no input files compilation terminated.原因很明确hello world.cpp被 shell 当成了两个不同的参数hello和world.cpp。解决办法就是在构建系统的shell_cmd中对引用文件路径的地方都加上英文引号。例如shell_cmd: g -stdc17 \${file}\ -o \${file_path}/${file_base_name}.exe\如果你用的是 macOS 或 Linux类似问题也会发生在文件名包含空格时。这类问题一旦发生往往十几分钟还摸不着头脑但理解了 shell 的参数解析规则后就很简单每个含空格的路径都是一个整体参数必须加引号。经验之谈学习阶段干脆把整个项目和所有文件都放在“全英文、无空格”的路径下比如D:\dev\c_practice\从源头减少这类问题。5.4 头文件找不到iostream 报错的标准排查链路报错信息是fatal error: iostream: No such file or directory先不要急着重新安装编译器。这条报错的含义是“找不到 C 标准库头文件”而不是“没有这个头文件名”。GCC 虽然能运行但它的系统头文件搜索路径没有正确生效。排查思路确认你的g是哪来的。如果系统里有多个编译器比如某个软件内嵌的老版本 GCC导致优先级抢占了 MinGW-w64 的路径需要检查where g返回的具体位置。用gcc -v查看配置信息重点看SEARCH_DIRS是否包含include和include/c相关目录。如果搜索路径异常通常是安装包版本不完整或者解压时文件丢失。在 Sublime 里报错、终端里却正常多半是 Sublime 没有感知到最新的环境变量重启 Sublime 即可。另外如果你的项目要额外引用外部库头文件比如下载了某个第三方库别忘了在编译命令里加-I你的头文件目录。这个问题不是编译器坏了而是你没有告诉编译器“去哪里找头文件”。5.5 编译报错但 Sublime 面板里看不到完整输出有些构建系统里使用了start cmd /c ...程序运行输出都被引导到了新开的黑色窗口Sublime 底部面板里只显示执行过程看不到编译错误细节。如果你希望在面板里直接查看完整输出最简单的做法是把构建系统换成“仅编译”版本。如果连“仅编译”都没有显示报错文本检查file_regex是否匹配当前 GCC 的报错格式。新版 GCC 的报错默认带了颜色还可能包含几行源码上下文正则匹配不到时Sublime 会认为没有可跳转的错误行但底部的原始输出还是应该存在的。我通常的做法是先移除start cmd让编译输出直接拉到面板里看确认逻辑没问题后需要交互式输入的程序再用弹窗版。这样既能看到错误又能运行交互式程序互不干扰。6. 把这套环境变顺手实时检查、格式化与调试6.1 用 SublimeLinter 做实时语法检查编译是最后一道防线但要等按下CtrlB才知道结果效率还是偏低。SublimeLinter 可以在你输入代码的同时调用g做后台语法检查红色波浪线直接标出可疑代码。安装步骤通过 Package Control 安装SublimeLinter和SublimeLinter-gcc。打开Preferences - Package Settings - SublimeLinter - Settings在高亮用户配置中指定可执行文件的路径。如果没有额外配置默认会使用 PATH 环境变量中的g。一个简单的用户配置示例{ user: { linters: { gcc: { args: [-stdc17, -Wall], include_paths: [${folder}/include] } }, linter_mode: background } }linter_mode可以设成background或save前者边写边查后者保存时才查。背景模式稍微占用一点 CPU但对轻量代码来说无感。需要注意的是SublimeLinter 默认可能要求你激活许可证或者绑定电脑这些弹窗提示按流程处理即可。6.2 接上 clang-format 做代码风格统一很多团队用 clang-format 管理 C 代码风格。Sublime 里可以安装相关包实现一键格式化也可以直接调用命令行。最简单的用法是项目根目录放一个.clang-format文件例如BasedOnStyle: Google IndentWidth: 4 ColumnLimit: 100然后在 Sublime 里安装ClangFormat之类的包通过命令面板Format File对当前文件格式化。如果你暂时不想装包也可以直接在终端里运行clang-format -i main.cpp-i表示直接修改原文件。格式化的意义不只是“好看”而是消除团队协作时因风格不一致导致的无效 diff让代码审阅真正集中在逻辑改动上。6.3 调试的两种浅方案从 printf 到 GDB 批处理很多人问 Sublime 怎么断点调试。我得说实话图形化调试在 Sublime 里不是最好的体验。如果调试需求强烈我建议平行使用 IDE。但如果只是偶尔要用有两条可行的路。方案一用输出日志定位。在关键路径上打印变量、状态然后用构建系统运行程序看输出。这个方法朴实但非常有效尤其适合逻辑性错误。方案二用 GDB 批处理模式。构建时确保带了-g参数然后构建系统配置一个调试方案{ shell_cmd: gdb -batch -ex run -ex bt --args \${file_path}/${file_base_name}.exe\, working_dir: ${file_path}, selector: source.c, source.c }这个命令的意思是启动 GDB运行程序如果程序崩溃输出调用栈回溯。批处理模式不会进入交互式断点界面但对崩溃问题非常高效。如果确实需要逐行调试还是打开终端输入gdb program.exe手动操作更灵活。6.4 我自己长期使用下来的习惯最终我把这套环境稳定下来靠的其实是几个小习惯保留两个构建方案一个是“编译运行”适合交互式程序另一个是“仅编译”适合快速检查语法和编译错误。写算法题时新建文件后直接用CtrlShiftP呼出构建列表选中编译运行基本不用碰鼠标。打开旧代码尽量先确认编码再用 ConvertToUTF8 转码而不是直接改文件内容。所有项目目录都保持全英文且不带空格目录规范本身就是减少踩坑的有效手段。如果你刚开始从 IDE 向 Sublime 迁移我的建议是前两周先别装任何插件用默认配置把编译流程跑通然后每周加一个插件试用一段时间。一旦某个插件让你觉得“没有它反而更顺”果断删掉。轻量工具的优势在于你能控制它的每一个行为别让插件把它变得像 IDE 一样臃肿。
阅读完成 · 觉得有帮助？
