Go模块不参与调度，调度由runtime控制；net/http跨平台差异源于netpoller依赖的系统原语不同：Linux用epoll、Windows用IOCP、macOS用kqueue，导致吞吐、M复用和阻塞行为各异。
Go 的模块本身不参与调度——调度完全由运行时（runtime）控制，和你用什么模块无关。真正影响并发行为的是 GOMAXPROCS、系统调用类型、阻塞点位置，以及底层 OS 对线程/信号/IO 的实现差异。
为什么 net/http 在 Linux 和 Windows 上表现不同？
根本原因不是模块写法，而是 netpoller 依赖的系统原语不同：
- Linux 使用
epoll：事件就绪后唤醒对应 G，M 不阻塞，P 可立即复用 - Windows 使用
IOCP：完成端口机制类似，但初始化开销略高，且某些低版本 Go 对 overlapped I/O 的封装存在额外锁竞争 - macOS 使用
kqueue：行为接近 epoll，但对空闲连接的超时处理更保守，可能延迟释放 M
典型现象：net/http.Server 在高并发短连接场景下，Linux 通常吞吐更高、M 复用更及时；Windows 可能出现短暂的 M 数飙升（尤其 Go < 1.21），表现为 runtime.NumThread() 突增。
time.Sleep 和 syscall.Read 的阻塞路径差异
这两类操作触发的调度行为在各平台一致，但底层等待机制不同，间接影响响应速度：
立即学习“go语言免费学习笔记（深入）”；
-
time.Sleep：走 Go 自己的定时器队列，与 OS 无关，所有平台行为一致 -
syscall.Read（如读 pipe 或 socket）：- Linux：若 fd 设置为 non-blocking，失败返回
EAGAIN，G 挂起，M 回调度循环 - Windows：即使 non-blocking，某些句柄（如 console input）仍可能同步阻塞 M，导致 P 饥饿
- Linux：若 fd 设置为 non-blocking，失败返回
所以你在 Windows 上用 os.Stdin.Read 启动 goroutine，容易卡住整个 P；而在 Linux 上它会立刻让出控制权。
runtime.LockOSThread() 在不同 OS 的副作用强度
这个函数让当前 G 绑定到一个 M，禁止调度器抢占，但它在各平台“锁死程度”不同：
- Linux：M 被
pthread_setaffinity_np限制核亲和性后，仍可被内核调度到其他 CPU，只是 Go 不再往它上面派任务 - Windows：
SetThreadAffinityMask效果更强，且某些 Go 版本（≤1.20）未正确恢复线程状态，可能导致后续UnlockOSThread()失效 - macOS：线程绑定后，若该 M 进入系统调用（如
read），运行时无法安全解绑，容易触发fatal error: thread unlocked when lock count != 0
结论：跨平台使用 runtime.LockOSThread() 必须配对 UnlockOSThread()，且避免在可能触发系统调用的路径里调用它。
goroutine 长时间计算不 yield 的平台一致性陷阱
纯 CPU 循环（无函数调用、无内存分配、无 channel 操作）在所有平台都**不会自动让出 P**，但“看起来卡住”的感知程度不同：
- Linux/macOS：sysmon 抢占阈值默认 10ms，一旦检测到 G 运行超时，会在下一次函数调用入口插入抢占点
- Windows：早期 Go 版本 sysmon 定时精度受系统 API 限制（如
timeGetTime），实际抢占延迟可能达 15–20ms，导致单核场景下其他 G 响应明显滞后 - 关键点：抢占只发生在“安全点”，比如函数调用、栈增长、GC 检查处。如果你的循环里只有整数运算，哪怕跑满 1 秒，也不会被中断——无论什么平台
所以别指望操作系统帮你切走失控 goroutine；真正可靠的 yield 方式永远是显式插入 runtime.Gosched() 或触发任意调度点（如 time.Now()、println()、哪怕一次空 select{}）。
