go程序不应自行fork守护进程，因runtime不支持且危险；应交由systemd（linux）或双进程互保（windows）管理，核心是正确生命周期控制而非进程形态。
Go 程序不该自己 fork 成守护进程，这是 runtime 明确不支持的危险操作；真正可靠的守护方式，是交给操作系统本身——Linux 用 systemd，Windows 用双进程互保。
为什么不能在 Go 里调用 syscall.Fork() 实现 daemonize
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，核心不是“怎么 daemon”，而是“怎么让 systemd 正确感知你的进程”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
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 下双进程互保的最小可行实现
没有 systemd，就得靠程序自己“诈尸”：主程序和守护进程互相检查 PID 文件 + Windows API 确认存活。
- 用命令行参数区分角色：
if 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 上没做双向存活检查，都会让看似健壮的互保逻辑在真实崩溃场景中彻底失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
