Sublime Text构建输出慢的根源在于命令执行环节，而非编辑器本身：启动延迟、IO阻塞、输出缓冲（如gcc默认全缓冲）、shell性能瓶颈（cmd/powershell慢）、错误重定向开销及编译运行耦合导致阻塞。
构建系统输出慢，本质是命令执行卡在哪儿了
Sublime Text 本身不处理编译逻辑，它只是把 shell_cmd 里写的命令交给系统 shell 执行，然后把 stdout/stderr 实时捕获到底部面板。所谓“输出慢”，90% 不是 Sublime 的锅，而是你调用的命令本身启动慢、IO 阻塞、或输出被缓冲了。比如 javac 启动 JVM 要几百毫秒，gcc -O3 编译大文件要几秒，v run 在 Windows 上若路径含空格又没加引号，会卡住等超时——这些都会让面板“迟迟没反应”。先确认是真慢，还是压根没输出：在终端里手动跑一遍构建系统里写的完整命令，看耗时和输出行为是否一致。
关掉 stderr 重定向和冗余输出能立竿见影
很多构建配置习惯性把 2>&1 或 2>/dev/null 加进 shell_cmd，看似“干净”，实则让 shell 多了一层管道转发，尤其在 Windows 上（cmd/powershell）会显著拖慢首行输出。更糟的是，有些编译器（如旧版 g++）默认开启 full buffering，当 stdout 不连终端（即连的是 Sublime 的管道）时，输出会攒满 4KB 才刷一次，导致“卡住几秒后突然刷出全部”。解决方法很简单：
- 去掉
shell_cmd末尾的2>&1，让错误单独走 stderr（Sublime 默认一并捕获） - 对 C/C++/Rust 等使用
gcc/clang的场景，在命令前加stdbuf -oL强制行缓冲："shell_cmd": "stdbuf -oL gcc -o \"$file_base_name\" \"$file\" && ./$file_base_name" - Java 构建避免用
java -jar tool.jar这类胖包，改用java -cp ... MainClass减少类加载开销
Windows 下 cmd/powershell 是性能瓶颈，换 conhost 或 wsl
Sublime 在 Windows 上默认用 cmd.exe 执行构建命令，而 cmd 启动慢、管道延迟高、不支持 ANSI 转义（影响颜色输出解析）。PowerShell 更甚，每次启动都要加载 .NET Runtime。实测启动时间：cmd ≈ 15ms，powershell ≈ 300ms+。如果你的构建命令本身很轻（比如 v run 或 python -c "print(1)"），那 cmd 启动开销就占了大头。可行方案：
- 改用
conhost.exe直接托管命令（需写成"shell_cmd": "conhost.exe cmd /c \"gcc ... && a.exe\""），但兼容性差 - 更稳的路是切到 WSL：确保已启用 WSL2，把
shell_cmd指向wsl bash -c "..."，启动快且 IO 行为更接近 Linux - 终极方案是弃用内置构建面板，用
Terminus插件新开一个真实终端 tab，运行命令——这时所有输出都是原生 tty 行为，无缓冲、无延迟
别让构建系统干 IDE 的活：分离编译与运行
很多人写一个 shell_cmd 把编译 + 运行串在一起，比如 gcc main.c -o main && ./main。这看起来方便，但问题在于：一旦运行阶段卡（比如 input() 等待输入、或程序 hang 住），整个构建流程就阻塞，面板卡死，Ctrl+C 还可能只杀掉前半段。正确做法是拆成两个 variant：
- 一个只编译：
"name": "Build", "shell_cmd": "gcc -o \"$file_base_name\" \"$file\"" - 另一个只运行（且带超时）：
"name": "Run (timeout 5s)", "shell_cmd": "timeout 5s ./$file_base_name || echo 'Program timed out'"
这样编译完立刻看到成功提示，运行失败也能明确归因，不会让一次失败拖垮整个工作流。真正需要交互的场景（如 Python input()），请直接上 SublimeREPL 或 Terminus——构建系统不是终端模拟器，硬扛只会越来越慢。
