os.ReadFile 不支持超时，需封装为分块读取并每次检查 ctx.Done()；推荐用 os.Open + 64KB 缓冲区 + select 监听上下文取消，避免 NFS 卡顿导致 goroutine 泄漏。
os.ReadFile 无法直接加超时，必须封装或换路径
os.ReadFile 是同步阻塞调用，底层不接收 context.Context，也不支持 deadline。NFS 挂载点断连、磁盘卡顿等场景下，它可能 hang 住数分钟甚至更久，goroutine 不可回收。
- 不能对
os.ReadFile外套select+time.After—— 超时触发后，文件读取仍在后台运行，句柄和内存都不释放 - 小文件且确定本地路径可靠时，可用
context.WithTimeout+ 自定义封装（见下一条），但不推荐用于生产级大文件或网络文件系统 - 更稳妥的替代方案是改用
os.Open+ 分块读取 + 主动检查ctx.Done()，或换用支持 context 的抽象层（如io/fs封装 + 自定义ReadDir等）
分块读取时必须每次调用前检查 ctx.Done()
大文件读取最常见错误：只在循环外检查一次 ctx.Done()，导致某一块读取卡住就彻底失控。例如 NFS 上一次 Read 可能阻塞几十秒，而你毫无感知。
- 缓冲区大小建议设为
64 * 1024（64KB），太大易 OOM，太小频繁系统调用损耗高 - 每次调用
file.Read(buf)前，必须select监听ctx.Done()，不能只在循环开始或结束处检查 - 不要用
time.Sleep做重试或等待——它不可中断；要用select+ctx.Done()+ 定时器组合 - 若读取返回
syscall.ETIMEDOUT或syscall.ESTALE（常见于 SMB/NFS），应明确判断并决定是否重试
bufio.Scanner 逐行读取需在 Scan() 后立即检查取消信号
bufio.Scanner.Scan() 本身不阻塞在 ctx.Done() 上，它只负责解析换行符。如果底层 file.Read 卡住，Scan() 就会一直等，直到系统调用返回。
- 正确写法是在每次
scanner.Scan()返回 true 后，立刻select判断ctx.Done() - 不能把
select放在for外层——那样只检查一次，完全失去超时意义 - 对日志类长尾文件，还要考虑单行超长导致内存暴涨，建议用
scanner.Buffer限制最大扫描缓冲区（如scanner.Buffer(make([]byte, 4096), 1） - 注意：即使设置了 buffer 限制，
scanner.Err()仍可能返回bufio.ErrTooLong，需显式处理
网络文件系统（NFS/SMB）上超时更难控制，需降级策略
普通本地文件的 Read 至少能靠分块 + ctx.Done() 拉回控制权；但 NFS/SMB 在内核态卡住时，Go 层面几乎无法干预——SetReadDeadline 对这类文件描述符无效，unix.Flock 也无原生超时。
立即学习“go语言免费学习笔记（深入）”；
- 唯一可行路径是：非阻塞尝试 + 轮询 +
ctx.Done()主动退出。例如用unix.Flock(fd, unix.LOCK_EX|unix.LOCK_NB)替代阻塞flock - 轮询间隔不低于
100ms，避免 CPU 空转；每次轮询都走select，不是time.Sleep - 遇到
syscall.EAGAIN或syscall.EWOULDBLOCK可重试；遇到syscall.ENOTCONN或syscall.EIO应立刻放弃 - 最终 fallback 方案是提前创建临时副本（如
cp /mnt/nfs/file /tmp/local-copy），再读本地路径——代价高但可控
真正麻烦的从来不是“怎么加 timeout”，而是“timeout 触发后，所有依赖资源是否已释放”。比如一个 os.File 被卡在 read，又没被 close，fd 就一直泄漏；再比如 multipart.File 被 io.Copy 半途打断，临时磁盘文件却没清理。这些细节不手动兜底，超时就只是个假象。
