本文详解 Go 并发编程中因忽略 nil 返回值导致的 panic（invalid memory address or nil pointer dereference），通过正确校验 GetUser 等 API 调用结果、调整控制流顺序，避免对 nil 结构体字段的非法访问。
本文详解 go 并发编程中因忽略 `nil` 返回值导致的 panic（invalid memory address or nil pointer dereference），通过正确校验 `getuser` 等 api 调用结果、调整控制流顺序，避免对 nil 结构体字段的非法访问。
在 Go 中，panic: runtime error: invalid memory address or nil pointer dereference 是最常见也最容易被忽视的运行时错误之一——它并非语法错误，而是在运行时试图解引用一个 nil 指针（例如访问 member.Username 时 member 为 nil）。该问题在单次调用中可能“侥幸”不触发，但在高并发场景下（如大量 goroutine 同时调用 GetUser），API 返回错误或空响应的概率显著上升，若未做防御性检查，就会立即 panic。
根本原因在于原代码中访问字段与错误判断逻辑错位：
member, err := s.GetUser(i)
output <- fmt.Sprint(member.Username) // ⚠️ 危险！此处 member 可能为 nil
if err != nil && member != nil {
continue
}这段代码在 err != nil 时仍尝试访问 member.Username，而根据 gosoundcloud 的 GetUser 实现，其返回签名是 (User, error)，且文档明确说明：当请求失败（如 HTTP 404、403、500 或网络超时）时，member 为 nil，err 非空。因此，必须先判空再使用。
✅ 正确做法如下：
func concurrent(n uint64) {
defer wg.Done() // 注意：defer 应放在函数开头，确保始终执行
for i := n; i < n+11; i++ {
member, err := s.GetUser(i)
if err != nil {
// 建议记录日志，便于定位失败原因（如 token 失效、限流、网络抖动）
log.Printf("failed to get user %d: %v", i, err)
continue // 跳过本次迭代，避免后续操作
}
if member == nil {
// 安全兜底：某些实现可能返回 nil 但无 error（虽不典型，但增强鲁棒性）
log.Printf("user %d returned nil without error", i)
continue
}
// ✅ 此时 member 必然非 nil，可安全访问字段
output <- fmt.Sprint(member.Username)
}
}? 关键注意事项：
- defer wg.Done() 必须置于函数起始处：原代码将其放在循环末尾，会导致 wg.Done() 在循环结束后才执行一次（甚至因 panic 无法执行），造成 WaitGroup 永远无法完成，主 goroutine 阻塞。
- 错误处理不可省略：GetUser 是阻塞式 HTTP 请求，失败是常态（尤其在并发压力下），应显式记录并决策是否重试、降级或跳过。
- 避免“先用后检”陷阱：Go 不强制要求检查 nil，但工程实践中所有外部 API 返回的指针/结构体引用，都应默认视为可能为 nil，遵循 “check before use” 原则。
- 补充健壮性建议：可在 s.GetUser 调用前添加上下文（context.WithTimeout）防止无限等待；对 output channel 做容量限制或 select + default 防止 goroutine 泄漏。
总结：Go 的 nil 安全不是语言特性，而是开发者责任。在并发场景中，API 失败率升高，nil 检查从“可选”变为“必需”。将 nil 判断前置、分离错误处理与业务逻辑、规范 defer 位置，三者结合即可彻底规避此类 panic。
