17370845950

文件I/O是同步且可定位的，网络I/O是异步封装、不可Seek的流式操作；前者依赖系统调用阻塞线程，后者由netpoller事件驱动实现高并发。

文件I/O是同步的，网络I/O是异步封装的

Go语言层面没有真正的“异步文件I/O”——os.File.Read 和 os.File.Write 调用最终都落到系统调用 read(2) / write(2) 上，是阻塞式同步行为。而网络I/O（如 net.Conn.Read）虽然表面也是阻塞调用，但底层由运行时的 netpoller 驱动：它用 epoll（Linux）或 kqueue（macOS）监听 socket 就绪事件，让 Goroutine 在等待数据时不真正阻塞 OS 线程，从而实现高并发。

• 你起 10k 个 Goroutine 去读文件？每个都会卡住一个 M（OS 线程），极易耗尽线程资源
• 你起 10k 个 Goroutine 去处理 HTTP 请求？只要不 CPU 密集，通常只用几个 M 就能调度完
• 文件 I/O 的并发提升，靠的是预读、缓冲（bufio.Reader

  

  ）、批量操作（io.Copy），不是靠“异步”

偏移量（offset）在文件I/O中显式重要，网络I/O中基本不存在

文件有明确的“位置”概念：os.OpenFile 打开后，每次 Read 或 Write 都从当前文件偏移处开始，并自动推进；你也可以用 file.Seek 显式跳转。而网络连接（如 TCP）是流式字节管道，没有“第 N 字节”的随机访问能力——conn.Read 总是从当前可读数据头开始取，没有 offset 参数，也不支持 Seek。

• os.File 实现了 io.Seeker 接口；net.Conn 不实现
• 想“重放”一段网络数据？得自己缓存到 []byte 或 bytes.Buffer，再构造 bytes.NewReader
• 误对 net.Conn 调用 Seek？编译不过——类型根本不兼容

错误处理方式不同：文件I/O多路径/权限类错误，网络I/O多状态/超时类错误

文件操作失败往往和路径、权限、磁盘空间强相关；网络操作失败则更常涉及连接状态、超时、对方关闭等动态条件。这意味着你该用的错误判断工具不一样：

• 判断文件不存在：os.IsNotExist(err) 或 errors.Is(err, fs.ErrNotExist)
• 判断目录已存在：os.IsExist(err)
• 判断网络超时：var ne net.Error; errors.As(err, &ne) && ne.Timeout()
• 判断连接被拒：errors.Is(err, syscall.ECONNREFUSED)（需 import "syscall"）

err := conn.Read(buf)
if err != nil {
    var netErr net.Error
    if errors.As(err, &netErr) {
        if netErr.Timeout() {
            log.Println("读取超时，可能客户端挂了")
        }
    } else if os.IsNotExist(err) {
        // 这个分支永远进不去：net.Conn.Read 不会返回 fs.ErrNotExist
    }
}

别指望用同一套缓冲策略“通吃”两者

bufio.Reader 对文件和网络都能用，但效果差异很大：对文件，它减少系统调用次数（一次 read 系统调用读多字节进 buffer）；对网络，它还能隐藏小包粘包问题（比如你 ReadString('\n') 时自动攒够一行才返回）。但注意：

• 文件用 bufio 后，Seek 行为变得不可预测（buffer 内数据未 flush，seek 可能跳过或重复读）
• 网络用 bufio 后，conn.SetReadDeadline 必须在 bufio.Reader 创建前设置，否则 deadline 不生效（因为底层 conn.Read 没被调用）
• 不要对同一个 os.File 同时用 bufio 和原生 Read —— buffer 和文件 offset 会脱节

文件 I/O 的“同步性”和“可定位性”是它的本质特征，不是缺陷；网络 I/O 的“伪阻塞+事件驱动”是 Go 运行时的精巧封装。混淆二者，轻则性能掉档，重则逻辑错乱——尤其当把文件当成流、把连接当成文件去 seek 或 reset 时。