go服务systemd管理失败主因是main()过早退出、type配置错误及日志未接入journal；须用type=simple、restart=always、user/group指定非root用户，并配置standardoutput/error=journal，监听sigterm优雅退出。
Go服务用systemd管理失败，90%是因为main()退出太快、Type配置错、日志没进journal——不是代码写错了，是systemd根本没机会接管进程。
为什么systemctl start后立刻显示inactive (dead)
Go程序启动后秒退，不是崩溃，而是main()函数执行完就os.Exit(0)或自然返回了。systemd在Type=simple下认为进程“启动即就绪”，但一发现主进程退出，立刻标记为inactive (dead)。
- 别在
main()里调用os.Exit()、log.Fatal()或提前return；HTTP服务必须用http.ListenAndServe()阻塞，非HTTP服务可用select{}长期等待 -
Type=forking绝对不要用：Go不double-fork，systemd找不到PID，状态永远activating (start)然后超时 -
Type=notify只在显式调用github.com/coreos/go-systemd/v22/daemon.SdNotify时才有效，否则systemd等不到READY=1，直接失败
service文件里最关键的三个配置项
很多人只改ExecStart，漏掉这三项，服务能启但极不稳定。
-
Type=simple：必须显式声明，告诉systemd“这个二进制就是主进程，别等fork” -
Restart=always：不是on-failure——Go panic、OOM kill、甚至被SIGKILL干掉，都得拉起来；搭配RestartSec=5防雪崩 -
User和Group不能留空或写root：创建专用用户（如sudo useradd -r -s /bin/false myapp），并确保它对ExecStart路径、WorkingDirectory、配置和日志目录有r-x/r--/w-权限
journalctl查不到日志？多半是输出没进journal
Go默认用log.Println()打到stderr，但旧版systemd（如CentOS 7）默认只把stdout接入journal，stderr被丢弃或截断。
- service文件里加
StandardOutput=journal和StandardError=journal（新版systemd默认如此，但显式写上更稳） - 删掉所有
StandardInput=null以外的Standard*覆盖（比如StandardOutput=append:/var/log/xxx），除非你真要自己轮转日志 - Go代码里别用
log.SetOutput(os.Stdout)绕开——统一走log.New(os.Stderr, "", log.LstdFlags)，systemd对stderr采集最可靠
Go怎么响应SIGTERM做优雅退出
systemd发SIGTERM后，默认等10秒（TimeoutStopSec=10）再强杀。如果Go不监听，连接会硬断、临时文件不清理、数据库连接不释放。
- 用
signal.Notify监听os.Interrupt和syscall.SIGTERM - HTTP服务需调用
srv.Shutdown()，带context超时（如5秒），再os.Exit(0) - 非HTTP服务可在收到信号后关闭channel、停止goroutine、写入最后一条日志，然后
return出main()
真正容易被忽略的是WorkingDirectory和ExecStart的绝对路径——Go里os.Open("config.yaml")这种相对路径，全靠WorkingDirectory定位；而ExecStart写./myapp或myapp，systemd根本找不到二进制。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
