当父进程调用 os.Exit() 或被信号终止时，其控制的终端文件描述符（尤其是 Stdin）通常会被关闭，导致子进程无法继续读取用户输入；本文介绍一种轻量级、可靠的技术方案：让父进程“退居幕后”——释放资源后仅等待子进程结束，而非直接退出。
当父进程调用 `os.exit()` 或被信号终止时，其控制的终端文件描述符（尤其是 `stdin`）通常会被关闭，导致子进程无法继续读取用户输入；本文介绍一种轻量级、可靠的技术方案：让父进程“退居幕后”——释放资源后仅等待子进程结束，而非直接退出。
在 Go 中，通过 exec.Command 启动子进程并继承 os.Stdin 时，看似实现了终端输入的无缝传递，但一旦父进程主动退出（如调用 os.Exit(0)）或被 SIGTERM 杀死，操作系统会回收其所有打开的文件描述符。由于终端（tty）的会话控制权与父进程强绑定，Stdin（通常是 fd 0）随之关闭，子进程后续调用 bufio.NewReader(os.Stdin).ReadString('\n') 等操作将立即返回 io.EOF 或阻塞失败——这正是问题的根本原因。
⚠️ 需要明确的关键点是：Stdout 和 Stderr 可以安全继承并长期使用，但 Stdin 的生命周期严格依赖于前台控制进程的存在。这是 POSIX 终端会话机制决定的，无法通过简单重定向或 syscall.Dup() 绕过。
✅ 正确解法：父进程不退出，而是“降级为守护协作者”
即：启动子进程后，父进程主动释放所有非必要资源（关闭不再需要的文件句柄、取消 goroutine 泄漏、重置信号处理器），然后仅阻塞等待子进程退出。这样终端控制权平稳移交，Stdin 持续有效。
以下是推荐实现：
package main
import (
"os"
"os/exec"
"syscall"
)
func main() {
cmd := exec.Command("./child-program") // 替换为实际子程序路径
cmd.Stdout = os.Stdout
cmd.Stdin = os.Stdin
cmd.Stderr = os.Stderr
// 启动子进程（非阻塞）
if err := cmd.Start(); err != nil {
panic(err)
}
// 【关键】父进程主动放弃对 Stdin/Stdout/Stderr 的“所有权”
// 仅保留对子进程的 wait 能力，不关闭任何 fd
// （注意：不要调用 os.Stdin.Close()！）
// 可选：重置信号处理，避免干扰子进程
signal.Ignore(syscall.SIGINT, syscall.SIGTERM)
// 父进程进入等待状态 —— 轻量、无资源占用、不退出
if err := cmd.Wait(); err != nil {
// 子进程异常退出时记录，但父进程仍自然结束
os.Exit(1)
}
}
? 注意事项：
- 禁止调用 os.Exit() 或向自身发送 SIGKILL：这会强制终结整个进程上下文，包括终端连接；
- 不要关闭 os.Stdin：即使你认为“已转交”，关闭它会破坏底层 tty 文件描述符；
- 子进程不应尝试 kill(getppid(), SIGTERM)：现代 shell（如 bash/zsh）在父进程退出后，会将孤儿进程 re-parent 给 init（PID 1），此时 getppid() 不再是原父进程；
- 若需真正“脱离父进程”（如 daemonize），应使用 syscall.Setsid() + syscall.Setpgid(0, 0) 并重定向全部 stdio 到 /dev/tty 或日志文件——但这已超出交互式终端场景，属于后台服务范畴。
总结：解决该问题的核心不是“抢救 Stdin”，而是重构进程协作模型——让父进程成为子进程的“静默监护者”而非“临时中介”。这种设计既符合 Unix 进程生命周期规范，又保证了交互式 I/O 的稳定性与可预测性。
