go 语言不支持对普通文件使用 select 实现多路复用，因其底层为阻塞式同步 i/o，不触发内核事件通知，而 select 仅支持 channel、timer 和网络 conn 等可被 runtime.netpoll 调度的对象。
Go 语言里没有“文件流多路复用”这个标准概念——io.MultiWriter 是顺序分发，不是多路复用；select 对文件 *os.File 无效，不能监听文件就绪事件。
为什么不能对普通文件用 select 做多路复用
Linux 下普通文件（如 /tmp/log.txt）的读写是阻塞式同步 I/O，不触发内核事件通知。Go 的 select 只能监听 channel、timer、网络 conn 等可被 runtime.netpoll 调度的对象，*os.File.Read() 会直接挂起 goroutine 并抢占 M，无法被 select 捕获就绪状态。
- 尝试在
select中写case n, _ := → 编译报错：<code>cannot use file.Read(buf) (value of type (int, error)) as channel - 哪怕设成非阻塞（
syscall.FcntlInt(uintptr(fd), syscall.F_SETFL, syscall.O_NONBLOCK)），Go 标准库也不暴露底层 fd，且os.File未封装为可调度对象 - 真正支持
select的只有net.Conn、chan、time.Timer.C这类 runtime 显式管理的资源
文件分发场景下常被误称的“多路复用”其实是顺序分发
所谓“把一份日志同时写入文件 + 控制台 + 网络”，实际靠的是 io.MultiWriter，它只是把一次 Write() 调用按参数顺序逐个转发给每个 io.Writer，不并发、不并行、不等待、不协调。
- 写入顺序固定：第一个
io.Writer（比如os.Stdout）成功后，才调第二个（比如os.File），任一失败立刻返回错误，前面成功的不会回滚 - 性能陷阱：本地磁盘快、网络慢，若把
http.Client放在io.MultiWriter参数前列，容易卡住整个写入流程 - 无超时控制：某个
Writer卡住（如慢速 HTTP 日志服务），整个Write()就卡死，io.MultiWriter不提供 context 或 deadline 接口
真要实现带容错/并发/超时的文件分发，得自己编排
如果目标是“一份数据，安全写入多个目标”，必须放弃 io.MultiWriter，改用显式 goroutine + channel + context 控制：
- 每个目标独立启动 goroutine：
go func(w io.Writer) { _, _ = w.Write(data) }(target) - 用
sync.WaitGroup等待全部完成，或用context.WithTimeout统一中断 - 结果聚合进
chan error，最后检查是否全部nil；任一失败可选择重试或标记告警 - 注意
*os.File本身不是线程安全的，多个 goroutine 同时写同一文件需加sync.Mutex
大文件分发时的“多路”其实是 Range + HTTP/1.1 分块
浏览器拖拽视频、断点续传 ZIP，依赖的是 HTTP 的 Range 请求能力，不是 Go 层面的多路复用。关键在 handler 是否让 http.ServeContent 能拿到真实 *os.File 句柄并支持 ReadAt：
- 不能用
bytes.Buffer或加密 reader 替代文件句柄，否则http.ServeContent无法响应Range请求 - 必须用
os.Open打开文件，不能用os.ReadFile加载到内存 - 路径校验要用
filepath.Clean+ 白名单前缀，防止../遍历漏洞
文件分发系统里最易被忽略的不是并发模型，而是响应头——缺 ETag、Last-Modified 或多出 Set-Cookie，CDN 就直接回源，再快的 Go 也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
