Goroutine 的启动是异步且非确定性的，其实际执行时间点由 Go 运行时调度器动态决定，不受代码书写顺序保证；正确并发编程必须依赖显式同步原语（如 channel、Mutex、WaitGroup），而非调度器的隐式行为。
go 中 goroutine 的启动是异步且非确定性的，其实际执行时间点由 go 运行时调度器动态决定，不受代码书写顺序保证；正确并发编程必须依赖显式同步原语（如 channel、mutex、waitgroup），而非调度器的隐式行为。
在 Go 中，go 关键字用于启动一个新的 goroutine，但它并不表示“立即执行”或“按顺序执行”，而仅表示“将该函数加入调度队列，等待运行时安排执行”。正如以下典型示例所示：
package main
import (
"fmt"
"time"
)
func main() {
go fmt.Println("Hello") // 启动 goroutine，但不阻塞主协程
fmt.Println("World") // 主协程继续执行
time.Sleep(1 * time.Millisecond) // 为避免主协程过早退出，给子 goroutine 留出执行窗口
}运行结果几乎总是：
World Hello
这容易让人误以为：“goroutine 要等到主协程阻塞（如 Sleep）才开始执行”。但事实并非如此——goroutine 可能在 go 语句后任意时刻被调度，包括在 fmt.Println("World") 执行过程中。Go 运行时会在多个安全点（safepoints）主动让出控制权，例如：
- 函数调用（尤其是涉及系统调用的 I/O 操作，如 fmt.Println 内部的 write syscall）；
- 循环中的某些迭代边界（编译器插入的 morestack 检查）；
- 垃圾回收暂停期间；
- 显式调用 runtime.Gosched()。
因此，fmt.Println("World") 在执行时可能触发底层 write 系统调用，此时当前 goroutine（main）让出 CPU，调度器便有机会唤醒刚启动的 "Hello" goroutine。但这属于实现细节级别的偶然行为，不具备可移植性与可预测性。
✅ 正确做法：使用明确的同步机制来表达执行顺序依赖。例如：
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
fmt.Println("Hello")
}()
fmt.Println("World")
wg.Wait() // 确保 "Hello" 执行完成后再退出
}或者更符合 Go 风格的 channel 方式：
done := make(chan struct{})
go func() {
fmt.Println("Hello")
close(done)
}()
fmt.Println("World")
<-done // 等待 goroutine 完成⚠️ 重要提醒：
- 永远不要依赖 goroutine 的“自然调度顺序”编写逻辑。即使在当前 Go 版本、特定硬件和负载下表现稳定，也可能在升级 Go、更换平台或压力变化后失效；
- Go 内存模型只保证通过 channel 发送/接收、sync 包原语（如 Mutex.Lock/Unlock、atomic 操作）建立的 happens-before 关系；
- time.Sleep 不是同步手段，它只是粗粒度的延时，无法替代 WaitGroup 或 channel 等语义明确的协调机制。
总结：Goroutine 的执行时机由运行时调度器自主决策，开发者应聚焦于通过并发原语声明意图，而非猜测或依赖调度器行为。这是写出健壮、可维护并发程序的根本原则。
