不会。阻塞系统调用（如os.ReadFile）会剥离当前M，启动新M执行调用，原M立即调度其他G；该机制仅适用于标准库封装的syscall，不适用于CGO中直接调用的C函数。
阻塞系统调用会卡住整个 goroutine 吗？
不会。Go runtime 调度器在检测到 goroutine 进入阻塞系统调用（如 os.ReadFile、syscall.Read）后，会在约 20 微秒内自动将其从当前 M（OS 线程）上剥离，并启动一个新的 M 专用于执行该调用。原 M 立即恢复运行其他就绪的 goroutine。
这个过程对用户代码完全透明：你写同步风格的 I/O 逻辑，调度器已在底层完成线程复用。这也是 HTTP 服务器能用 net/http 处理数万并发连接却无需显式异步封装的根本原因。
- 仅适用于 Go 标准库封装的 syscall（如
os.Open、io.Copy），不适用于 CGO 中直接调用的 C 函数（如fread） - Linux/macOS/Windows 均支持，行为一致
- 不是“非阻塞”，而是“阻塞但不拖垮调度”
为什么 time.Sleep 不触发线程剥离？
time.Sleep 是 Go 自己实现的定时器机制，背后由 runtime 的 timer heap 和网络轮询器（netpoller）驱动，不进入系统调用 —— 它本质是让 goroutine 挂起并加入定时器队列，调度器直接将其移出运行队列，不涉及 OS 线程阻塞。
对比之下：syscall.Read 或 os.Read 会真正陷入内核态等待数据就绪，这才触发调度器的线程剥离逻辑。
-
time.Sleep→ goroutine 挂起，P 可立即调度其他 G -
syscall.Read（阻塞文件）→ G 被剥离，新 M 启动，原 M 继续跑其他 G - 两者都“不卡 P”，但底层机制完全不同
CGO 或 unsafe 调用阻塞函数时会发生什么？
如果通过 CGO 直接调用 C 标准库的 fread、sleep，或用 unsafe 绕过 Go runtime 的 syscall 封装，这些调用将**完全绕过调度器的监控与干预**。此时 goroutine 会真实阻塞所在 M，且不会自动派生新线程 —— 若该 M 是唯一可用线程（如 GOMAXPROCS=1），整个程序可能假死。
- 避免在 CGO 中调用任何可能长时间阻塞的 C 函数
- 必须使用时，应配合
runtime.LockOSThread()+ 显式线程池，或改用 Go 标准库等价接口（如os.ReadFile替代fread） - Go 1.14+ 的抢占式调度无法覆盖此类外部阻塞点
如何验证某个调用是否被调度器接管？
最直接的方式是观察 goroutine 数量与 OS 线程数的关系：在阻塞调用期间，用 ps -T -p $(pidof yourprogram) 查看线程数是否临时增长；或在调试时启用 GODEBUG=schedtrace=1000，观察 trace 日志中是否有 goroutine blocked on syscall 类似提示。
- 标准库 I/O（
os.Read、net.Conn.Read）几乎总是被接管 - 自定义 syscall 封装需确保调用的是
syscall.Syscall系列函数（而非裸汇编或 C 函数） - 一旦看到 M 数量在 I/O 高峰期明显上升，基本可确认调度器已介入
