go文件i/o与网络编程的常见问题在于资源未关闭、超时未设、错误忽略、缓冲区误用；os.open仅支持只读，写入/追加须用os.openfile；accept()需配合context或setdeadline防卡死；应避免ioutil.readall，改用io.readfull或bufio.scanner。
Go 的文件 I/O 和网络编程本身不难，但混在一起做真实项目时，常见问题不是语法错误，而是资源没关、超时没设、错误被忽略、缓冲区用错——这些细节直接导致服务卡死或数据损坏。
os.Open 与 os.OpenFile 的区别和选型
别只图省事全用 os.Open；它等价于 os.OpenFile(path, os.O_RDONLY, 0)，只读且无法指定权限。真正需要写入、追加、或创建不存在的文件时，必须用 os.OpenFile。
-
os.OpenFile("log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)是日志场景最常用组合 - 如果传了
0作为 perm 参数（比如os.O_CREATE但 perm=0），在 Linux 下会创建权限为---x--x--x的文件，后续写入失败 - 打开后务必检查返回 error，
nil不代表文件存在——比如路径是符号链接但目标不存在时，os.Open也会返回os.ErrNotExist
net.Listener 接收连接时的超时与上下文控制
用 net.Listen("tcp", ":8080") 启动监听器后，ln.Accept() 是阻塞调用，没有内置超时。一旦客户端半开连接或网络异常，Accept() 可能永远卡住。
- 正确做法是用
net.ListenConfig{KeepAlive: 30 * time.Second}配合SetDeadline或更推荐：用context.WithTimeout包裹整个 accept 循环 - 不要在
for { conn, _ := ln.Accept() }里忽略 error——ln.Accept()返回net.ErrClosed表示监听器已关闭，此时应退出循环 - 每个
conn建议立刻设置conn.SetReadDeadline和conn.SetWriteDeadline，否则一次卡住的读写会让 goroutine 泄漏
ioutil.ReadAll 已弃用，改用 io.ReadFull 或 bufio.Scanner
ioutil.ReadAll 在 Go 1.16 后被标记为 deprecated，因为无限制读取可能吃光内存。真实项目中必须按需控制读取边界。
立即学习“go语言免费学习笔记（深入）”；
- 确定数据长度（如 HTTP header 中的
Content-Length）时，用io.ReadFull(conn, buf)更安全 - 处理行协议（如自定义文本协议、Redis RESP）优先用
bufio.Scanner，并调用scanner.Buffer(make([]byte, 4096), 1 限制最大行长 - 若必须读全部，至少加上长度预估：
buf := make([]byte, 0, 64，再根据实际读到长度切片
文件读写与网络传输耦合时的流式处理
比如实现一个“上传文件 → 保存到磁盘 → 转发给后端服务”的代理逻辑，不能先 ReadAll 再 Write，否则大文件直接 OOM。
- 用
io.CopyN(dst, src, size)或io.Copy(dst, src)实现零拷贝转发，注意dst是http.ResponseWriter或net.Conn时，需提前写响应头 - 写文件时用
os.O_CREATE|os.O_WRONLY|os.O_TRUNC，避免旧内容残留；但若要原子替换，应写临时文件 +os.Rename - 多个 goroutine 同时写同一文件？不行。要么加
sync.Mutex，要么用syscall.Flock做文件级锁（Linux/macOS）
最常被跳过的其实是错误链路：比如 file.Close() 失败通常被忽略，但它可能意味着磁盘已满或 write buffer 未刷出——这类错误在日志归档、配置热加载等场景下会悄悄破坏一致性。