金融级系统稳定性取决于panic捕获、error显式处理、goroutine生命周期管控和资源泄漏防范四件事：子goroutine需独立recover，error必须作为控制流分支决策，所有外部调用须带超时context，高频对象要复用并显式释放资源。
panic 不能靠全局 recover 拦住
你在 main 函数或 HTTP handler 里加了 defer recover()，但子 goroutine 一 panic 就静默退出，日志没记录、监控没告警、资金流水直接断在半路。
- HTTP 中间件的
recover只对当前请求 goroutine 有效，对go func() {}()启动的异步任务完全无效 - 后台任务（如对账、清算、Redis 缓存刷新）必须各自包一层
defer func() { if r := recover(); r != nil { log.Panic(r) } }() -
gpool.Get和gpool.Put返回的error不检查，就等于把连接复用失败、对象初始化崩溃、池已关闭等状态全扔给上层猜
error 不是装饰，是控制流的显式分支
金融逻辑里没有“临时网络抖动”，只有“本次支付是否成功”。把 err != nil 当 if 分支跳过，而不是决定降级、重试或记流水，等于把一致性校验交给运气。
-
MustGet/MustPut是调试开关，不是生产防护——源码就是if err != nil { panic(err) }，线上用等于主动把可恢复错误（如 Redis timeout）转成服务中断 - DB 事务中，
tx.Commit()失败必须判断：是网络超时（可重试），还是唯一键冲突（需业务降级），还是死锁（需指数退避） - gRPC 调用返回
status.Code() == codes.Unavailable，不能直接返回 503，得结合熔断器状态决定走本地缓存还是返回预设兜底值
goroutine 泄漏比 CPU 高更致命
一个没加 context 或没设超时的 goroutine，可能卡在 http.Do 或 redis.Client.Get 上数小时，积压数千个，最终拖垮整个节点内存和调度器。
- 所有外部调用必须带
context.WithTimeout或context.WithDeadline，超时后主动 cancel，避免 goroutine 悬停 - 使用
sync.WaitGroup等待子 goroutine 时，务必在 goroutine 内部 defer wg.Done()，且确保 wg.Add 在 go 语句前执行 - 定时任务（如每分钟跑一次对账）用
time.Ticker时，记得在 shutdown 时ticker.Stop()，否则 runtime 会持续持有 goroutine 引用
资源泄漏常藏在“正常路径”里
你测试时一切 OK，上线后三天内存涨到 95%，GC 频次飙升，最后发现是某个风控规则引擎每次 new 了一个 regexp.Regexp 却没复用，而 Go 的正则编译开销远超预期。
立即学习“go语言免费学习笔记（深入）”；
- 高频路径（如订单创建、余额查询）中，避免重复
json.Unmarshal或time.Parse；预编译正则、复用sync.Pool对象、缓存解析结果 - 文件句柄、DB 连接、Redis 连接池都必须显式 Close 或归还，尤其注意 defer 放在循环内会导致延迟释放
- 使用
pprof定期抓取/debug/pprof/goroutine?debug=2和/debug/pprof/heap，重点看 top alloc_objects 和 blocking profile
