go程序不该自行daemonize，因手动调用syscall.fork()会破坏运行时调度器、cgo状态和stdio缓冲区，导致崩溃或fatal error；正确做法是前台运行，交由systemd等外部工具管理。
Go 程序不该自己 daemonize，强行 fork 会触发 fatal error: fork/exec failed 或 goroutine 调度崩溃；正确做法是让程序前台运行，交由 systemd、supervisord 等外部工具管理。
为什么 Go 里调用 syscall.Fork() 是危险操作
Go 运行时对 fork() 有内部锁（syscall.ForkLock）保护，仅允许 exec.Command 等极少数路径安全使用。手动调用会导致：
- 子进程继承未 flush 的 stdio 缓冲区、处于中间状态的 M/P/G 调度器
- cgo 线程状态不一致，可能 panic 或 segfault
- Go 1.20+ 后 runtime 强化限制，直接报
fatal error: fork/exec failed - 即使看似成功，后续
setsid()在非 main goroutine 执行也会引发竞态
systemd 配置中 Type=simple 和 Type=forking 的关键区别
选错 Type 会让 systemd 误判进程生命周期，导致服务启动失败或无法重启：
-
Type=simple：默认值，systemd 认为ExecStart启动的进程就是主服务进程，直接监控其状态——这是 Go 程序唯一推荐的模式 -
Type=forking：要求程序自己 fork 并立刻退出父进程，systemd 等待 fork 后的子进程 PID 文件或信号——这正是你要避免的手动 daemonize 场景 - 若误配
Type=forking，而 Go 程序没按规范输出 PID 或提前退出，systemd 会卡在activating (auto-restart)或直接报failed with result 'exit-code'
Restart=on-failure 不生效的三个常见原因
Go 服务崩溃后没自动拉起，往往不是 systemd 问题，而是退出码或配置没对齐：
- Go
panic默认 exit(2)，属于on-failure范围；但若你在main()结尾加了os.Exit(0)，就覆盖了所有错误退出码，systemd 视为“正常退出” - 没设
RestartSec=5：systemd 默认有速率限制（10s 内最多 5 次重启），连续崩溃会静默拒绝后续尝试 - 日志被重定向：在代码里调用
log.SetOutput(f)把日志写到文件，systemd 就收不到 stdout/stderr，journalctl -u your.service查不到任何线索
需要兼容旧系统（如 CentOS 6）时的替代方案
systemd 不可用时，优先用成熟进程管理器，而非手写守护逻辑：
-
supervisord：支持日志轮转、HTTP 接口、自动重启，配置简单，适合多进程或需细粒度控制的场景 -
start-stop-daemon：Debian/Ubuntu 系统自带，轻量可靠，配合 init.d 脚本即可 - 绝对避免用
os.StartProcess()+syscall.Setsid()模拟 daemon 流程——它和直接 fork 一样绕过 runtime 协调，风险相同
真正容易被忽略的是：Go 程序的日志输出方式和退出码语义，比守护化逻辑本身更能决定 systemd 是否能稳定接管。别碰 fork，盯紧 os.Exit 和 log.SetOutput。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
