这是闭包按引用捕获变量的确定性行为：for循环中直接用i启动goroutine时，所有goroutine共享同一变量i的地址，最终都读取到循环结束后的终值（如i=100）。
Go 中匿名函数在 goroutine 启动时若直接引用循环变量，会导致所有 goroutine 共享同一变量地址，最终全部读取到循环结束后的终值（比如 i 变成 100 或 len(slice)），这不是 bug，而是闭包按引用捕获变量的确定性行为。
for 循环中直接用 i 启动 goroutine 为什么全输出终值
因为 Go 的 for i := 0; i 复用同一个变量 <code>i 的内存位置，每次迭代只是更新其值；匿名函数捕获的是这个地址，而非某次迭代的快照。goroutine 调度延迟 + 循环执行极快 → 等它们真正执行时，i 已稳定为终值。
- 常见错误现象：
fmt.Println(i)输出全是100（哪怕循环是0..99） - 使用场景：启动批量 HTTP 请求、定时任务注册、消息分发等需并发处理循环项的逻辑
- go vet 会报 warning：
loop variable i captured by func literal
range 循环里的 v 也被所有 goroutine 共享
和传统 for 一样，for _, v := range slice 中的 v 是单个变量，每次迭代覆盖其值。所有 goroutine 捕获的都是最后一个 v 的地址。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 验证方式：打印
&v，会发现所有 goroutine 输出相同指针 - 参数差异：用
range时不能靠“语义上更直观”来规避问题，必须显式副本 - 性能影响：
v := v是值拷贝，对小结构体/基础类型无负担；大结构体可改用索引访问slice[i]
两种安全写法的区别与选择
核心目标是让每个 goroutine 持有独立、稳定的值。两种惯用法效果等价，但语义和可读性略有不同：
-
i := i：利用变量遮蔽（shadowing），简洁，适合单变量；注意它不是赋值冗余，而是新声明 -
func(val int) { ... }(i)：通过参数传值，闭包内val天然隔离，语义更明确，适合多变量或需命名时 - 容易踩的坑：
func(j Job) { DistributeJob(j) }(job)是立即执行函数（IIFE），返回值不是func()类型，无法传给c.AddFunc等期望无参函数的接口
Go 1.22+ 的 GOEXPERIMENT=loopvar 不要依赖
虽然 Go 1.22 实验性支持在 range 循环中自动为每次迭代创建独立变量（需启用 GOEXPERIMENT=loopvar），但它仍未成为默认行为，且仅限 range，不覆盖传统 for 循环。
- 兼容性风险：跨版本构建或 CI 环境未启用该 flag 时，代码退化回老行为
- 可读性隐患：新人无法一眼看出变量是否被安全捕获
- 生产环境建议：坚持手动
v := v或参数传值，这是最可控、最易审查的方式
真正容易被忽略的点是：这个问题不只发生在 fmt.Println 这种简单场景里——当变量是结构体指针、channel、或参与后续计算时，共享引用可能导致数据错乱、panic 或静默失败，比单纯打印错值更危险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
