在 go 中，若一个 goroutine 启动前已在主线程中完成对结构体字段的初始化（且该字段后续仅由该 goroutine 访问），则无需显式同步；启动 goroutine 本身即构成内存可见性的同步点。
在 go 中，若一个 goroutine 启动前已在主线程中完成对结构体字段的初始化（且该字段后续仅由该 goroutine 访问），则无需显式同步；启动 goroutine 本身即构成内存可见性的同步点。
Go 的并发模型建立在明确的内存同步语义之上。关键在于：goroutine 的创建（go f()）是一个同步事件——它隐式保证了创建 goroutine 的 goroutine 中所有先前的写操作，对新启动的 goroutine 是可见且按序的。
这并非依赖运气或编译器优化，而是 Go 内存模型（The Go Memory Model）的明确规定：
"A go statement that starts a new goroutine happens before the goroutine's execution begins."
这句话意味着：在 go r.goroutine() 执行完成的那一刻，其前序代码（包括 r.something = make(map[string]int 和 r.something["a"] = 1）的所有副作用，必然已对 r.goroutine() 的执行环境可见。因此，只要满足以下两个条件，访问 r.something 就是完全安全的：
✅ 条件一：r.something 在 go r.goroutine() 之前完成初始化；
✅ 条件二：r.something 在 r.goroutine() 运行期间不被任何其他 goroutine 读写（即无并发访问）。
下面是一个可验证的示例：
type Runner struct {
something map[string]int
}
func (r *Runner) init() {
r.something = make(map[string]int)
r.something["a"] = 1
r.something["b"] = 2
go r.goroutine()
}
func (r *Runner) goroutine() {
// 安全：此处一定能看到 "a"→1 和 "b"→2
fmt.Printf("In goroutine: %+v\n", r.something) // 输出 map[a:1 b:2]
}⚠️ 注意事项：
- 此安全性不延伸至 goroutine 启动之后的写操作。例如，若你在 go r.goroutine() 之后又修改 r.something，而 r.goroutine() 同时在读，就构成数据竞争，必须加锁或使用 channel 同步。
- 若 r.goroutine() 结束后，你希望在其他 goroutine 中安全读取 r.something，也需确保「读操作发生在 r.goroutine() 结束之后」。此时可借助 sync.WaitGroup 或 <-doneChan 等同步原语建立 happens-before 关系：
func (r *Runner) initWithWait() {
r.something = make(map[string]int
r.something["a"] = 1
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
r.goroutine()
}()
// 等待 goroutine 完成后再读取 —— 此时读操作 happens after 写操作（含 goroutine 内部写）
wg.Wait()
fmt.Println("After goroutine:", r.something) // 安全
}✅ 总结：
Go 不要求为“单写-单读”且写发生在读之前的场景添加额外同步。go 语句天然提供初始化写与 goroutine 首次读之间的内存屏障。理解并善用这一语义，是编写高效、简洁、无竞争 Go 并发代码的基础。
