Go程序无法自身实现进程级自动重启，需依赖systemd等外部管理器；panic仅能通过recover在goroutine内拦截，主进程崩溃后须由systemd配置Restart=on-failure等策略拉起。
Go 程序如何捕获 panic 并触发自动重启
Go 本身不提供进程级自动重启能力，panic 发生后默认会终止当前 goroutine，若未被 recover 捕获且发生在主 goroutine，整个进程退出。要实现“异常恢复”，必须在启动入口做两层防护：一是用 recover 拦截关键 goroutine 的 panic；二是让主进程在崩溃后由外部或自身重新拉起。
- 仅靠
defer + recover无法恢复已崩溃的 HTTP server 或长期运行的协程——它只能防止 panic 向上冒泡导致进程退出，但业务逻辑已中断，连接可能卡死 - 不要在
http.HandlerFunc里写裸recover，应统一用中间件包装，例如：func recoverMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { defer func() { if err := recover(); err != nil { log.Printf("panic recovered: %v", err) http.Error(w, "Internal Server Error", http.StatusInternalServerError) } }() next.ServeHTTP(w, r) }) } - 对非 HTTP 场景（如 CLI 工具、后台 worker），可在
main()最外层加defer recover，记录错误后调用os.Exit(1)，交由进程管理器重启
用 systemd 实现 Go 服务崩溃后自动拉起
生产环境最可靠的方式不是“Go 自己重启自己”，而是交给操作系统级进程管理器。systemd 是 Linux 主流选择，它能监听进程退出状态、限制重启频率、设置依赖关系。
- 关键配置项必须包含：
Restart=on-failure（仅在非 0 退出时重启）、RestartSec=5（间隔 5 秒）、StartLimitIntervalSec=60和StartLimitBurst=3（防雪崩，1 分钟内最多重启 3 次） - 确保你的 Go 二进制有完整路径和明确工作目录，否则
WorkingDirectory缺失会导致日志写入失败或配置文件找不到 - 示例 unit 文件：
[Unit] Description=My Go Service After=network.target [Service] Type=simple User=myapp WorkingDirectory=/opt/myapp ExecStart=/opt/myapp/bin/myapp --config /opt/myapp/config.yaml Restart=on-failure RestartSec=5 StartLimitIntervalSec=60 StartLimitBurst=3 LimitNOFILE=65536 [Install] WantedBy=multi-user.target
Go 进程内实现软重启（graceful restart）的边界条件
“软重启”指不中断已有连接、平滑加载新代码，这需要配合构建流程和信号处理。Go 标准库不支持热更新，所谓“重启”本质是 fork 新进程 + 关闭旧进程。
openclaw-github-config-impact
下载
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 必须使用
syscall.SIGUSR2（Linux/macOS）或syscall.SIGTERM配合外部工具（如kill -USR2 $(pidof myapp)），不能依赖SIGHUP—— 它在容器中常被忽略或转发异常 - 新进程启动后，需通过 Unix domain socket 或文件传递 listener fd，旧进程在收到确认后才关闭；标准库
net/http.Server.Shutdown只负责优雅关连，不解决 fork 和 fd 传递 - 推荐直接使用成熟库如
github.com/freddierice/kingpin或更轻量的github.com/alexedwards/zero，避免手写fork/exec+SCM_RIGHTS通信，极易出错
为什么不要在 Go 里用 exec.Command(“./myapp”) 自重启
看似简单，实则埋雷。这种“自举式重启”在容器、systemd、supervisord 等环境中会破坏进程树结构和生命周期管理。
立即学习“go语言免费学习笔记（深入）”；
- 子进程脱离父进程控制，systemd 将无法追踪其状态，
systemctl status显示 inactive，journalctl -u myapp日志断层 - 多次自重启可能导致文件描述符泄漏（如日志文件句柄未 close）、端口被占用（旧进程未完全退出）、PID 文件残留
- 如果程序启用了
pprof或expvar，两个实例同时监听同一端口会直接 panic：“address already in use” - 真正需要动态更新的场景，应走发布流程：构建新二进制 → 替换旧文件 → 发送信号触发 reload，而不是运行时 fork
Restart=on-failure 就够用；剩下 5% 的灰度更新或配置热加载，得靠外部协调机制，而不是让 Go 程序自己 fork 自己。 
