云环境中Go服务进程崩溃需依赖Kubernetes的livenessProbe与restartPolicy自动恢复，须设memory limits防OOMKilled，用显式http.Server异步启动并验证DB/Redis等核心依赖实现就绪检查，严防goroutine泄漏，配置热更新应使用viper.WatchConfig并挂载K8s Secret管理敏感信息。
云环境里单个 Go 服务进程挂了怎么办
Go 服务本身不自带进程守护或自动重启能力，go run 或直接执行二进制在云上一旦 panic、OOM 或被 OOMKilled，进程就彻底消失，请求立即中断。必须靠外部机制兜底。
- 容器编排平台（如 Kubernetes）是首选：通过
livenessProbe检测进程健康，配合restartPolicy: Always实现秒级拉起 - 避免用
systemd或supervisord托管容器内进程——这违反容器“一个容器一个进程”原则，且无法感知 Pod 生命周期 - Kubernetes 中务必设置
resources.limits.memory，否则 cgroup 不限制内存，Go runtime 可能因 GC 压力持续增长直至被节点强制 kill，且无 graceful shutdown 机会
HTTP 服务启动时端口被占或就绪检查失败
Go 的 http.ListenAndServe 默认阻塞，若启动阶段依赖未就绪（如 DB 连接超时、配置中心拉取失败），服务会卡住或 panic，导致 readiness probe 失败，K8s 认为它“未就绪”，流量永不打入。
- 使用
http.Server显式启动，配合srv.ListenAndServe()异步调用，主 goroutine 留给初始化逻辑 - 就绪检查（readiness）不应只 ping
/healthz，而应验证核心依赖：比如DB.PingContext()、redis.Ping()，任一失败返回 503 - 避免在
init()里做重操作——它阻塞整个包加载，错误难以定位；把初始化逻辑收拢到main()或独立setup()函数中，便于加 timeout 和重试
goroutine 泄漏导致内存持续上涨
云环境资源按需计费，goroutine 泄漏不会立刻 crash，但会缓慢吃光内存，触发 OOMKill，表现为 Pod 频繁重启、监控显示 go_goroutines 指标单边上涨。
- 所有带
go func() {...}()的地方，必须确认退出条件：要么有明确 channel 关闭信号，要么有 context.Done() 监听 - 慎用
time.AfterFunc或time.Tick启动 goroutine——它们不随 parent context 取消，容易堆积 - 上线前用
pprof抓取 goroutine profile：curl http://localhost:6060/debug/pprof/goroutine?debug=2
，重点关注状态为select或chan receive且数量异常的堆栈
配置热更新与多实例一致性问题
云上多副本部署时，若配置从本地文件读取，更新配置需滚动发布；若从 etcd/Consul 拉取，又面临监听失效、连接断开后不重连、变更未通知到所有实例等问题。
立即学习“go语言免费学习笔记（深入）”；
- 不要自己写 long-polling 监听配置——用成熟库如
github.com/spf13/viper+viper.WatchConfig()，它内部已处理重连和事件分发 - 配置变更后，避免直接修改全局变量（如
globalTimeout），改用原子值（atomic.Int64）或 sync.Once 控制 reload 逻辑 - 敏感配置（如数据库密码）绝不能硬编码或放镜像里，统一走 K8s
Secret挂载，且设置readOnly: true防止误写
