go程序不该自己fork成守护进程，因runtime状态无法安全复制，易致goroutine卡死、信号丢失或崩溃；应前台运行，交由systemd（type=simple）或daemonize等外部工具管理生命周期。
Go 程序不该自己 fork 成守护进程——runtime 状态无法安全复制，大概率导致 goroutine 卡死、信号丢失或静默崩溃。真正可靠的做法是：让程序保持前台运行，把“后台化”和“自动重启”交给操作系统级守护机制。
Type=simple 是 systemd 下唯一安全的选项
systemd 的 Type=forking 要求你的程序 fork 后立刻退出父进程，并上报子进程 PID；但 Go runtime 不支持安全 fork，强行实现会导致子进程调度器异常，甚至触发 fatal error: fork/exec failed（尤其在 Go 1.20+）。Type=simple 才是正解：它把整个二进制当一个普通前台进程启动，由 systemd 全权管理生命周期。
- service 文件里必须显式写
Type=simple（不能省略，默认虽是 simple，但明确写出更防误配） - 删掉代码里所有
syscall.Fork、syscall.Setsid、os.Chdir、重定向os.Stdin/os.Stdout的逻辑 - 确保
main()不退出：用http.ListenAndServe、signal.Notify配合select{}或其他阻塞方式维持运行
Restart=on-failure 生效的前提是你没覆盖退出码
systemd 只对非零退出码且非 signal 终止的进程触发 Restart=on-failure。而 Go panic 默认调用 os.Exit(2)，本应被拉起；但如果你在 main() 结尾加了 os.Exit(0)，就等于把所有错误都“抹平”成正常退出，systemd 就不再干预。
- 禁止在
main()末尾无条件写os.Exit(0) - panic 场景下，让程序自然退出（即不捕获 panic 后再
os.Exit） - 务必加上
RestartSec=5，否则连续崩溃会触发 systemd 默认 rate-limit（10 秒内最多 5 次），之后静默拒绝重启
日志必须走 stderr，别在 Go 里 log.SetOutput(f)
systemd 依赖继承的 stdout/stderr fd 来捕获日志。一旦你在 Go 中调用 log.SetOutput 把输出重定向到文件，journalctl -u your.service 就完全查不到任何内容，debug 成本陡增。
- 开发和上线阶段都保持
log.Printf、fmt.Println直接打到默认 stderr - 如需落盘，用 systemd 的
StandardOutput=journal+console+ 外部轮转（如logrotate），而不是 Go 自己打开文件写 - service 文件中加
StandardOutput=journal和StandardError=journal（默认已启用，显式写出更稳妥）
老系统（如 CentOS 6）不用硬刚 fork，用 daemonize 工具包装
如果你必须跑在没有 systemd 的环境，别在 Go 代码里手写 daemon 逻辑。那不是帮你，是埋雷。用系统级工具完成标准 daemon 化流程，它不碰 Go runtime，只做 fork/setsid/umask/重定向这些 POSIX 层操作，风险可控。
- Debian/Ubuntu：
sudo apt install daemonize；CentOS/RHEL：sudo yum install daemonize - 启动命令示例：
daemonize -p /var/run/myapp.pid -u nobody /opt/myapp/myserver -
-u nobody避免 root 权限滥用；-p提供标准 PID 文件路径，方便外部监控脚本读取
daemonize 这类外部机制，才是经过十年以上生产验证的守门人。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
