Go并发核心是channel显式通信、goroutine可控退出、慎用sync优先解耦、错误必须显式处理；需避免共享内存竞态，用context控制生命周期，以channel替代锁协调，全面检查channel操作与外部调用错误。
Go 语言的并发模型以简洁、安全、高效著称，但写对并发代码远比写“能跑”的并发代码难得多。真正可靠的 Go 并发程序，核心不在于多用 goroutine，而在于合理控制并发边界、明确通信意图、及时处理失败与生命周期。以下是经过工程验证的关键实践。
用 channel 显式通信，而非共享内存
Go 推崇 “不要通过共享内存来通信，而要通过通信来共享内存”。这意味着应避免多个 goroutine 直接读写同一变量（如全局 map、切片或结构体字段），尤其未加锁时极易引发竞态。正确做法是：让一个 goroutine 拥有数据所有权，其他 goroutine 通过 channel 发送请求或接收结果。
- 需要读写状态？封装为一个“状态管理 goroutine”，暴露 channel 接口（如 reqCh 和 respCh）
- 批量任务分发？用无缓冲或带缓冲 channel 作为任务队列，worker 从 channel 中取任务，不直接访问外部 slice
- 避免在 closure 中捕获可变变量（如 for 循环中的 i 或 v），应显式传参：go func(val int) { ... }(v)
始终为 goroutine 设置退出机制
失控的 goroutine 是内存泄漏和 CPU 空转的主因。每个启动的 goroutine 都应有明确的终止条件，不能依赖 GC 回收——goroutine 不会因所在线程结束而自动退出。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 使用 context.Context 传递取消信号，尤其在 I/O、定时、HTTP 客户端调用中必须传入 ctx
- worker 循环中监听 ctx.Done()，收到信号后清理资源并 return
- 避免无限 for {}，除非配合 select + default 或 time.Ticker 控制频率
- 启动 goroutine 的函数应提供同步等待或关闭方法（如 Stop()），便于测试与服务优雅退出
谨慎使用 sync 包，优先用 channel 解耦
sync.Mutex、sync.RWMutex、sync.Once 等工具虽必要，但易引入死锁、粒度失当或掩盖设计缺陷。它们更适合保护极小范围、高频、纯内存操作（如计数器、flag 切换），而非业务逻辑协调。
立即学习“go语言免费学习笔记（深入）”；
- 读多写少且结构稳定？考虑 sync.Map，但注意它不适用于需要遍历或强一致性场景
- 初始化一次？用 sync.Once，比手写 double-check 更安全
- 需等待多个 goroutine 完成？优先用 sync.WaitGroup，但记得 Add() 必须在 goroutine 启动前调用
- 若发现频繁加锁/解锁同一资源，说明该资源可能本不该被多 goroutine 共享——回归 channel 模型重新建模
并发错误必须显式处理，不可静默吞掉
goroutine 内 panic 会终止自身，但不会传播到父 goroutine；channel 发送/接收失败、超时、关闭后误读等，若不检查返回值或错误，将导致逻辑错乱或阻塞。
- 所有 channel 操作都应检查是否 ok：val, ok := <-ch；关闭 channel 前确保无人再发送
- select 中的 default 分支不是“兜底”，而是实现非阻塞尝试；若需超时，必配 time.After 或 ctx.Done()
- HTTP 请求、数据库查询等外部调用，必须检查 error；并发场景下建议用 errgroup.Group 统一收集错误
- 测试并发逻辑时，开启 -race 检测竞态，CI 中强制运行
