sublime中g++报错根本原因是环境链断裂，需确保cmd中g++ --version成功、mingw-w64的bin目录（如c:mingwin）加入系统path而非用户path，并验证where g++返回路径。
Sublime Text 启动快、打开大文件不卡，不是靠“优化技巧”堆出来的，而是因为它的核心压根没走通用运行时那一套——main() 函数一执行，就直接调用 Win32 API 或 Cocoa，连虚拟机或渲染进程都不启动。
为什么 Sublime 的 g++ 构建系统在 Windows 上常报错找不到命令
这不是 Sublime 的问题，是环境链断在了最底层：Sublime 的构建系统本质就是调用 shell 执行 g++，如果 CMD 里敲 g++ --version 都失败，那任何 .sublime-build 配置都白搭。
- MinGW-w64 的
bin/目录必须完整加入系统PATH，不能只加C:MinGW—— 正确路径是C:MinGWin - Windows 10/11 用户容易忽略“用户变量”和“系统变量”的区别，务必加到“系统变量”里的
PATH，否则 Sublime（以非当前用户上下文启动时）看不到 - 安装完后不要只信“安装成功”，必须在全新 CMD 窗口里验证
where g++是否返回路径，而不是依赖之前已打开的终端缓存
shell_cmd 里用 && 还是 ;？PowerShell 用户最容易栽在这里
Sublime 默认使用系统默认 shell，Windows 下通常是 cmd.exe，而 && 是 cmd 的逻辑执行符；PowerShell 不认这个，它用 ; 分隔命令。但 Sublime 并不自动切换语法——你写 &&，它就原样扔给当前 shell 执行。
- 如果你在 Windows 上启用了 PowerShell 为默认终端（比如通过 Windows Terminal 设置），又没改 Sublime 的 shell 配置，
"shell_cmd": "g++ ... && .\a.exe"会直接报错：“无法将‘&&’识别为……” - 临时解法：把
&&换成&&（注意 HTML 实体转义）或干脆拆成两个variants：一个编译，一个单独运行 - 根本解法：在 Sublime 的
Preferences → Settings里加一行"shell": "cmd"，强制回退到 cmd 环境
异步分块加载不是“功能开关”，而是架构硬约束
你没法在设置里关掉“异步加载”来“让文件读得更全”，因为 Sublime 根本没有“全加载”这个模式——它的文本缓冲区（TextBuffer）从设计上就只映射可视区域 + 小范围预取，其余内容始终留在磁盘页缓存或 mmap 区域里。
- 打开 500MB 日志时底部显示
Loading…，不是它在“努力加载”，而是在建立首屏的内存映射视图，通常 1–2 秒内完成 - 滚动到底部时出现短暂空白，不是卡顿，是触发了新块的按需加载；此时
ps aux | grep sublime显示 RSS 内存几乎不变，证明没把整文件拖进 RAM - 别试图用插件强行
view.substr(Region(0, view.size()))读全内容——这会瞬间拉爆内存，尤其在老机器上可能触发 OOM Killer
真正难调的从来不是配置项，而是你误以为自己能控制的那些东西：比如认为“禁用插件就能更快”，却没意识到 Sublime 的插件沙箱本身就在 Python 子进程中惰性加载，不触发就不占资源；又比如反复修改 file_regex 去匹配错误格式，却忘了 GCC 输出随版本微调，g++-12 和 g++-13 的 warning 行正则并不完全兼容。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
