在 go 中，若一个变量在启动 goroutine 前由同一线程完成初始化（且后续仅由该 goroutine 访问），则无需显式同步；该模式完全符合 go 内存模型，是安全、推荐的并发编程实践。
在 go 中，若一个变量在启动 goroutine 前由同一线程完成初始化（且后续仅由该 goroutine 访问），则无需显式同步；该模式完全符合 go 内存模型，是安全、推荐的并发编程实践。
在 Go 并发开发中，一个常见但关键的问题是：如何安全地将数据“传递”给新启动的 goroutine？ 很多开发者因担心数据竞争而过度使用 sync.Mutex 或 sync.Once，反而增加了复杂度和性能开销。实际上，Go 的内存模型已为此类场景提供了明确保证——关键在于理解 goroutine 创建本身就是一个同步原语。
✅ 安全前提：单线程初始化 + 单 goroutine 专属访问
回顾你的代码：
func (r *Runner) init() {
r.something = make(map[string]int
r.something["a"] = 1
go r.goroutine() // ← 同一线程中，写操作完成后才执行此语句
}根据 Go 内存模型文档，go 语句具有严格的 happens-before 关系：
The go statement that starts a new goroutine happens before the goroutine’s execution begins.
这意味着：
- 主协程中对 r.something 的所有写操作（包括 make 和赋值 "a": 1）必然在 r.goroutine() 开始执行之前完成；
- 这些写操作对新 goroutine 是立即可见的，无需 sync/atomic 或互斥锁；
- 只要没有其他 goroutine 同时读或写 r.something，就不存在数据竞争（data race）。
这与官方文档中的经典示例本质相同：
var a string
func f() { print(a) }
func hello() {
a = "hello, world" // ← 主协程写入
go f() // ← 启动新 goroutine
}
// 调用 hello() 必然打印 "hello, world"（即使 hello 已返回）✅ 后续复用：goroutine 结束后主线程安全读取
你提出的第二个问题同样重要：r.goroutine() 执行完毕后，能否在主线程（或其他 goroutine）中安全读取 r.something？
答案是：只要确保读取发生在 goroutine 结束之后，且无并发读写，就是安全的。
但注意：Go 不保证 goroutine 结束的可见性自动同步到其他 goroutine。你需要显式同步来确认结束时机，例如：
func (r *Runner) init() {
r.something = make(map[string]int
r.something["a"] = 1
done := make(chan struct{})
go func() {
r.goroutine()
close(done) // 通知完成
}()
<-done // 等待 goroutine 结束
// 此时可安全读取 r.something（无其他 goroutine 并发修改）
fmt.Println(r.something) // 安全！
}⚠️ 重要提醒：
- 若 r.something 在 r.goroutine() 中被修改，且你希望主线程读取其最终状态，必须通过 channel、sync.WaitGroup 或 sync.Once 等机制等待其完成；
- go 语句只保证启动前的写可见性，不保证执行结束后的读可见性；
- 使用 go vet -race 检测数据竞争仍是最佳实践——它会帮你捕获意外的并发访问。
总结
| 场景 | 是否需要同步 | 说明 |
|---|---|---|
| 启动 goroutine 前初始化变量，且仅该 goroutine 访问 | ❌ 不需要 | go 语句提供 happens-before 保证 |
| goroutine 结束后，由其他 goroutine 读取该变量 | ✅ 需要同步结束信号 | 如 chan struct{}、WaitGroup，否则存在竞态风险 |
| 多个 goroutine 共享读写同一变量 | ✅ 必须同步 | 使用 Mutex、RWMutex 或原子操作 |
这种“初始化即传递”的模式，是 Go 鼓励的轻量级并发设计哲学——它简洁、高效、且内存安全。掌握 go 语句的同步语义，是你写出健壮 Go 并发代码的重要基石。
