Go的goroutine抢占机制不保证打断纯for{}循环，因其仅在安全点（如函数调用、栈检查）触发；Go 1.21起通过asyncPreempt桩增强抢占，但nosplit/noinline/CGO等仍绕过；验证需借助schedtrace或pprof；可靠做法是主动插入Gosched()。
goroutine 抢占机制不是靠“学完文档就能用”，而是必须结合运行时行为观察、代码干预和错误复现来建立直觉。Go 1.14+ 默认启用抢占，但**它不保证打断任意循环**——纯 for {} 仍可能卡死，尤其在旧版本或特定编译条件下。
为什么 for { i++ } 有时就是不被抢占？
这不是 bug，是设计约束：抢占只发生在安全点（safepoint），比如函数调用入口、栈增长检查、GC 扫描点。而一个空循环若没函数调用、没栈操作、没系统调用，就永远走不到安全点。
- Go 1.14–1.20 对纯计算循环的抢占依赖
sysmon发送SIGURG信号，但信号需等目标M返回用户态才处理；若M卡在内核态（如阻塞 syscall），信号延迟甚至丢失 - Go 1.21 起默认插入
asyncPreempt汇编桩，能在更多指令间隙触发，但仍有例外：标记了//go:nosplit或//go:noinline的函数、CGO 调用、部分 runtime 汇编函数（如memclrNoHeapPointers）会跳过 -
GODEBUG=asyncpreemptoff=1会禁用异步抢占路径，只剩morestack同步路径——此时for { i++ }彻底逃逸
怎么验证当前 goroutine 是否被抢占过？
没有公开 API，但可通过运行时调试信号间接确认：
- 启动时加
GODEBUG=schedtrace=1000,scheddetail=1，观察输出中某G状态是否在running和runnable间高频切换，且间隔接近 10ms - 用
runtime/pprof抓取goroutineprofile，看是否有大量runtime.gosched_m出现在调用栈顶部 - 在疑似卡住的 goroutine 中插入
runtime.Gosched()，若问题消失，说明原逻辑缺失调度点——这是最直接的证据
如何写出不易被抢占绕过的代码？
别依赖“调度器一定会打断我”，主动暴露调度点才是可靠做法：
- 避免长纯计算循环：把
for i := 0; i 拆成每 1000 次调用一次 <code>runtime.Gosched()或time.Sleep(0) - 慎用
//go:noinline和//go:nosplit：它们会屏蔽抢占检查，除非你明确知道自己在做什么（如底层内存操作） - CGO 调用期间抢占默认关闭（Go 1.22 前），若必须在 CGO 中做长耗时计算，应在 C 侧定期调用
runtime·gosched（需导出并从 C 调用） - 注意
select {}是阻塞原语，不是调度点；真正让出的是runtime.gopark，它发生在 channel 操作、timer 等阻塞调用中
