您应该
syscall.ForkExec()从
syscall包装中获取。
请注意，这
fork()是在根本不使用任何线程的情况下发明的，并且一个进程中始终只有一个执行线程，因此分叉是安全的。使用Go，情况完全不同，因为它大量使用OS级线程来为其goroutine调度提供动力。
现在，
fork(2)在Linux上未经修饰的子进程将
fork(2)在所有活动线程中只有一个线程（在父进程中调用的线程），包括Go运行时使用的一些关键线程。基本上，这意味着您根本
无法期望子进程能够继续执行Go代码， 并且唯一明智的选择就是立即执行
exec(2)。注意这
syscall.ForkExec()就是应该使用的。
现在进一步考虑问题。我
fork(2)想说，如今，直接调用唯一有用的是“尽力而为异步过程状态快照”，即Redis使用的那种。该技术依赖于以下事实：子进程从其父进程继承了所有内存数据页，但是OS使用写时复制技术无法真正复制所有数据，因此子进程可以坐在那里并保存所有数据结构到磁盘，而其父级却在自己的地址空间中修改它们。可以想到的其他所有用途都
fork()意味着Instant
exec()，这就是
exec.Command()et al的用途，那么为什么不使用它呢？
