Go函数并发安全取决于是否读写共享可变状态；纯函数天然安全，而访问包级变量、未锁map、rand.Intn等则不安全，闭包捕获循环变量和标准库fmt/rand调用也易引发竞态。
Go 函数本身是否并发安全，不取决于你开了多少个 goroutine 去调，而只取决于它内部有没有读写共享可变状态。纯计算函数天然安全，但凡碰了包级变量、全局 map、未加锁的指针接收者、rand.Intn() 或 fmt.Print，就大概率不安全。
纯函数（无状态、无副作用）天然并发安全
像 add(a, b int) int、strings.ToUpper(s string) 这类只操作参数和局部变量的函数，每次调用都在独立栈帧里完成，返回值不逃逸，也不影响任何外部状态。Go 运行时自动隔离每个 goroutine 的栈空间，所以这种函数根本不需要加锁，也完全不会因并发出问题。
- ✅ 安全前提是：不访问任何包级变量（如
var counter int） - ✅ 不修改传入的指针或切片底层数组（除非你明确控制同步）
- ✅ 不调用非并发安全的外部函数（比如未加锁的
map写入、rand.Seed()）
闭包捕获循环变量是高频竞态源头
闭包捕获的是变量地址，不是值拷贝。常见错误写法：for i := range xs { go func() { use(i) }() } —— 所有 goroutine 共享同一个 i 变量，最终可能全输出 5（如果循环到 5 结束）。
- ⚠️ 正确做法：显式传参，
go func(i int) { use(i) }(i) - ⚠️ 更稳妥：用
range配合结构体字段赋值，避免裸变量传递 - ⚠️ 注意：闭包不能替代同步原语，哪怕把
*sync.Mutex封进闭包，也必须显式调用Lock()和Unlock()
带共享状态的函数必须显式同步
只要函数内部修改了包级 map、结构体字段、计数器或日志文件句柄，就必须自己加锁或换用线程安全类型。别指望 sync.Once 能兜底——它只保“初始化一次”，不保初始化之后的读写安全。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- ❌ 错误示例：
visits[r.RemoteAddr]++直接改全局map，触发fatal error: concurrent map writes - ✅ 正确做法：用
sync.RWMutex包裹读写，或直接换成sync.Map - ✅ 日志初始化函数（如
SetupLogger()）本身无状态，是并发安全的；但若内部调用os.Create()创建日志文件，就存在 TOCTTOU 竞态，需加锁或改用原子文件操作
标准库常见陷阱：fmt 和 math/rand
fmt.Print 和 math/rand 包级函数是典型“表面无害、并发即崩”的例子。它们底层依赖非原子系统调用或全局互斥锁，高并发下要么输出交错，要么严重性能退化。
- ⚠️
fmt.Println("msg")在多goroutine下必然出现字符交错，这不是偶发，是确定性行为 - ✅ 替代方案：用
log包（内部已加锁），或用sync.Mutex包裹fmt调用，或走chan统一收集再输出 - ⚠️
rand.Intn(100)背后是单个带sync.Mutex的全局实例，100 个goroutine会排队争锁，pprof显示runtime.futex占比飙升 - ✅ 正确做法：每个
goroutine自建rand.New()实例，种子用time.Now().UnixNano() ^ int64(unsafe.Pointer(&x))扰动，避免重复
最常被忽略的点不是“要不要加锁”，而是“谁 owns 那个被函数读写的内存地址”——生命周期错配、变量逃逸到堆上、闭包捕获栈变量却在 goroutine 中长期持有，这些都会让看似正确的同步逻辑瞬间失效。
