io.pipe不适合直接用于文件传输，因其无缓冲、无背压、一端阻塞即整链死锁；可靠方案应使用带缓冲channel（如make(chan []byte, 16)）配合goroutine、os.open和io.copy实现可控分块传输。
io.Pipe 不适合直接用于文件数据传输——它无缓冲、无背压、一端阻塞整条链，极易死锁。真要高效传文件，得用带缓冲的 chan []byte + 显式 goroutine 控制。
什么时候该用 io.Pipe，什么时候必须避开
它只在两类场景下安全：写端和读端无法同步启动（比如异步日志生成器往 http.ResponseWriter 写），或必须满足 io.Reader/io.Writer 接口契约（如喂给只接受 io.Reader 的 JSON 解析库）。但凡涉及文件读写、流式转换、分块处理，io.Pipe 就是陷阱：
- 写端调用
w.Write时，若读端还没开始Read，会永久阻塞 - 没有容量概念，不是队列，不能暂存数据
- 写端 panic 后没
Close，读端永远卡在Read - 错误传播弱，下游很难及时感知上游失败
用 chan []byte 做可控分块传输
把文件按固定大小切片（如 4KB），通过带缓冲 channel 中转，下游按需消费。关键点：
- 缓冲大小设为
make(chan []byte, 16)（约 64KB），避免内存暴涨又不至于太小导致频繁阻塞 - 每次
file.Read(buf)后必须copy(data, buf[:n])拷贝出新 slice——否则多个 goroutine 可能改同一底层数组 - 读端 goroutine 必须
defer close(ch)，否则range ch会永远等待 - 判断 EOF 要看
n == 0 && err == nil，不能只依赖err != nil
管道输入（stdin）和命令行参数共存时怎么读
Go 不自动区分「用户想从管道读」还是「想读文件路径参数」，必须自己定义逻辑。最可靠策略是：
- 只要
os.Stdin可读（哪怕只读到 EOF），就以管道输入为主，忽略所有文件路径参数 - 仅当
os.Stdin立即返回 EOF（即没数据），才 fallback 到os.Args[1]或 flag 指定的文件 - 别用
os.Stdin.Stat().Mode() & os.ModeNamedPipe != 0判断——CI 环境、IDE 终端常误报，且上游提前关闭时Stat()可能 panic
大块二进制输入别用 bufio.Scanner
bufio.Scanner 是为按行文本设计的，默认单行上限 64KB，且会剥离 \n/\r\n。遇到 JSON blob、base64、tar 流等原始字节流，它反而会截断或解析错：
- 改用
io.ReadAll(os.Stdin)，一次性读完全部字节，返回[]byte和error - 注意：若上游不关闭写端（如长连接未结束），
ReadAll会永久阻塞 - 文本行处理仍首选
bufio.Scanner，但务必检查scanner.Err()——上游中断或编码错误不会自动暴露
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
