先说一个核心结论：Go程序不应该自己调用fork来变成守护进程。这不是什么风格问题，而是runtime层面就不支持这种操作，强行去做反而会惹出一堆麻烦。真正靠谱的守护方式，是把控制权交给操作系统本身——Linux交给systemd，Windows则用双进程互保。
为什么 Go 程序不能自己 fork 成守护进程
原因很简单：Go的运行时会严格保护fork操作。调用syscall.Fork()会绕过调度器、mcache、netpoller这些关键机制，还会打乱CGO线程状态同步。结果就是，子进程可能继承一堆未flush的stdio缓冲、半死不活的goroutine栈，或者已经注册但没来得及清理的signal handler。实际测试下来，在Go 1.20及更高版本中，这种情况经常直接触发fatal error: fork/exec failed。
就算fork侥幸成功了，后续的setsid()或chdir()如果不在主goroutine中执行，很容易引发panic。更麻烦的是，os.Exit(0)在panic之后会覆盖退出码，导致systemd误以为进程是“正常退出”，从而拒绝重启。还有，手动把os.Stdout重定向到文件后，journalctl就再也收不到日志了——这显然不是我们想要的效果。
Linux 下用 systemd 管理 Go 服务的关键配置
正确的做法是写一个/etc/systemd/system/myapp.service文件。这里的关键不在于“怎么让进程daemonize”，而在于“怎么让systemd正确感知你的进程状态”。
几个核心配置点：
Type=simple是最安全的选择，systemd会在ExecStart进程启动后立即认为服务就绪。别用Type=forking或Type=notify，除非你真的调用了daemon.SdNotify。ExecStart必须使用绝对路径，比如/opt/myapp/bin/myserver。写相对路径或者只写二进制名，会导致文件找不到或者工作目录错乱。- 显式设置
WorkingDirectory=/opt/myapp，否则os.Open("config.yaml")注定失败。 - 加上
StandardOutput=journal和StandardError=journal，确保log.Printf和fmt.Println的输出都能被journalctl -u myapp捕获到。 Restart=on-failure生效的前提是，Go进程必须以非0码退出（panic默认exit(2)可以触发），且不能被signal强行终止。务必配合RestartSec=5，防止rate-limit把重启请求挡在外面。
Windows 下双进程互保的最小可行实现
Windows没有systemd，那就只能靠程序自己“诈尸”了。核心思路是：主程序和守护进程互相检查对方的PID文件，同时通过Windows API确认对方是否还活着。
具体实现方式：
- 用命令行参数区分角色：如果
len(os.Args) > 1 && os.Args[1] == "/s"，则进入守护模式。 - 将PID写入固定文件（比如
main.pid和guard.pid），双方都去读对方的PID，然后调用windows.OpenProcess(windows.PROCESS_QUERY_LIMITED_INFORMATION, ...)来验证存活状态。 - 拉起新进程必须用
exec.Command("cmd", "/c", "start", "", exePath, "/s")，这样才能保证新进程脱离父进程的生命周期。 - 主程序启动守护进程后，要异步定期检查
guard.pid是否还活着；守护进程也一样盯着main.pid。单向依赖会导致断链，一旦一方挂了，另一方就彻底失联。
核心观点
最后必须强调一点：Go服务的“守护”本质上是生命周期管理问题，不是进程形态问题。Linux上写错Type或者漏掉RestartSec，Windows上没做双向存活检查，都会让看似健壮的互保逻辑在真实崩溃场景中彻底失效。所以，关键不在于怎么fork，而在于怎么让系统正确感知和恢复你的进程。
