Sublime Text构建系统进程卡住是因为它只发送SIGINT或关闭stdin，无法终止等待输入或派生守护进程的子进程；Ctrl+C失效因构建面板非真实终端，信号无法透传至深层子进程。
Sublime Text 构建系统启动的进程卡住不退出，不是“程序没跑完”，而是 Sublime 没真正终止子进程——它只向主进程发了 SIGINT 或关闭 stdin，但子进程（尤其是带 input()、cin、getchar() 的程序）可能还在等输入，或 spawn 了守护子进程（如 Java 的 JVM、Python 的 matplotlib 窗口），导致构建面板假死、CPU 持续占用、Ctrl+C 失效。
为什么 Ctrl+Break / Ctrl+C 在 Sublime 构建面板里经常失效
Sublime 的构建面板不是真实终端，它对子进程的信号控制非常有限：Ctrl+C 默认只发送到前台进程组，但若程序用了 system("pause")、std::cin.get() 或调用了外部 GUI（如 plt.show()），实际阻塞点可能在子 shell 或独立窗口里，而 Sublime 并未将信号透传过去。
- Windows 下用
shell_cmd走cmd /c启动的进程，Ctrl+C只能杀 cmd.exe，但 .exe 本身可能已脱离控制 - macOS/Linux 用
shell_cmd调gnome-terminal或open -a Terminal，Sublime 根本无法触达那个终端里的进程 - 即使用了
cmd数组 +"shell": true，Sublime 也只管理第一层进程，不递归 kill 子进程树
手动强制终止残留进程的实操路径
必须绕过 Sublime 的信号机制，直接从系统层面清理。关键是找到并干掉“真正在跑”的那个可执行文件进程，而不是只关掉构建面板。
- Windows：打开任务管理器 → 切换到“详细信息”页 → 搜索
python.exe、a.exe、java.exe、javaw.exe；特别注意subl.exe和sublime_text.exe是否共存，两者都得结束 - macOS：活动监视器 → 搜索
Python、JavaApplet、Terminal，或终端执行pgrep -f "python.*\.py\|java.*Main"+kill -9 - Linux：终端运行
pkill -f "python3.*${file_base_name}\|g\+\+\|java.*$(basename $file .java)"，避免误杀其他 Python 进程
构建系统里加防卡死兜底逻辑
与其事后杀进程，不如提前让程序自己“守时退出”。这不是优雅方案，但在 Sublime 环境下最可靠。
- Python：在脚本末尾加
import os; os._exit(0)（比sys.exit()更彻底，绕过 atexit） - C/C++：Windows 下
system("pause")改成fflush(stdin); getchar();，再加一句return 0;；或编译时加-D_WIN32_WINNT=0x0601启用现代控制台 API - Java：避免
Scanner阻塞，改用try (Scanner s = new Scanner(System.in)) { ... }，并在 finally 块中显式System.in.close() - 所有语言：在构建系统里用超时包装，例如 Windows 的
timeout /t 30 /nobreak && your_cmd，Linux/macOS 的timeout 30s your_cmd（需 GNU coreutils）
别依赖“自动终止”，关键靠进程隔离
真正稳定的方案，是让每次运行都在独立、可预测的上下文中——Sublime 自身不具备进程生命周期管理能力，硬靠它收尾只会反复踩坑。用 Terminus 插件接管终端 I/O，或自定义构建系统调用 gnome-terminal -- bash -c "your_cmd; read -p 'Press Enter...'"，把 stdin/stdout/tty 完整交给系统终端，才能确保 Ctrl+C 生效、进程树干净、输出不截断。这点容易被忽略：你配的不是“怎么编译”，而是“谁来负责结束”。
