Go并发常见问题包括goroutine泄漏、channel死锁、数据竞争和channel关闭混乱，需通过超时控制、缓冲channel、sync/atomic保护及明确关闭规则来规避。
Go 的并发模型简洁有力，但 Goroutine 和 Channel 的误用极易引发隐蔽、难复现的 bug。多数问题不报 panic，却导致死锁、数据竞争、内存泄漏或逻辑错误——它们往往在高负载或特定调度时机才暴露。
goroutine 泄漏：忘记回收或阻塞等待
启动 goroutine 后若未确保其能正常退出，它将持续占用栈内存和调度资源，长期运行服务中会缓慢耗尽系统资源。
-
常见场景：向无缓冲 channel 发送数据，但没有 goroutine 接收；或从 channel 读取时，发送方已关闭但接收方仍在循环等待（如
for range ch误用于单次通信） -
调试方法：用
runtime.NumGoroutine()定期采样观察增长趋势；pprof 查看/debug/pprof/goroutine?debug=2获取完整堆栈快照 -
安全写法：带超时的 select、使用
context.WithTimeout控制生命周期、避免在循环内无条件启动匿名 goroutine（尤其配合 channel 操作时）
channel 死锁：发送/接收双方无法同步
Go 运行时会在所有 goroutine 都阻塞且无可能被唤醒时触发 fatal error: all goroutines are asleep - deadlock。这是最典型的 channel 错误信号。
- 典型错误：主 goroutine 向无缓冲 channel 发送后等待响应，而处理 goroutine 却先尝试接收再发送——顺序错位导致双向阻塞；或多个 goroutine 循环依赖 channel 通信（A 等 B，B 等 C，C 等 A）
- 规避策略：优先使用带缓冲 channel（容量 = 1 常可解耦）；用 select + default 避免无限等待；对关键 channel 操作加 context 超时控制
- 注意点：关闭已关闭的 channel 不 panic，但向已关闭 channel 发送会 panic；从已关闭 channel 接收会立即返回零值——这常被误认为“成功通信”
数据竞争：共享变量未受保护
Go 的内存模型允许 goroutine 并发读写同一变量，但未同步时行为未定义。Race Detector 可捕获大部分情况，但无法覆盖所有路径（如仅在特定时间窗口发生的竞争）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
高频雷区：在 goroutine 中修改闭包捕获的局部变量（如 for 循环中启动 goroutine 用
i，却未传参或拷贝）；结构体字段被多个 goroutine 直接读写，未用 mutex 或 atomic -
推荐做法：优先通过 channel 传递数据而非共享内存；必须共享时，用
sync.Mutex或sync.RWMutex显式保护；计数类操作优先用atomic包 -
验证手段：编译时加
-race标志运行测试；结合go vet检查潜在闭包变量捕获问题
channel 关闭混乱：谁关？何时关？关几次？
channel 关闭是单向操作，且应由“数据发送方”负责。错误的关闭时机或主体会导致接收方收到意外零值、panic 或逻辑中断。
- 明确规则：只应由**唯一确定不再发送数据的 goroutine** 关闭 channel；多个 goroutine 尝试关闭会 panic；接收方不应关闭 channel
-
实用模式：用
sync.WaitGroup等待所有发送者完成后再关闭；或用额外的 done channel + select 组合实现优雅退出 -
检查技巧：接收时用
v, ok := <-ch判断是否已关闭；避免在 for-range 循环中混入非 channel 退出逻辑（如 break 条件与关闭不同步）
并发 bug 的本质是时序敏感，不是代码写错，而是对执行顺序做了错误假设。多用工具验证，少靠直觉推理；设计阶段就明确 channel 所有权、生命周期和错误传播路径，比事后调试更有效。
