本文详解 go 并发编程中因 for 循环变量复用导致的指针错误：当在循环中取地址（&category）并发送给 goroutine 时，所有 goroutine 实际共享同一内存地址，造成数据覆盖和逻辑错乱。
本文详解 go 并发编程中因 for 循环变量复用导致的指针错误：当在循环中取地址（&category）并发送给 goroutine 时，所有 goroutine 实际共享同一内存地址，造成数据覆盖和逻辑错乱。
在 Go 的并发实践中，一个经典且极易被忽视的陷阱是：在 for range 循环中对迭代变量取地址并传递给 goroutine（或存入 channel）。您提供的网络爬虫代码正是这一问题的典型体现——parent 字段被意外覆盖、子分类 URL 构造错误、行为随 worker 数量增加而恶化，其根本原因并非并发竞争（如未加锁），而是循环变量的生命周期与地址复用机制。
? 问题本质：category 是循环中复用的栈变量
看这段关键代码：
for _, category := range *categories {
numRequests += 1
downloadChannel <- &category // ❌ 危险！
}表面上，每次迭代都生成一个 category 值；但 Go 规范规定：range 中的迭代变量 category 在整个循环中只分配一次内存地址，每次迭代只是将新值拷贝到该固定位置。因此 &category 始终指向同一个地址。当多个 goroutine 从 channel 中读取 *Category 并后续访问 parent 字段时，它们实际看到的是最后一次迭代写入该地址的 category 值——这直接导致父级关系错乱（例如 travel-tourism/ 被错误覆盖为 political-ideological-organizations/ 的 parent）。
✅ 正确做法：确保每个 goroutine 拥有独立、稳定的内存地址。
✅ 安全修复方案：显式索引 + 取数组元素地址
您已在更新中给出正确解法，我们进一步明确其原理与推荐写法：
// ✅ 推荐：使用索引访问切片元素，取其真实地址
categoriesSlice := *categories // 解引用，获得 []Category 切片
for i := range categoriesSlice {
category := categoriesSlice[i] // 显式拷贝一份（值语义安全）
downloadChannel <- &categoriesSlice[i] // ✅ 取切片中第 i 个元素的真实地址
}⚠️ 注意：&categoriesSlice[i] 是安全的，因为切片底层数组的每个元素都有唯一地址；而 &category（局部变量）是危险的。
? 其他加固建议（提升健壮性）
避免不必要的指针传递
Category结构体较小（仅含字符串、整数、指针），按值传递更清晰、更安全。若需修改原对象，再考虑指针；否则优先用Category而非*Category。channel 关闭逻辑修正
原代码中if len(allCategories) > numRequests { close(...) }存在竞态风险且逻辑反直觉（应基于待处理任务数判断）。建议改用sync.WaitGroup或原子计数器协调 worker 生命周期。调试技巧：用
%p打印地址 +fmt.Printf("addr=%p", &v)辅助定位
如您已做的fmt.Printf("... (addr %p)", &target)，这是诊断此类问题最直接有效的方式——观察日志中地址是否重复，比逐行分析逻辑更快。
? 总结
| 场景 | 是否安全 | 原因 |
|---|---|---|
for _, v := range s { go f(&v) } |
❌ 不安全 |
v 地址复用，所有 goroutine 看到同一内存 |
for i := range s { go f(&s[i]) } |
✅ 安全 |
s[i] 是底层数组独立元素，地址唯一 |
for _, v := range s { vCopy := v; go f(&vCopy) } |
✅ 安全（但冗余） | 每次创建新局部变量，地址独立 |
Go 的简洁语法背后有严格的内存模型约束。理解“循环变量复用”这一机制，是写出可预测、可维护并发代码的关键一步。下次遇到类似诡异的数据覆盖现象，请第一时间检查 & 和 range 的组合——它大概率就是罪魁祸首。
