Go 程序不该手动 fork 守护化，因 runtime 状态无法安全复制，易致调度异常、信号丢失或卡死；应交由 systemd 以 Type=simple 管理，配合 Restart=on-failure 和 StandardOutput=journal。
Go 程序不该自己 fork 成守护进程，强行调用 syscall.Fork 或 syscall.Syscall 极大概率导致 goroutine 调度异常、信号丢失、甚至子进程卡死。
为什么 Go 不适合手动 daemonize
传统 Unix 守护进程需 fork + setsid + chdir + 重定向 fd 等一连串系统调用，但 Go 运行时（runtime）在 fork 后无法安全复制所有状态：goroutine 栈、netpoller、CGO 线程、垃圾回收器标记位都可能处于中间态。哪怕 syscall.Fork 调用成功，后续 syscall.Setsid() 也可能因调度器未就绪而 panic。Go 官方明确不保证 fork 后行为，1.20+ 版本更强化了限制，直接触发 fatal error: fork/exec failed。
- 你写的
unsafeDaemonize()函数，在开发机上看似能跑，上线后可能隔几天才复现一次静默崩溃 - 用
exec.Command("sh", "-c", "nohup ./myapp &")同样危险——它绕过了 Go runtime 的进程生命周期管理 - 所有“自己 fork 自己”的方案，本质都是把 systemd 的活抢过来干，还干得不专业
systemd service 文件必须设 Type=simple，禁用 Type=forking
Type=forking 要求程序自己 fork 并立刻退出父进程，这正是你要避免的危险路径。systemd 会等你 fork 后的子进程 PID 上报，而 Go 程序根本没法安全提供这个 PID —— 因为 fork 后 runtime 状态不可信。
- 正确写法：
Type=simple，让 Go 程序以普通前台进程启动，由 systemd 全权接管生命周期 -
Restart=on-failure只对非零退出码生效；若代码里写了os.Exit(0)覆盖 panic，默认 exit(2)，systemd 就不会重启 - 务必加
RestartSec=5，否则连续崩溃会触发 systemd 默认的 rate-limit（10s 内最多 5 次），之后静默拒绝拉起 - 日志必须走
StandardOutput=journal，别在 Go 里用log.SetOutput(f)写文件，否则journalctl -u myapp查不到任何输出
如果必须兼容无 systemd 的老系统（如 CentOS 6）
用 daemonize 工具包装二进制，而不是在 Go 代码里实现 fork 逻辑。它只做标准 daemon 化流程，不碰 Go runtime，风险可控。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 安装：
sudo apt install daemonize（Ubuntu/Debian）或yum install daemonize（CentOS） - 启动命令：
daemonize -p /var/run/myapp.pid -u nobody /opt/myapp/myapp - PID 文件路径要和你的监控脚本（如 Monit、supervisord）保持一致，
-u nobody避免 root 权限滥用 - 注意：
daemonize本身不处理崩溃自动重启，需额外配supervisord或 shell 循环兜底
Go 程序自身只需专注「永驻」和「可终止」
main goroutine 别退出，就是最基础的守护逻辑。用 select{} 阻塞，配合 os.Signal 监听 os.Interrupt 和 syscall.SIGTERM 即可。
- 不要写
for {}空循环，CPU 占满且无法响应信号；select{}是零消耗阻塞 - 工作 goroutine 崩溃时，别用
recover()吞掉 panic——让它自然退出，靠 systemd 重启才是正解 - 若需平滑关闭（如 HTTP server 关闭连接），用
http.Server.Shutdown()+ context，但 shutdown 完成后仍要让 main 退出，交还控制权给 systemd
真正难的不是“怎么让进程不退出”，而是“怎么让退出变得可预测、可审计、可恢复”。systemd 的 journalctl、systemctl status、资源限制、依赖管理，远比手写 fork 逻辑可靠。别让 Go 程序承担 init 系统的职责。
