应围绕os/exec.cmd构建封装层并强制注入context.context：启动后检查cmd.process、拦截信号转发、用cmd.wait()回收僵尸进程、绑定context实现超时与取消控制，并统一管理多进程生命周期。
os/exec 是 Go 中管理外部进程生命周期最直接的工具，但仅靠它远远不够——你需要的是一个能响应信号、支持优雅退出、可监控状态、并避免僵尸进程的模块。核心判断是：**别自己重写进程管理逻辑，而是围绕 os/exec.Cmd 构建封装层，并强制注入 context.Context 控制权**。
用 os/exec.Cmd 启动进程时必须设置 ProcessState 检查和信号转发
很多人只调用 cmd.Start() 就以为完事了，结果子进程崩溃后主程序完全不知情，或者 SIGINT 被主进程吞掉，子进程变成孤儿。
- 启动后立即检查
cmd.Process是否非 nil，否则说明进程根本没起来（比如路径错误、权限不足） - 务必在
cmd.Wait()前用signal.Notify拦截os.Interrupt和syscall.SIGTERM，然后向子进程发送对应信号（cmd.Process.Signal()），而不是直接os.Exit() -
cmd.Wait()返回后，用cmd.ProcessState.ExitCode()和cmd.ProcessState.Success()判断真实退出原因，不要只看 error 是否为 nil
长运行子进程必须绑定 context.Context 并监听 Done()
单纯靠信号不够——超时、取消、父进程主动终止都需要统一出口。不加 context 的 os/exec 调用等于放弃控制权。
- 用
exec.CommandContext(ctx, ...)替代exec.Command(...)，这样 ctx 取消时会自动向子进程发 SIGKILL（前提是子进程未忽略该信号） - 若子进程需优雅关闭（如等待连接处理完），应在 ctx.Done() 触发后先发 SIGTERM，等待几秒再发 SIGKILL；这需要额外 goroutine 监听
ctx.Done()并执行两阶段终止 - 注意：子进程若已退出，
ctx.Done()不会触发 kill，所以cmd.Wait()仍需单独处理
避免僵尸进程的关键是确保每个 cmd.Wait() 都被执行
Go 的 os/exec 不会自动回收已退出的子进程，漏掉 Wait() 就会产生僵尸进程——尤其在频繁启停的场景下，系统资源会快速耗尽。
- 绝不能只依赖 defer cmd.Wait()：如果 cmd.Start() 失败，cmd.Wait() 会 panic
- 推荐模式：启动后立刻 go func() { _ = cmd.Wait() }()，并在主流程中用 channel 或 sync.WaitGroup 等待其完成
- 若需获取退出状态，把
cmd.Wait()结果通过 channel 发出，而不是阻塞等待——否则会卡住整个管理模块
多进程协同时，主控进程必须持有所有子进程句柄并统一回收
模块化设计里常有多个子进程（如 auth、api、worker），各自独立启动，但主控进程必须对它们有终局掌控力。
- 用 map[string]*exec.Cmd 或 slice[*exec.Cmd] 显式维护所有活跃子进程引用，避免“启动即不管”
- 提供统一的 StopAll() 方法，按反向顺序发送 SIGTERM（避免依赖链断裂），再逐个 wait
- 注意：不同子进程对信号的响应可能不同（比如有的忽略 SIGTERM），需在文档或配置中标明兼容性要求
cmd.Wait() 的调用时机和 panic 安全性，它不是锦上添花，而是防止资源泄漏的第一道防线。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
