go playground 默认 gomaxprocs=1 导致调度行为受限，而本地环境默认使用多核并行（gomaxprocs=cpu 核心数），因此同一段含无限 goroutine 的代码在两者上表现迥异：playground 超时阻塞，本地却快速退出。
go playground 默认 gomaxprocs=1 导致调度行为受限，而本地环境默认使用多核并行（gomaxprocs=cpu 核心数），因此同一段含无限 goroutine 的代码在两者上表现迥异：playground 超时阻塞，本地却快速退出。
Go 中 goroutine 的生命周期与程序终止逻辑常被误解，尤其当对比 Go Playground 和本地运行结果时。核心差异并非语言规范本身，而是运行时调度策略与资源限制的配置不同。
? 关键机制：GOMAXPROCS 与调度行为
GOMAXPROCS 控制 Go 程序可并行执行的操作系统线程数（即 P 的数量），直接影响 goroutine 调度器能否“同时”推进多个 goroutine：
Go Playground（旧版及默认配置）：GOMAXPROCS = 1
单线程调度意味着：一旦某个 goroutine 进入 CPU 密集型循环（如 for { fmt.Println("Here") }），且不主动让出控制权（如无 I/O、channel 操作或 sleep），调度器无法强制切换——其他 goroutine（包括 main）将被饿死。这就是你看到 Process took too long 的根本原因。本地环境（Go 1.5+）：GOMAXPROCS 默认等于可用逻辑 CPU 核心数（如 4 或 8）
多 P 并行下，即使一个 goroutine 死循环，调度器仍可在其他 OS 线程上继续执行 main goroutine。main 函数返回后，整个程序立即终止——Go 规范明确指出：程序在 main.main 返回时结束，不会等待其他非主 goroutine 完成（见 Spec: Program execution）。
? 验证行为差异的代码示例
以下代码可清晰复现并验证该机制：
package main
import (
"fmt"
"runtime"
"time"
)
func other(done chan bool) {
done
- 在本地运行：稳定输出 "Finished."，且 "Here" 打印次数取决于调度时机（通常 0–2 次），因 main 退出后程序即终结。
- 在 Playground（保持 GOMAXPROCS=1）：若移除 time.Sleep，极易触发超时；加入后则可能完整打印 5 次——因为显式让出使调度器有机会切换。
⚠️ 重要注意事项
- 无同步 = 无保证：Go 内存模型仅定义 happens-before 关系，绝不保证 goroutine 执行顺序或完成状态。依赖“某 goroutine 必然执行完再退出”是典型竞态陷阱。
- Playground 缓存机制：输出常被缓存，修改代码（如加空格）才能触发真实重跑，否则看到的是历史结果。
-
强制同步才是正解：若需确保后台 goroutine 完成，必须使用显式同步原语：
var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() for { /* ... */ } }() // ... 后续 wg.Wait()
✅ 总结
| 场景 | GOMAXPROCS | 行为特征 | 是否超时/退出 |
|---|---|---|---|
| Go Playground（默认） | 1 | 单线程调度，死循环 goroutine 饿死 main | 是（超时） |
| 本地（默认） | >1 | 多线程并行，main 返回即终止程序 | 否（快速退出） |
| 本地（设为 1） | 1 | 行为趋近 Playground，但实现细节可能导致偶然退出 | 不确定（非标准） |
结论：你的本地程序“Finished.” 快速输出，并非因为后台 goroutine 自动退出，而是 main 结束后整个进程被操作系统回收——那条 for 循环 goroutine 实际上被粗暴终止。这不是优雅协作，而是 Go 的设计契约：main 是唯一权威的生命周期管理者。要实现协同终止，请始终使用 channel、sync.WaitGroup 或 context 显式协调。
