systemd服务启动后立即退出，是因为Go程序默认前台运行但未保持阻塞；应设Type=simple、Restart=always、避免os.Exit、main函数需阻塞（如http.ListenAndServe或select{}）。
为什么 systemd 服务启动后立即退出？
多数人写完 go build 得到二进制，配好 systemd unit 文件，systemctl start myapp 却显示 inactive (dead)。根本原因是 Go 程序默认以「前台进程」方式运行，但 systemd 要求服务要么是长期驻留的守护进程（Type=simple），要么明确 fork 出子进程（Type=forking）——而 Go 标准库不自动做 daemon 化，也不默认重定向 stdout/stderr。
解决办法不是加 & 或用 nohup，而是让 systemd 正确识别进程生命周期：
-
Type=simple（推荐）：Go 程序保持前台运行，不自行 exit，stdout/stderr 不关闭；systemd 认为主进程 PID 启动即服务就绪 - 务必设置
Restart=always和RestartSec=5，否则崩溃后不会自拉起 - 去掉
StandardInput=null以外的任何Standard*覆盖，除非你真要接管日志流 - 避免在 Go 代码里调用
os.Exit(0)或提前 return，main 函数应阻塞（如http.ListenAndServe或select{}）
如何写一个安全可用的 myapp.service 文件？
直接抄模板容易漏掉权限和路径细节。以下是最小可行配置，假设你的 Go 二进制放在 /opt/myapp/myapp，配置文件在 /etc/myapp/config.yaml：
[Unit] Description=My Go Application After=network.target [Service] Type=simple User=myapp Group=myapp WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/myapp -config /etc/myapp/config.yaml Restart=always RestartSec=5 LimitNOFILE=65536 Environment="GODEBUG=madvdontneed=1" SyslogIdentifier=myapp [Install] WantedBy=multi-user.target
关键点：
立即学习“go语言免费学习笔记（深入）”；
- 必须用非 root 用户运行（
User=myapp），提前创建该用户并赋予二进制和配置文件读取权限 -
WorkingDirectory影响相对路径加载（比如 Go 里os.ReadFile("conf.json")） -
Environment可用于调试内存行为，生产环境可删 - 不要加
PrivateTmp=yes，除非你确认程序不依赖/tmp下已有文件
Go 程序怎么配合 systemd 做健康检查？
systemd 本身不提供 HTTP 探活，但可以通过 ExecStartPre + ExecStopPost 或外部工具间接实现。更实际的做法是利用 Go 自身暴露健康端点，并让 systemd 通过 systemctl is-active 或日志关键词判断状态。
如果你需要精确控制 readiness，建议在 Go 中监听 SIGUSR1（systemd 支持发送该信号）或使用 socket activation（较重）：
- 最简方式：在
main()启动后打印一行"ready: true"到 stdout，然后用journalctl -u myapp -n 1 | grep "ready:"辅助判断 - 若用
http.Server，加一个/healthzhandler 返回 200，再配合curl -f http://localhost:8080/healthz || exit 1写成脚本供运维调用 - 避免在
ExecStartPre里做耗时检查（如连 DB），这会拖慢服务启动，应放到 Go 程序内部初始化逻辑中
为什么 journalctl 看不到 Go 的 panic 日志？
Go 默认 panic 输出到 stderr，但若你在代码里用了 log.SetOutput(ioutil.Discard) 或重定向了 os.Stderr，systemd 就收不到日志。另外，某些 panic（如栈溢出）可能来不及刷缓冲就终止进程。
确保日志可见的实操项：
- 不要覆盖
os.Stderr，如有日志库（如zap），设其EncoderConfig.EncodeLevel = zapcore.CapitalColorLevelEncoder并输出到os.Stderr - 在 main 开头加
log.SetFlags(log.LstdFlags | log.Lshortfile)，便于定位 - 用
journalctl -u myapp -o cat查看原始输出（去掉时间戳等干扰） - 如果 panic 频繁发生且无日志，检查是否启用了
GOMAXPROCS过高导致调度异常，或存在未 recover 的 goroutine panic
真正麻烦的是那些没打日志、又不 panic 的静默失败——比如监听端口被占用却没报错退出。这类问题得靠 lsof -i :8080 和 strace -p $(pgrep myapp) 配合排查，不能只盯 journalctl。
