文件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 时。