如何使用Golang在Windows系统启动分离式子进程？

这问题我太熟悉了！你之前用START /B失败，核心原因是**START是Windows cmd.exe的内置命令，不是独立的可执行文件**，直接用exec.Command调用当然找不到它。下面给你两种靠谱的解决方案：

方案一：通过cmd.exe间接调用START #

既然START是cmd的内置命令，那我们可以把它作为参数传给cmd.exe来执行，代码如下：

import "os/exec"

func startDetachedViaCmd(myProgram string) error {
    // /C 参数表示执行完命令后关闭cmd窗口
    cmd := exec.Command("cmd.exe", "/C", "START", "/B", myProgram)
    // 如果需要传递参数给myProgram，直接追加在后面即可：
    // cmd := exec.Command("cmd.exe", "/C", "START", "/B", myProgram, "arg1", "arg2")
    return cmd.Start()
}

这个方法简单直观，适合快速实现，但依赖cmd环境，且子进程的输出默认会和父进程隔离。

方案二：调用Windows API直接创建分离进程（更接近ForkExec的效果） #

如果你需要和Linux下syscall.ForkExec完全一致的行为——让子进程彻底脱离父进程，即使父进程退出子进程也能继续运行，那推荐直接调用Windows的CreateProcessAPI，设置DETACHED_PROCESS和CREATE_NEW_PROCESS_GROUP标志：

import (
    "syscall"
)

func startDetachedProcess(program string) error {
    si := &syscall.StartupInfo{}
    pi := &syscall.ProcessInformation{}
    
    // 把程序路径转成Windows需要的UTF16指针
    cmdLine := syscall.StringToUTF16Ptr(program)
    // 如果需要传递参数，要把参数拼到命令行里，比如：
    // cmdLine := syscall.StringToUTF16Ptr(program + " arg1 arg2")
    
    err := syscall.CreateProcess(
        nil,                // 应用程序名（设为nil的话，cmdLine要包含完整路径）
        cmdLine,            // 命令行字符串
        nil,                // 进程安全属性
        nil,                // 线程安全属性
        false,              // 是否继承父进程句柄
        syscall.CREATE_NEW_PROCESS_GROUP | syscall.DETACHED_PROCESS, // 关键标志：分离进程+新进程组
        nil,                // 环境变量（继承父进程的话设为nil）
        nil,                // 工作目录（继承父进程的话设为nil）
        si,                 // 启动信息
        pi,                 // 进程信息
    )
    if err != nil {
        return err
    }
    
    // 必须关闭进程和线程句柄，否则会造成系统资源泄漏
    syscall.CloseHandle(pi.Thread)
    syscall.CloseHandle(pi.Process)
    
    return nil
}

关键标志说明： #

• DETACHED_PROCESS：让子进程完全脱离父进程的控制台，父进程退出后子进程不受影响
• CREATE_NEW_PROCESS_GROUP：创建新的进程组，避免父进程终止时连带结束子进程

注意事项 #

1. 如果你的程序路径包含空格，一定要用引号括起来，比如：program := "C:\Program Files\myapp.exe"``
2. 传递参数时，方案一可以直接追加到exec.Command的参数列表；方案二需要把参数拼到命令行字符串里，注意格式
3. 方案二的代码更底层，不依赖cmd环境，行为和Linux的ForkExec最接近，推荐用于生产环境

内容的提问来源于stack exchange，提问作者Baptiste Donaux