runtime.Goexit仅用于goroutine内主动退出且不执行defer；runtime.Gosched是让出P的时间片而非挂起goroutine，不可替代sleep。
runtime 包不是给你日常写业务逻辑用的，它是 Go 程序的“内脏监控台”——只在你真需要干预调度、诊断卡顿、压测内存或理解 panic 根源时才该伸手进去。
什么时候必须碰 runtime.Goexit？
它唯一合法的用途是：在 goroutine 内部主动退出，且不希望执行后续代码（包括 defer）。
- 常见错误：把它当
return用在普通函数里 → 编译报错：cannot use runtime.Goexit() (value of type) - 正确场景：启动一个 goroutine 做初始化，失败就静默退出，不污染主流程
- 注意：
Goexit不会触发defer，这点和return本质不同；若需清理，得提前手动调用或改用 channel 通知
go func() {
if err := setup(); err != nil {
runtime.Goexit() // ✅ 正确：退出当前 goroutine
}
defer cleanup() // ❌ 这行永远不会执行
}()
runtime.Gosched 不是“让出 CPU”，而是“让出 P 的时间片”
它不会挂起当前 goroutine，只是告诉调度器：“我先歇半拍，你去跑别的 goroutine 吧”。但下次轮到这个 P，它大概率立刻继续执行你这 goroutine。
- 别指望靠它实现“协程 sleep”——要用
time.Sleep或select{case - 真实价值场景：长循环中防调度饥饿（比如解析大文件时每处理 1000 行调一次
Gosched），避免其他 goroutine 长时间得不到调度 - 现代 Go（1.14+）抢占式调度已大幅缓解该问题，除非你明确观察到
NumGoroutine持续飙升 +pprof显示某 goroutine 占满 P，否则不用加
查系统信息？别硬记常量，用 runtime 函数就行
比如获取 CPU 数、Go 版本、OS 类型，runtime 提供了稳定、跨平台的接口，比读环境变量或硬编码可靠得多。
立即学习“go语言免费学习笔记（深入）”；
-
runtime.NumCPU()返回 OS 可见的逻辑核数（非当前GOMAXPROCS值） -
runtime.GOMAXPROCS(0)是唯一安全读取当前并发限制的方式（传 0 表示只读不设） -
runtime.Version()比runtime/debug.ReadBuildInfo更轻量，适合日志打点 - 注意：
GOOS/GOARCH是编译期常量，运行时不能改；而GOMAXPROCS可动态调，但突增可能引发 GC 频繁或线程暴涨
fmt.Printf("CPUs: %d, MaxProcs: %d, GoVer: %s\n",
runtime.NumCPU(),
runtime.GOMAXPROCS(0),
runtime.Version())
别直接调 runtime.GC，除非你在做基准测试或调试 GC 行为
手动触发 GC 在生产环境几乎总是错的：它会强制 STW（Stop-The-World），打断所有 goroutine，还可能干扰 GC 自适应算法。
- 真正该用的，是
debug.SetGCPercent(n)控制 GC 触发阈值（默认 100），比如内存敏感服务可设为 50 - 想看 GC 细节？设环境变量
GODEBUG=gctrace=1，而不是自己调GC然后看日志 - 要等 GC 完成再继续？
runtime.GC()会阻塞，但更推荐用debug.ReadGCStats对比前后LastGC时间戳来判断
最常被忽略的一点：runtime 包里多数函数没有文档承诺的稳定性——比如 runtime.LockOSThread 或内部字段访问，一旦升级 Go 版本就可能行为突变。除非你正在写 cgo 互操作、写调试工具，或者 patch 标准库，否则别把它当“功能 API”用，而应视为“诊断探针”。
