关键在于用ProgressReader包装文件流劫持Read调用，原子更新计数（单goroutine可省同步但需注明，多goroutine推荐sync.Mutex），回调不可阻塞，total需按场景动态获取（本地文件用Stat.Size，HTTP下载用Content-Length，multipart需预扫描或接受动态total），并确保绑定在Request.Body读取路径上。
Go 里想在读文件时显示进度条，关键不是改 io.Copy，而是用一个轻量包装器劫持每次 Read 调用——只要它能拿到原始数据、累计字节数、触发回调，就足够了。
ProgressReader 的 Read 方法必须原子更新计数
并发读取时（比如多个 goroutine 同时调用 Read），read 字段会竞争错乱。常见错误是直接写 pr.read += int64(n)，没加锁也没用原子操作。
- 若只在单 goroutine 中使用（如配合
io.Copy），可省略同步逻辑，但代码要显式注明 “not safe for concurrent use” - 若需多 goroutine 安全，推荐用
sync.Mutex包裹更新和回调（比atomic.AddInt64更易控制回调时机） - 回调函数本身不能阻塞；否则会拖慢整个读取流程，尤其在小缓冲区（如默认 32KB）下，1GB 文件可能触发超 32K 次同步调用
不要用 os.Stat().Size() 当实时 total
很多初学者在构造 ProgressReader 时直接传 file.Stat().Size() 当 total，这在本地文件没问题，但一旦换成 http.Response.Body 或管道（io.Pipe），Size() 就是 -1 或不准——因为流长度根本不可知。
- 上传场景中，
total应来自os.File.Stat().Size()（仅限已知大小的本地文件） - 下载场景中，优先从
resp.Header.Get("Content-Length")解析；若为空，设为 0 并用 “已读 / ?” 格式显示（避免除零 panic） - 对
multipart上传，multipart.Writer写入前无法预知总长，此时应先用io.MultiWriter+io.TeeReader预扫描或接受动态total
io.TeeReader 是更简洁的替代方案，但有隐含约束
io.TeeReader(r, w) 本质是把从 r 读出的数据，同步写入 w，再返回新 Reader。它天然适合“边读边记”的场景，比如写日志+计数。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 它不暴露当前读了多少，得自己实现一个
io.Writer（如ProgressWriter）来接收“被 tee 出去”的数据并累加 - 写入
w的过程是阻塞的：如果w.Write慢（比如写磁盘卡顿），Read就会卡住——这点和自定义ProgressReader的callback一样，但更容易被忽略 - 它无法区分“读成功但写失败”的情况；错误会从
Write返回并终止后续Read，而自定义ProgressReader可选择忽略写失败只计数
上传进度必须绑定在 Request.Body 的读取路径上
HTTP 上传时，进度监控点必须落在 Request.Body.Read 这一层。把 ProgressReader 直接塞进 http.NewRequest() 的 Body 字段，是唯一可靠方式；其他绕过 Body 读取路径的方案（如监听 TCP 层、抓包、轮询服务端状态）都属于事后补救，无法反映真实客户端发送节奏。
- 确保
ProgressReader实现了io.Seeker（如需重试或断点续传），否则某些 HTTP client 会 panic 或静默失败 - 如果用了
multipart.Writer构造请求体，ProgressReader必须包装原始文件流，而不是包装最终的bytes.Buffer或io.Reader—— 后者已失去与原始文件的字节对应关系 - 大文件上传务必设置超时和最大内存限制，防止
ProgressReader回调中意外阻塞导致整个请求 hang 住
最易被忽略的是：进度回调的触发频率和实际 I/O 缓冲区大小强相关。用默认 32KB 缓冲读 1GB 文件，回调会被调用 32K 次；若回调里做 fmt.Printf 或 HTTP 请求，性能会断崖式下跌。节流必须做，而且得在 Reader 内部做，不能靠外部 sleep 或 timer 控制。
