runtime.Gosched 仅在自旋等待且无法用 channel 或 sleep 替代的极少数场景下有效，如硬件寄存器轮询；它不保证内存可见性、不释放锁、不提供同步语义，也不能替代 time.Sleep。
runtime.Gosched 不该是你的默认选择，它只在极少数自旋等待且无法用 channel 或 sleep 替代的场景下才真正有用。
什么时候调用 runtime.Gosched 才有效
它只在当前 goroutine 持续占用 P、又没任何阻塞点（比如 channel 收发、time.Sleep、系统调用）时起作用。典型场景是手写轮询逻辑，且不能加锁或等条件变量 —— 比如嵌入式设备里读某个硬件寄存器标志位。
- for {} 空循环中每轮都加
runtime.Gosched()，能避免卡死调度器，但只是“治标” - 如果循环体里有密集计算（如遍历大 slice），Go 1.14+ 的异步抢占可能已自动中断，再加
Gosched是冗余 - 它对内存可见性无任何保障：自旋读一个全局
bool变量时，不加atomic.LoadUint32或sync/atomic原语，编译器可能直接优化掉重复读
为什么 runtime.Gosched 不能替代 time.Sleep(0)
time.Sleep(0) 在 Go 1.14 之后已不是“退化为 Gosched”，而是真实触发一次纳秒级休眠，会把 goroutine 移入定时器等待队列，再唤醒时重新参与调度。而 runtime.Gosched 只是放回运行队列尾部，下一轮很可能立刻被选中——它不改变 goroutine 状态，也不引入任何等待语义。
- 想“停一下再试”，用
time.Sleep(1 * time.Nanosecond)更可靠 - 想“等某个条件成立”，必须用
channel或sync.Cond，Gosched不解决同步问题 - 频繁调用
Gosched会制造大量无意义的调度抖动，实测比time.Sleep(0)开销更低，但行为更难预测
常见误用：在 long-running 计算中盲目插入 Gosched
比如写了个遍历千万级 map 的函数，每百次迭代就调一次 runtime.Gosched()，结果发现其他 goroutine 还是饿死——因为调度器还没来得及响应，或者当前 P 上压根没有其他可运行 goroutine。
- 优先检查是否真需要“手动让出”：若函数本身含
http.Get、os.ReadFile、select等，调度器早已介入 - 若必须做 CPU 密集型任务，考虑拆成小块 +
time.Sleep或用context.WithTimeout控制总耗时 -
runtime.Gosched不释放锁、不暂停 timer、不影响 defer 链，它真的只是“歇半拍”
真正容易被忽略的是：它不提供任何同步语义，也不保证可见性。你看到的“别的 goroutine 跑起来了”，可能只是巧合；而你读到的“变量已更新”，大概率是缓存未刷新导致的假象。
