不会。Go运行时检测到阻塞系统调用（如read/write）后约20微秒内自动将goroutine从当前M剥离并启用新M执行，原M立即调度其他goroutine，该机制对用户透明且仅适用于标准库封装的syscall。
Go 文件 I/O 阻塞时调度器真会卡住吗
不会。Go 运行时对阻塞系统调用（如 read()、write() 到普通磁盘文件）有自动解耦机制：当检测到 goroutine 进入长时间阻塞（Linux 下约 20 微秒），调度器会将其从当前 OS 线程（M）上剥离，并启动新 M 继续执行该调用，原 M 立即恢复运行其他 goroutine。
这意味着你写 os.ReadFile("big.log") 或 file.Read(buf)，表面是同步阻塞调用，实际不会拖垮整个 P/M 调度链——无需手动起 goroutine 包一层来“防卡死”。
- 这是 Go 能用同步风格写出高并发 HTTP 服务的底层保障
- 但注意：该机制只适用于系统调用级阻塞（如磁盘文件、pty、部分 syscall），不适用于纯 CPU 计算或无协作点的循环
- 若观察到 goroutine 大量堆积在
syscall.Syscall上，大概率是文件描述符耗尽、磁盘 IO 饱和或 NFS 等网络文件系统延迟异常，而非调度器失效
什么时候该显式用 goroutine 并发文件操作
不是为了“避免阻塞”，而是为了**重叠等待时间、提升吞吐**——比如同时读 10 个日志文件、并发处理多个上传分片、并行压缩不同目录。
- 用
errgroup.Group启动并发任务，天然支持上下文取消和错误传播 - 必须限制并发数：通过带缓冲 channel 或
semaphore.NewWeighted(20)控制 goroutine 数量，防止打开过多 fd（Linux 默认 soft limit 通常为 1024） - 每个 goroutine 应独立
os.OpenFile，不要共享*os.File；多 goroutine 写同一文件需额外同步（如file.WriteAt分段写） - 避免在循环里无节制
go func() { ... }()：未加控制的 1000 个 goroutine 可能瞬间打爆 ulimit
bufio 缓冲区大小怎么设才不浪费也不卡顿
默认 4KB 缓冲（bufio.NewReader(file)）对小文本够用，但对大文件流式处理常成瓶颈。关键不是“越大越好”，而是匹配**硬件块大小 + 数据访问模式**。
立即学习“go语言免费学习笔记（深入）”；
- 顺序读大日志/二进制：设为
64 * 1024或128 * 1024，减少read()系统调用次数 - 随机访问小记录（如 KV 日志）：保持默认 4KB，过大的缓冲反而增加首字节延迟
- 写入场景：用
bufio.NewWriterSize(w, 32*1024)，但必须在关闭前调用Flush()，否则最后一批数据可能丢失 - 绝对不要混用：
file.Read()和bufio.Reader.Read()操作同一个*os.File，缓冲区状态不同步会导致丢数据
sync.Pool 复用 buffer 的真实收益点在哪
不是所有场景都值得上 sync.Pool。它的价值集中在**高频分配固定尺寸临时缓冲**的场景，比如批量解析 CSV 行、中转小文件、日志格式化。
- 典型模式：
var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 32*1024) }} - 用
buf := bufPool.Get().([]byte)拿缓冲，处理完bufPool.Put(buf)归还 - 对单次大文件读（如 >100MB），直接
make([]byte, size)更简单，sync.Pool管理开销反而不划算 - 基准测试时看
allocs/op：若优化后该值显著下降（比如从 50→2），说明 GC 压力缓解有效；若只是ns/op微降，可能是过早优化
真正容易被忽略的是：文件 I/O 性能瓶颈往往不在 Go 代码层，而在磁盘队列深度、文件系统缓存策略、甚至 NFS 客户端参数。上线前务必用 go test -bench=. -benchmem 测真实数据，再结合 iostat -x 1 看 %util 和 await，才能定位到底是 Go 调度问题，还是底层存储拖了后腿。
