Go文件与网络编程应从os.Open+io.Copy和http.Client.Do等底层API入手，理解流式处理、错误传播、资源管理及背压机制，避免过早使用高级封装导致线上问题。
从 os.Open 和 io.Copy 开始，别碰 os.ReadFile 就急着写配置加载
Go 文件编程的入口不是高级封装，而是理解「文件描述符」和「流式处理」的底层契约。新手常一上来就用 os.ReadFile 读小配置，结果在处理大日志文件或网络响应体时 panic：内存爆了或超时没设。os.Open + io.Copy 是最稳的起点，它强制你面对 io.Reader/io.Writer 接口，也自然引出错误检查、资源关闭、缓冲控制等真实问题。
-
os.Open返回*os.File，必须配对调用Close()；漏掉会导致文件句柄泄漏（Linux 下默认上限 1024） -
io.Copy默认用 32KB 缓冲区，对千兆文件够用；若需更高吞吐，可传入自定义bufio.Writer - 别用
strings.NewReader模拟文件测试——它不触发系统调用，掩盖syscall.EAGAIN类错误
HTTP 客户端先死磕 http.Client.Do，绕开 http.Get
http.Get 看似简单，但隐藏了超时、重定向、连接复用等关键控制点。新手用它发请求，遇到「卡住 5 分钟才返回」或「并发 200 请求直接夯住」时完全无从下手。直接学 http.Client.Do，配合自定义 http.Client 实例，才能看清网络行为的全貌。
- 必须显式设置
Timeout字段：&http.Client{Timeout: 10 * time.Second}，否则默认无限等待 - 复用连接靠
Transport，不是靠复用Client；默认http.DefaultClient的 Transport 允许最多 100 个空闲连接，但 keep-alive 超时是 30 秒 -
Do不自动处理重定向；要支持，得自己检查resp.StatusCode == 302并读取Locationheader
服务端起步用 net/http.ServeMux，别被 gin 或 echo 带偏节奏
第三方 Web 框架把路由、中间件、JSON 序列化全包圆了，新手反而看不到 HTTP 协议怎么落地。用标准库 net/http.ServeMux 写几个 handler，你会亲手处理 http.Request.Body 的读取时机、Content-Length 校验、multipart/form-data 解析边界——这些正是线上接口 500 错误的高发区。
-
http.Request.Body是io.ReadCloser，只能读一次；二次读会返回空；想复用得用io.TeeReader或提前io.ReadAll缓存 -
ServeMux不支持路径参数（如/user/:id），但能暴露URL.Path字符串，足够练手字符串切分和path.Clean防遍历攻击 - 启动服务别用
http.ListenAndServe(":8080", nil)——nil表示用默认DefaultServeMux，容易被其他包悄悄注册路由导致冲突
文件与网络交叉场景：用 io.MultiReader 和 io.Pipe 连接二者
真实项目里，文件上传后要转发给下游 API，或日志文件要实时推到 WebSocket。这时不能把整个文件读进内存再发，得用流式拼接。标准库的 io.MultiReader 和 io.Pipe 就是为此而生，它们不新增依赖，且能清晰暴露背压（backpressure）问题。
-
io.MultiReader把多个io.Reader串成一个，适合「头部 JSON 元数据 + 后续二进制文件内容」这种混合格式 -
io.Pipe创建配对的io.Reader/io.Writer，一端写、另一端读；注意写端未关闭时，读端会阻塞——这是调试流式卡顿的第一线索 - 上传文件到 HTTP 服务时，用
multipart.Writer写入io.Pipe的Writer，同时用http.NewRequest的Body设为该Pipe的Reader，实现零拷贝转发
pr, pw := io.Pipe()
go func() {
defer pw.Close()
mw := multipart.NewWriter(pw)
part, _ := mw.CreateFormFile("file", "log.txt")
io.Copy(part, file) // file 是 *os.File
mw.Close()
}()
req, _ := http.NewRequest("POST", "https://api.example.com/upload", pr)
req.Header.Set("Content-Type", mw.FormDataContentType())
文件和网络的边界在流上消失，但错误传播不会消失——pw.Close() 前的任何写错误，都会在 pr.Read 时以 io.ErrClosedPipe 形式爆发。这点最容易被忽略。
