go程序不应自行fork成守护进程，因runtime状态无法安全复制，易致调度异常、信号丢失或卡死；应交由systemd以type=simple管理，配合restart=on-failure和standardoutput=journal。
Go 程序不该自己 fork 成守护进程，systemd 不需要你“后台化”，它要的只是一个干净、稳定、能正确退出的前台进程。
为什么 Type=simple 是唯一安全的选择
Go 运行时禁止 fork，所以 Type=forking 会直接失效：systemd 等不到子进程 fork 出来，超时后标记为 failed。而 Type=notify 要求程序调用 daemon.SdNotify，但 Go 标准库不带这个，得引入 cgo 和 systemd-devel，还容易因 signal handler 冲突导致日志丢失或 panic。只有 Type=simple 符合 Go 的运行模型——启动即就绪，崩溃即退出，无需任何额外协调。
- 别写
Type=oneshot或Type=exec：它们用于一次性命令，不适用于长期服务 - 确保
ExecStart指向绝对路径，比如/opt/myapp/bin/server，相对路径在 systemd 下工作目录不可控 - 如果程序启动后立刻退出，先检查是否在 main 中提前调用了
os.Exit(0)—— 这会让 systemd 认为“正常结束”，Restart=on-failure就不会触发
Restart=on-failure 失效的三个常见原因
systemd 只在进程以非零状态码退出时才重启，而 Go 的 panic 默认 exit(2)，看似满足条件，但实际常被掩盖：
- main 函数末尾写了
os.Exit(0)：即使前面 panic 了，也会被覆盖成 0 码退出 - 程序被
SIGKILL（kill -9）终止：systemd 不认为这是“失败”，不会重启 - 没设
RestartSec=5：连续崩溃会触发 systemd 的 rate-limit（默认 10 秒内最多 5 次），之后静默拒绝拉起
验证方式：journalctl -u myapp -n 20 查看最后几条日志里是否有 “exited, code=exited, status=2/” 或类似字样；没有则说明退出码是 0 或被信号中断。
日志进不了 journalctl 的真实原因
不是 Go 日志库有问题，而是你主动破坏了 systemd 的日志捕获链：
- 在代码里调用了
log.SetOutput(f)把日志写到文件，StandardOutput=journal就完全失效 - 用
fmt.Println或log.Printf是 OK 的，只要没重定向os.Stdout - 如果必须写文件日志，保留
os.Stdout到 stdout，再另开一个 file writer，不要替换全局输出 - 别在程序里
syscall.Dup2或os.Stdin.Fd()关闭重定向标准流——systemd 需要这些 fd 来接管日志
User= 和 WorkingDirectory= 不是可选项
省略这两项等于埋雷：
-
User=缺失 → 服务以 root 运行，哪怕只是读个配置文件也存在权限放大风险 -
WorkingDirectory=缺失 →os.Open("config.yaml")在 systemd 下默认从/开始找，必然 open: no such file or directory - 配了
User=却没配Group=→ 某些发行版（如 RHEL/CentOS）会拒绝启动 -
WorkingDirectory=必须是已存在的路径，且User=对该路径有读/执行权限
最稳妥的写法是显式声明 User=myapp、Group=myapp、WorkingDirectory=/opt/myapp，并确保目录属主匹配。
真正难的不是写 service 文件，而是让 Go 程序彻底放弃“我要后台运行”的执念——它越老老实实待在前台，systemd 就越能管好它。任何试图在代码里 fork、setsid、重定向 fd 的操作，都是在和 Go 运行时硬碰硬，迟早出事。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
