vscode-cpptools的Process类通过封装启动、监控、通信与清理全链路实现进程生命周期管理：基于Emitter暴露started/exited/error事件，支持超时检测与terminate()分级终止，并在deactivate()中通过context.subscriptions统一销毁，防止孤儿进程。
vscode-cpptools 的 Process 类如何管理进程生命周期
VS Code 插件中调用外部命令（如 clang、gdb、mvn）时，不能只靠 child_process.spawn() 一扔了事——进程可能卡死、未退出、输出乱序、或在插件禁用后继续运行。vscode-cpptools 的 Process 类正是为解决这类问题设计的：它把“启动→监控→通信→清理”全链路封装进一个可复用、可取消、可监听的对象里。
关键点在于它不依赖 Node.js 原生进程对象的裸引用，而是通过内部 Emitter 暴露 started、exited、error 等事件，并在 deactivate() 阶段主动调用 kill() 或 destroy() 方法终止子进程。这意味着：即使用户关闭窗口或禁用插件，残留进程也不会继续占用 CPU 或端口。
-
Process实例必须被显式保存在插件上下文（如context.subscriptions）中，否则 GC 可能提前回收，导致无法调用销毁逻辑 - 构造时传入的
options.cwd和options.env会直接影响可执行文件能否被正确解析——尤其在 Windows 上路径分隔符和环境变量继承容易出错 - 不要在
activate()中直接new Process(...)启动长期进程；应延迟到用户触发命令或打开特定文件后才创建，避免冷启动耗时和资源浪费
为什么不能只用 spawn + on('exit')？
原生 spawn() 的 on('exit') 只能告诉你“进程结束了”，但无法区分是正常退出、被信号杀死、还是卡死无响应。更麻烦的是：如果父进程（Extension Host）崩溃或插件被热重载，子进程大概率变成孤儿进程，继续在后台运行。
vscode-cpptools 的 Process 类额外做了三件事：
- 启动后立即监听
stdout和stderr的'data'事件，并设置超时计时器（如 5 秒无输出则标记为 hang） - 提供
terminate(timeoutMs: number)方法：先发SIGTERM（Unix）或taskkill（Windows），等待超时后强制SIGKILL - 将进程 PID 记录到内部 registry，便于在
deactivate()中批量遍历并清理所有活跃实例
在 deactivate() 中安全清理外部进程的实操要点
很多插件开发者以为只要在 deactivate() 里写个 process.kill() 就完事了，结果发现有时根本杀不掉——因为 process 引用早已丢失，或子进程已 fork 出新进程（比如 java -jar xxx.jar 启动后又起了 JVM 子线程）。
正确做法是：从创建起就统一管理进程句柄。
- 所有
Process实例都 push 到context.subscriptions，利用 VS Code 自带的 dispose 链自动调用dispose()（该方法内部会触发terminate()） - 避免使用
exec()或execFile()：它们内部封装了spawn，但屏蔽了底层ChildProcess对象，导致无法精确控制生命周期 - 若必须用原生 API（如调用
git），请手动包装一层：class ManagedProcess { private proc: ChildProcess | null = null; dispose() { if (this.proc && !this.proc.killed) { this.proc.kill('SIGTERM'); setTimeout(() => this.proc?.kill('SIGKILL'), 2000); } } }
跨平台路径与可执行文件验证的实际影响
vscode-cpptools 的 Program 工厂函数会自动在 PATH 中搜索可执行文件，并校验是否具有执行权限（Unix）或扩展名是否为 .exe/.bat（Windows）。这个看似简单的步骤，实际决定了插件在不同用户环境下的鲁棒性。
如果你跳过这步，直接硬编码 /usr/bin/gcc 或 C:\MinGW\bin\gcc.exe，就会遇到以下典型问题：
- macOS 用户装了 Homebrew 版 gcc，路径是
/opt/homebrew/bin/gcc-14，硬编码路径失效 - Windows 用户用 MSYS2，
gcc在usr/bin/下但没有.exe后缀，Node.jsspawn直接报ENOENT - 某些 CI 环境 PATH 被重置，插件找不到
mvn却不报明确错误，只静默失败
所以，哪怕不用 vscode-cpptools，也建议自己实现类似逻辑：先调用 which（Unix）或 where（Windows），再用 fs.access() 校验可执行位，最后才传给 spawn。
