io.copy 不提供进度回调因其设计追求简单高效无状态，需通过包装 io.writer 在 write 时累加并通知；应解耦进度计算与 ui 渲染，用 channel + goroutine 安全更新终端进度条。
为什么 io.Copy 本身不提供进度回调
io.Copy 的设计目标是简单、高效、无状态 —— 它只关心从 src 读、往 dst 写，中间不做任何额外计算或通知。这意味着你无法直接从 io.Copy 拿到已拷贝字节数，也就没法更新进度条。
真正能介入读写过程的，是包装 src 或 dst：要么用自定义 io.Reader 在每次 Read 后累加并通知；要么用自定义 io.Writer 在每次 Write 后统计。后者更常用，因为文件写入通常比读取更易观测（尤其涉及磁盘 I/O 时）。
常见错误是试图在 io.Copy 外层加 goroutine 定时查文件大小 —— 这不仅不准（源/目标可能被其他进程修改），还引入竞态和额外开销。
用 io.Writer 包装实现带回调的拷贝
核心思路：把目标 *os.File 包一层，让它在每次 Write 调用后触发回调，并返回真实写入字节数。这个包装器必须满足 io.Writer 接口，且不能破坏原有行为。
- 回调函数签名建议为
func(int64)，传入累计已写入字节数，避免浮点运算和精度丢失 - 务必在包装器的
Write方法里先调用底层Write，再更新计数并调用回调 —— 否则可能回调未执行就 panic - 如果目标文件支持
Seek（如本地文件），可在回调前用dst.Stat()验证当前大小，但别依赖它做进度计算，仅作校验 - 示例中不要用
time.Ticker主动轮询，而是靠Write自然触发，否则在小文件或慢速设备上会漏掉更新
简短示意：
type ProgressWriter struct {
w io.Writer
total int64
onWrite func(int64)
}
func (pw *ProgressWriter) Write(p []byte) (n int, err error) {
n, err = pw.w.Write(p)
pw.total += int64(n)
if pw.onWrite != nil {
pw.onWrite(pw.total)
}
return
}
如何安全地把进度同步到终端进度条
终端刷新不是线程安全操作，尤其当回调在 io.Copy 的 goroutine 中并发调用时。直接用 fmt.Printf 或 fmt.Print("\r...") 可能导致文字错乱、覆盖不全或光标跳位。
- 用单个 channel + 独立 goroutine 消费进度事件，统一控制输出节奏（例如限频 10Hz）
- 避免在回调里做耗时操作（如格式化大字符串、调用
os.Stdout.WriteString多次），全部交给消费者 goroutine 批量处理 - 进度条宽度建议固定（如 50 字符），用
\r回车但不用\n换行，防止滚动刷屏 - 注意 Windows 终端对
\r支持不稳定，可改用fmt.Fprint(os.Stdout, "\r"+bar)并确保末尾补空格清旧内容
关键点：进度数值和 UI 渲染解耦，回调只发信号，不负责渲染。
大文件拷贝时要注意的性能与兼容性问题
进度监控本身有开销，尤其在高频小块写入场景（如网络流、加密流）。实际使用中容易忽略三点：
-
io.Copy默认 buffer 是 32KB，但如果你用io.CopyBuffer自定义 buffer，要确保包装的ProgressWriter不干扰 buffer 复用逻辑 —— 它只应包装最终dst，别去包中间的 buffer - 某些文件系统（如 NFS、FUSE）或目标设备（USB 闪存）的
Write返回值可能小于请求长度，ProgressWriter必须严格按实际n累加，不能假设写满 - 如果源是
*os.File且支持Stat()，应在拷贝前获取fi.Size()作为总大小；但若源是管道或网络响应体，就只能用“已写 / 估算总长”或纯时间进度，强行硬算百分比反而误导用户
最麻烦的其实是中断恢复 —— 带进度的拷贝一旦被 kill 或 crash，没有原子性保证，也没法自动续传。这得靠上层业务自己记录 offset 并重开 Seek，不在 io.Copy 范畴内。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
