子兮子兮

写一个能跑的服务很容易，写一个在生产环境“长期稳定运行”的服务很难。

很多 Go 服务在本地、测试环境表现良好，一上线就开始暴露各种问题：

• 偶发 panic
• 内存缓慢上涨
• 请求偶尔卡死
• 重启后状态不一致
• 日志一多就查不出问题

这些问题往往不是业务复杂导致的，而是基础设计阶段就埋下了隐患。

这篇文章从工程角度，拆解几个「决定 Go 服务是否可靠」的关键点。

一、服务生命周期管理，是第一块地基

一个典型的 Go 服务，至少经历以下阶段：

1. 启动（Init）
2. 对外提供服务（Running）
3. 优雅关闭（Shutdown）

很多项目只关心第 2 步。

常见问题

• 进程被 SIGTERM 直接 kill
• HTTP 请求还没处理完就中断
• goroutine 没退出，资源泄露

推荐的基础结构

ctx, stop := signal.NotifyContext(
	context.Background(),
	os.Interrupt,
	syscall.SIGTERM,
)
defer stop()

关键思想：

• 用 context 统一管理生命周期
• 所有后台 goroutine 都必须感知 ctx.Done()

这一步做不好，后面所有“稳定性优化”都是空谈。

二、不要让 goroutine 成为“幽灵”

Go 的并发模型很强，但也很容易被滥用。

常见反模式

go func() {
	for {
		doSomething()
	}
}()

问题在于：

• 没有退出条件
• 没有错误反馈
• 没有资源释放

时间一长，goroutine 数量不可控，问题只会在生产环境暴露。

一个简单但有效的约束原则

所有 goroutine，必须满足至少一个条件：

• 生命周期与请求绑定
• 生命周期与服务 context 绑定

例如：

go func(ctx context.Context) {
	for {
		select {
		case <-ctx.Done():
			return
		default:
			doSomething()
		}
	}
}(ctx)

能被关闭的 goroutine，才是“可维护的 goroutine”。

三、错误必须“向上游流动”

很多 Go 项目里，错误被悄悄吞掉了：

if err != nil {
	log.Error(err)
	return
}

这类代码短期没问题，长期非常危险。

原因在于

• 上层无法感知失败
• 调用链断裂
• 系统只能“看起来正常”

更合理的做法

if err != nil {
	return fmt.Errorf("数据验证失败: %w", err)
}

原则：

• 底层负责补充上下文
• 上层决定如何处理（重试 / 返回 / 降级）

这也是 Go 鼓励 error wrapping 的核心原因。

四、配置不是常量，而是“运行时输入”

很多服务把配置当成写死的常量：

const Timeout = 3 * time.Second

上线后发现：

• 超时时间不合适
• 并发数需要调整
• 日志级别想临时改

只能：改代码 → 打包 → 发版。

更合理的定位

配置是系统行为的一部分，而不是代码的一部分。

实践建议：

• 所有关键参数必须配置化
• 支持环境变量 / 配置文件
• 启动时一次性校验配置合法性

一个能动态调整配置的服务，才是真正“活着”的服务。

五、日志是系统的“外部神经系统”

很多服务日志存在两个极端：

• 全是 fmt.Println
• 全是 debug，信息过载

推荐的最小日志原则

至少区分三类日志：

1. 启动日志：配置、端口、模式
2. 请求日志：入口、耗时、结果
3. 错误日志：失败原因 + 上下文

并且：

• 日志必须结构化
• 必须能按请求维度串起来

否则日志只是一堆噪音。

六、不要等出问题才加监控

生产事故之后，常听到一句话：

“要是当时有监控就好了。”

但真正有效的监控，必须在系统设计阶段就考虑。

至少需要关注：

• QPS / 延迟
• 错误率
• goroutine 数量
• 内存使用趋势

不是为了“好看”，而是为了提前发现异常趋势。

七、写在最后

一个 Go 服务是否“可靠”，往往不是由某个高级技巧决定的，而是：

• 生命周期是否清晰
• 并发是否可控
• 错误是否透明
• 行为是否可观测

这些东西看起来“基础”，但恰恰是：

能把系统从“能用”，推向“能长期用”的关键。