Go服务生产环境的生存规则，你知道几条？

Go 让你很容易就能写出一段“能编译、能通过冒烟测试、一遇到真实流量就跪”的代码。这门语言默认给你很少——没有运行时异常可以捕获没有框架护栏没有魔法。这是个特性但这也意味着让一个服务在生产环境活下去的规则得你自己来定语言不会替你定。下面这些规则是我在写账本系统、webhook 网关和基于 Temporal 的工作流时用血泪换来的教训。它们核心就一件事不能丢数据。1. 每个 goroutine 都得有“主人”和有“退路”一个 Go 服务在生产环境里最常见的死法不是 panic是goroutine 泄漏。有人 spawn 了一个 goroutine 去做“即发即弃”的事情它监听的 context 被取消了但没人告诉这个 goroutine于是它就永远挂在那里——占着一个连接、一把锁、一个 channel 引用。规则很简单在你写go func()之前先想好“这玩意儿怎么停下来”func(s*Service)startWorker(ctx context.Context){for{select{case-ctx.Done():log.Println(worker shutting down)returncasejob:-s.jobCh:s.process(job)}}}没有ctx.Done()就没有退出计划。如果实在没法用 context比如一个后台 worker 在监听一个比任何单个请求都长寿的 channel那就用sync.WaitGroup加一个专用的 shutdown channel确保收到 SIGTERM 时还能体面地收工。2. Context 是用来传截止时间和取消信号的不是用来“夹带私货”的context.Context经常被滥用——在调用链里偷偷传一些值。这不是它的本意。Context 存在的意义是传播两样东西这活该什么时候停调用方是不是已经放弃了func(r*OrderRepo)GetPending(ctx context.Context,userIDstring)(*Order,error){// 给自己设个 2 秒上限别让下游拖死自己ctx,cancel:context.WithTimeout(ctx,2*time.Second)defercancel()returnr.db.GetOrderByUser(ctx,userID)}每一次数据库调用、每一次 gRPC 调用都应该带一个比调用方给的截止时间更短的超时而不是照搬同一个。不然一个下游调用慢就会一直占着连接直到整个请求在边缘超时你三跳之后才发现问题。3. 报错要报“在哪错的”别只报“错了”fmt.Errorf(%w, err)是最低要求。如果你不加有用的上下文那只是在无意义地包装同一个错误。我给自己定的规则是每一层包装都要加一个原来错误里没有的信息。func(s*Ledger)Post(ctx context.Context,entry LedgerEntry)error{iferr:s.repo.Insert(ctx,entry);err!nil{returnfmt.Errorf(post ledger: account%d amount%d: %w,entry.AccountID,entry.Amount,err)}returnnil}凌晨三点这条日志出现的时候你希望账号和金额直接出现在日志行里而不是还得跨四个服务去关联一个 trace ID。配合errors.Is/errors.As做控制流哨兵错误要定义成类型别用字符串匹配varErrInsufficientFundserrors.New(insufficient funds)iferrors.Is(err,ErrInsufficientFunds){returnnil,ErrInsufficientFunds}4. 事务需要包装器别指望“大家都会记得”“在 defer 里记得调tx.Rollback()”这不是策略这是许愿。每个碰 Postgres 的服务都应该有唯一一个地方管理事务生命周期所有写操作都走那里。func(s*Store)WithTx(ctx context.Context,fnfunc(*Queries)error)error{tx,err:s.pool.Begin(ctx)iferr!nil{returnfmt.Errorf(begin tx: %w,err)}defertx.Rollback(ctx)q:s.queries.WithTx(tx)iferr:fn(q);err!nil{returnerr}returntx.Commit(ctx)}Commit之后再调Rollback是安全的pgx 会处理好。这个模式也给了你一个地方以后加“序列化失败重试”的逻辑而不是等发现需要的时候再到处加。5. 并发写需要行锁别指望“代码里小心点”如果两个 goroutine——或者你服务的两个副本——可能同时更新同一行“我们小心点”不是计划。队列类任务用FOR UPDATE SKIP LOCKED正确性比吞吐量重要的场景用普通的FOR UPDATE。-- name: LockPendingPayout :oneSELECT*FROMpayoutsWHEREstatuspendingORDERBYcreated_atFORUPDATESKIP LOCKEDLIMIT1;这一行 SQL 做的事情比你在应用层加多少 mutex 都多——因为它让 Postgres那个已经知道所有事务状态的家伙来决定什么可以跳过。6. 背压是特性不是“以后再说”的 bug一个服务接受的工作比它能处理的多不会体面地失败——它会因为 OOM 而死或者默默堆积延迟直到健康检查超时。给队列和工作池加上明确的边界。typePoolstruct{semchanstruct{}}funcNewPool(limitint)*Pool{returnPool{sem:make(chanstruct{},limit)}}func(p*Pool)Submit(ctx context.Context,fnfunc())error{select{casep.sem-struct{}{}:gofunc(){deferfunc(){-p.sem}()fn()}()returnnilcase-ctx.Done():returnctx.Err()}}流量高峰下无限制地 spawn goroutine是流量高峰演变成 OOM 的捷径。有限制的池子会把“我们没容量了”变成一种清晰可见、可恢复的状态而不是直接崩掉。7. 但凡碰钱或状态幂等就是必须的如果一个请求可能被重试——被客户端、被负载均衡器、被 Temporal 回放工作流——你的处理器就必须安全地跑两遍。这意味着 API 层要有幂等键数据库层要有唯一约束而不是“希望客户端别双击”。func(s*Payment)Charge(ctx context.Context,req*ChargeReq)error{returns.db.WithTx(ctx,func(q*Queries)error{_,err:q.InsertIdempotency(ctx,req.Key)ifisUniqueViolation(err){returnErrAlreadyProcessed}iferr!nil{returnerr}returnq.CreateCharge(ctx,req)})}真正干活的是idempotency_key上的唯一约束——Go 代码只需要检查冲突把它当成一个已知的、预期内的结果而不是错误。8. 结构化日志别用 printf 调试生产环境里log.Println是个累赘——当你要跨一堆实例去 grep 的时候。用结构化日志带上request_id、account_id、service这些一致的字段你的日志才能变成可查询的数据。logger.Error(failed to post ledger entry,slog.String(request_id,reqID),slog.Int64(account_id,entry.AccountID),slog.String(error,err.Error()),)“十秒找到”和“花四十分钟从非结构化文本里拼时间线”的区别全看你从第一天起有没有做这件事。9. 优雅退出是服务的一部分不是“有空再弄”如果你的服务在退出前不排空正在处理的请求那每一次部署都是一次小型中断。ECS、Kubernetes 和负载均衡器都会在发 SIGKILL 之前先发 SIGTERM——利用好这个窗口。funcrun(ctx context.Context,srv*http.Server)error{errCh:make(chanerror,1)gofunc(){errCh-srv.ListenAndServe()}()select{caseerr:-errCh:returnerrcase-ctx.Done():shutdownCtx,cancel:context.WithTimeout(context.Background(),10*time.Second)defercancel()returnsrv.Shutdown(shutdownCtx)}}十秒通常够让正在飞的请求处理完了。回过头看上面这些规则没有一个稀奇古怪的。它们的共同点是把“事故发生时再想”的决策变成了“发生前就定好”的规则。生产环境不会惩罚“简单”的服务——它惩罚的是“决策没做”的服务。上面每一条本质上都是同一个规则的不同说法把失败模式提前、主动地定好别等生产环境替你定。