Go微服务中panic不得跨goroutine传播，HTTP handler和gRPC方法须显式defer recover；error需携带上下文与状态码；超时需三层协同容错；熔断应区分超时与真实失败；错误处理逻辑自身不可panic。
Go 微服务中 panic 不该跨 goroutine 传播
在 HTTP handler 或 gRPC 方法里直接 panic，会导致整个服务崩溃——这不是错误处理，是拒绝服务。Go 的 recover 只对同 goroutine 有效，而 http.ServeMux 和 grpc.Server 都会在新 goroutine 中调用你的业务逻辑，所以 defer recover() 必须显式加在入口函数里。
常见错误现象：某次数据库超时触发 panic("timeout")，结果整个服务进程退出，K8s 持续重启 Pod。
- 所有 HTTP handler 包裹一层
func(w http.ResponseWriter, r *http.Request) { defer errorHandler(w); handler(w, r) } - gRPC interceptor 中用
defer func() { if r := recover(); r != nil { ... } }()捕获 - 不要依赖全局
http.DefaultServeMux的隐式 recover；它不生效
error 类型必须携带上下文和可分类状态码
返回 errors.New("db failed") 或 fmt.Errorf("failed: %w", err) 在微服务里等于放弃可观测性。下游无法区分是重试able 的临时错误（如网络抖动），还是需告警的永久错误（如 schema mismatch）。
使用 status.Code()（来自 google.golang.org/grpc/codes）或自定义 error wrapper 是底线。
立即学习“go语言免费学习笔记（深入）”；
GitHub 项目更新追踪工具 - 自动检查多个 GitHub 项目的 Releases 和 CHANGELOG，生成更新摘要与影响分析报告。支持自动化定时任务。 如何使用 最简单的方式：直接用自然语言告诉我 你可以说 我会做 「检查 GitHub 更新」 检查最新版本 「添加 vscode」 追踪新项目 「停止追踪 xxx」 移除项目 「暂停更新检查」 暂停自动化 「给我看 openclaw 报告」 展示报告 触发词：「追踪项目更新」「检查 GitHub 更新」「项目更新报告」「设置更新提醒」
- HTTP 服务推荐用
github.com/segmentio/errors或轻量封装：type AppError struct { Code int; Message string; Cause error } - gRPC 服务必须用
status.Error(codes.Internal, "msg")，否则客户端status.FromError()解析失败 - 避免在 error message 里拼接敏感字段（如用户 ID、token），日志里单独结构化打点
超时与重试不能只靠 context.WithTimeout
context.WithTimeout 只是取消信号，不保证下游立刻停止。若你调用一个没做 context 透传的第三方 SDK（比如老版本 redis-go 或 mongo-go-driver），超时后 goroutine 仍在跑，连接堆积，最终耗尽资源。
真正的容错需要三层配合：上游 cancel、中间件拦截、下游主动响应。
- 所有外部调用必须接收
ctx context.Context并透传到底层 client 方法（如client.Do(ctx, req)） - HTTP 客户端设
http.Client.Timeout作为兜底（防止 ctx 被忽略） - 重试逻辑放在 client 层而非 handler 层，用
github.com/hashicorp/go-retryablehttp或自研带 jitter 的指数退避
熔断器要区分“调用失败”和“调用未完成”
很多 Go 熔断库（如 sony/gobreaker）默认把超时也当 failure 计数，但超时 ≠ 错误——它可能是下游慢，也可能是网络延迟。混在一起会过早熔断健康节点。
正确做法是：只对明确返回 error（且非 context.Canceled / context.DeadlineExceeded）的调用计为 failure；超时、取消应走 separate counter 或降级路径。
- 用
gobreaker.Settings{ReadyToTrip: func(counts gobreaker.Counts) bool { return counts.TotalFailures > 5 && counts.ConsecutiveFailures > 3 }}，并自行过滤超时 - 更稳妥的是用
resilience-go，它原生支持 failure predicate 函数 - 熔断打开后，别直接返回 503，先 fallback 到缓存或默认值（如果业务允许）
最易被忽略的一点：错误处理代码本身不能有 panic。比如在 errorHandler 里尝试序列化一个 nil 结构体，或往已关闭的 channel 发送日志——这会让错误处理变成新的单点故障。
