io.Copy是字节流桥接器，仅在io.Reader和io.Writer间原样复制数据，不解析、不缓存全量、不关资源、不设超时、不保元数据；其阻塞源于底层Reader/Writer行为，如stdin未终止、连接未关闭或管道无读端等。
io.Copy 不是搬运文件的函数，它是搬运字节流的桥接器——只管把 src 读出来的字节，原样塞进 dst 写进去，中间不解析、不缓存全量、不关资源、不设超时、不保元数据。
它真正的作用，是让任意两个实现了 io.Reader 和 io.Writer 的东西“通上电”，形成一条数据流水线。能不能跑通、跑多快、会不会卡死，全看两端是否配合、错误是否被检查、资源是否被释放。
为什么 io.Copy 会卡住？常见阻塞点在哪
卡住不是 io.Copy 的 bug，而是它忠实反映了底层 Reader/Writers 的行为：
-
os.Stdin作为src时，不输入 Ctrl+D（Unix）或 Ctrl+Z（Windows）就不会返回io.EOF，io.Copy一直等 - 网络连接（如
net.Conn）未关闭、远端没发 FIN 包，Reader 就可能永远阻塞在Read - Writer 是管道（
io.PipeWriter）但没人从另一端读，写满缓冲区后就会阻塞 - 目标磁盘满、权限不足、NFS 挂载异常等，错误可能延迟返回，表现像“卡”
复制文件时必须手动处理的三件事
用 io.Copy 复制文件，只是流水线中间一环；打开、关闭、落盘，都得你亲手控：
- 必须检查
os.Open和os.Create的返回错误，不能只看io.Copy的结果 - 复制完成后必须显式调用
dst.Close()—— 否则内核可能还缓着数据，stat看大小对，但实际没写入磁盘 - 如需强落盘保证（比如关键日志、配置文件），在
dst.Close()前加dst.Sync()（注意：仅对支持 fsync 的*os.File有效）
io.CopyBuffer 能解决什么实际问题
默认 32KB 缓冲在多数场景够用，但遇到特定瓶颈时，换 io.CopyBuffer 是最轻量的优化手段：
- 大文件 + NFS 或 CIFS 共享存储：系统页缓存效率低，加大缓冲（如
make([]byte, 1）可显著减少 syscall 次数 - 小块高频写（如日志聚合到 socket）：减小缓冲（如
make([]byte, 4096)）降低延迟，避免攒太久才发 - 内存受限环境（嵌入式/Serverless）：缓冲太大可能 OOM，主动控制上限比依赖默认更可靠
- 注意：
io.CopyBuffer第三个参数不能为nil，传空切片会 panic；且缓冲区生命周期由调用方管理，别复用给多个并发CopyBuffer
跨设备移动文件时，为什么 os.Rename 失败后不能直接 Copy
因为 os.Rename 在 Linux/macOS 上本质是 rename(2) 系统调用，仅支持同文件系统内原子重命名；跨挂载点（比如 /home → /mnt/usb）会返回 syscall.EXDEV 错误。
立即学习“go语言免费学习笔记（深入）”；
此时退化为「复制 + 删除」流程，但顺序和时机很关键：
- 必须等
io.Copy返回成功、且dst.Close()完成后，才能调用os.Remove(src) - Windows 下若目标文件还没 Close，
os.Remove会报The process cannot access the file - 删除前建议再
os.Stat(dst)核对大小，防止因磁盘满等导致io.Copy返回部分成功（written > 0, err != nil）
io.Copy 本身，而在于它太老实——它不会替你做任何假设，也不会掩盖任何异常。你传进去的是什么状态的 Reader 和 Writer，它就按那个状态跑完全程。漏掉一次 Close，就可能泄露 fd；忽略一个 err，就可能让截断的数据静默落地。 
