go 运行时对短时系统调用（如小文件写入）会复用 os 线程，避免频繁创建销毁；只有当 i/o 操作真正阻塞较长时间（如大文件同步写、磁盘高负载），调度器才会按需扩容 m（os 线程）以维持 g 的并发执行。
在 Go 中，goroutine（G）的阻塞行为与底层 OS 线程（M）的分配并非一一对应。当 goroutine 执行 ioutil.WriteFile 等同步文件 I/O 时，若该操作能快速完成（例如写入几 KB 小文件），系统调用会迅速返回，Go 调度器无需为其额外绑定新线程——原有 M 可立即继续调度其他 G，因此线程数保持稳定（如你实验中仅显示 5 个线程）。
但一旦 I/O 变为真实阻塞（如写入 128MB 大文件），内核层面的 write() 系统调用可能因页缓存压力、磁盘吞吐瓶颈或同步刷盘（fsync）而显著延迟。此时，Go 运行时检测到当前 M 被长期占用，便会启动新的 OS 线程（M）来接管其他就绪的 goroutine，从而体现为线程数激增（如修改后示例达 203 个线程）。
以下是一个可验证阻塞行为的增强版示例（使用 os.File.Write + f.Sync() 强制同步写）：
package main
import (
"os"
"runtime"
"strconv"
"time"
)
func main() {
runtime.GOMAXPROCS(2)
data := make([]byte, 10*1024*1024) // 10MB 数据，增大阻塞概率
for i := 0; i < 50; i++ {
go func(n int) {
filename := "test_sync_" + strconv.Itoa(n) + ".bin"
for j := 0; j < 3; j++ { // 每个 goroutine 写 3 次
f, err := os.Create(filename)
if err != nil {
return
}
_, _ = f.Write(data)
f.Sync() // 强制落盘，显著延长阻塞时间
f.Close()
time.Sleep(10 * time.Millisecond) // 避免日志刷屏
}
}(i)
}
// 保持主 goroutine 活跃，便于观察线程数
select {}
}⚠️ 注意事项：
- ioutil.WriteFile（已弃用，推荐 os.WriteFile）本质是 os.Create + Write + Close，其阻塞程度取决于文件大小、存储介质和内核缓冲策略；
- Go 1.14+ 引入了异步抢占与更精细的系统调用封装，但同步 I/O 仍遵循“阻塞即让出 M”的原则；
- 线程数不是性能指标，盲目追求高线程数反而增加调度开销；应优先使用 bufio.Writer、批量写入或异步 I/O（如 io_uring via CGO）优化吞吐。
总结：Go 的线程复用机制是性能关键设计——它不为每个阻塞 goroutine 立即创建线程，而是动态按需扩容。你的初始测试因 I/O 过快未触发扩容阈值；增大数据量或强制同步操作后，才能清晰观察到 Go 调度器对真实阻塞场景的自适应响应。
