不阻塞，但会暂时脱离Go调度器直接控制；C调用超20微秒后sysmon解绑M，允许其他goroutine在新线程运行，死锁检测因无法预判C回调而保守跳过panic。
Go 用 cgo 调用 C 代码时，goroutine 不会“挂起”整个调度器，但可能表现为单个 goroutine 长时间卡在 C 函数里、其他 goroutine 响应变慢，甚至死锁检测失效——这不是 bug，是运行时对 C 世界不可控性的主动妥协。
cgo 调用期间 goroutine 是否阻塞调度器？
不阻塞，但会暂时脱离 Go 调度器的直接控制。调用 C.xxx() 时，当前 goroutine（G）会绑定到一个 OS 线程（M），并暂停参与 Go 层面的调度；此时若 C 函数执行超时（约 20 微秒以上），sysmon 会标记该 M 为可解绑，允许其他就绪 G 在新线程上启动。
这意味着：
- 短时 C 调用（如
C.strlen）几乎无感知，G 仍计入GOMAXPROCS配额 - 长时阻塞调用（如未设 timeout 的
read()、pthread_cond_wait()）会导致该 M 占用资源，虽不卡死全局调度，但可能拖慢整体吞吐 - 若 C 代码中调用了 Go 函数（反向调用），必须提前调用
runtime.LockOSThread()，否则 runtime 可能 panic
为什么死锁检测器对 cgo 场景静默失效？
Go 死锁检测器只看 goroutine 当前状态是否全为“非可运行”，但它无法知道 C 代码是否会异步唤醒某个 goroutine。例如 net/http.Get 底层走 cgo 的 epoll/kqueue，C 层随时可能回调 runtime.netpoll，所以检测器保守跳过 panic。
验证方式：
-
CGO_ENABLED=0 go run main.go→ 立即触发fatal error: all goroutines are asleep - deadlock! -
CGO_ENABLED=1 go run main.go→ 可能无限 hang，CPU 0%，无日志，极难定位 - 用
GODEBUG=schedtrace=1000观察 M 数量变化，确认是否有线程被长期占用
常见挂起现象与对应排查点
所谓“协程挂起”，往往不是调度器坏了，而是你没看清控制权在哪。典型表现和原因：
- goroutine 打印完日志后不再推进，且 CPU 归零：大概率卡在 C 的阻塞系统调用（如
connect()、recv()），需检查是否设置了 socket timeout 或使用非阻塞模式 - 多个 goroutine 同时卡住，但
pprof/goroutine?debug=2显示它们都停在runtime.cgocall：说明 C 层存在共享资源竞争（如全局锁、信号量未释放）或回调未触发 - 程序在
defer或recover中不生效：C 代码崩溃（segfault）会绕过 Go 的 panic 机制，直接终止进程；需用signal.Notify捕获SIGSEGV并人工处理 - 内存泄漏 + goroutine 积压：Go 分配的结构体传给 C 后，Go 端未保持引用，GC 回收导致 C 持有悬空指针，后续访问引发未定义行为，表现为随机 hang 或 crash
如何让 cgo 调用更可控？
核心原则：别把 C 当透明胶水，要当独立子系统对待。
- 所有传给 C 的 Go 内存（如
*C.struct_xxx），必须由 Go 端显式持有引用（如保存到全局 map 或 struct 字段），避免 GC 提前回收 - 避免在 C 代码中做耗时计算或 I/O；必须做时，用
pthread_create启新线程，并确保回调进 Go 前已调用runtime.cgocall兼容逻辑 - 对关键 C 调用加超时：用
select+time.After包裹，或在 C 层使用带 timeout 的 API（如poll()替代read()） - 调试阶段启用
GODEBUG=cgocall=1，可打印每次 cgo 进出栈，快速定位卡点
最易被忽略的一点：cgo 不是函数调用，是跨语言边界。一旦越过那条线，Go 的一切保障（GC 安全、panic 捕获、调度可见性）都得重新协商——你得自己写协议，而不是指望 runtime 猜你意图。
