bytes.reader 不能直接当 os.file 用，因其仅实现 io.reader 和受限 io.seeker（不支持写、负偏移越界会 panic），而 os.file 实现完整 io.readwriteseeker；archive/zip 等库依赖随机读写，seek 越界导致错误或 eof。
为什么 bytes.Reader 不能直接当 os.File 用
因为 os.File 实现了完整的 io.ReadWriteSeeker 接口，而 bytes.Reader 只实现了 io.Reader 和有限的 io.Seeker（不支持写、不支持负偏移重定位到未读区域之外）。很多依赖随机读写的库（比如 archive/zip、image/jpeg 解码器）会调用 Seek(0, io.SeekStart) 或反复跳转，这时 bytes.Reader 会 panic 或返回错误。
-
bytes.Reader的Seek只允许在当前已读范围或末尾偏移，超出就返回ErrInvalidSeek - 需要完整虚拟文件语义时，得自己补全
ReadAt、WriteAt、Stat等行为，不能只靠bytes包 - 常见报错：
seeker not supported、invalid argument（来自 syscall）、unexpected EOF（因 seek 失败后 read 位置错乱）
用 bytes.Buffer 模拟可读写文件要绕开哪些坑
bytes.Buffer 天然支持读写和 seek，但默认不暴露 io.ReadWriteSeeker 接口——它实现的是 io.ReadWriter，Seek 方法是额外提供的。直接传给期望 io.ReadWriteSeeker 的函数会编译失败。
- 必须显式转换：
interface{}转成io.ReadWriteSeeker，例如io.ReadWriteSeeker(&buf)（注意取地址） -
bytes.Buffer的Seek支持负偏移，但若 seek 到负位置且后续Read，会 panic；安全做法是先buf.Len()校验范围 - 写入后未
buf.Reset()就重复使用，容易残留旧数据；建议每次 new 一个新bytes.Buffer，或明确buf.Truncate(0) - 性能上，
bytes.Buffer底层是切片扩容，频繁写小数据会有内存抖动；大文件模拟建议预估大小并buf.Grow(n)
真正需要“虚拟文件系统”时，别硬套 bytes 包
如果项目里要支持多文件、目录结构、权限、mtime、open/close 生命周期管理，bytes.Buffer 或 bytes.Reader 就只是个字节容器，不是文件系统。这时候该用轻量封装，而不是自己造 os.File 子类。
- 推荐用
github.com/spf13/afero：提供afero.MemMapFs，完整实现fs.FS和fs.File，支持Open、ReadDir、Stat、Remove - Go 1.16+ 原生
io/fs接口不能直接写，但afero已兼容；自定义fs.FS时，Open返回的fs.File可以包装*bytes.Buffer - 不要试图让单个
bytes.Buffer表示整个 FS——每个路径对应独立 buffer，用 map[string]*bytes.Buffer 管理，否则并发读写会出问题 - 注意
afero.MemMapFs默认不校验路径合法性（如../etc/passwd），生产环境需加白名单或用afero.WhitelistFs
调试时怎么快速确认虚拟文件行为是否符合预期
最直接的办法是把它塞进原本跑真实文件的逻辑里，然后观察 panic 位置和 error 类型。别靠猜，用最小可复现路径验证。
立即学习“go语言免费学习笔记（深入）”；
- 检查是否实现了所需接口：
var _ io.ReadWriteSeeker = (*bytes.Buffer)(nil)编译期断言 - 测试 seek 边界：
buf := bytes.NewBufferString("hello"); buf.Seek(10, io.SeekStart)—— 应返回 error，不是静默失败 - 对 zip 解压等场景，先用
os.Open跑通，再把同内容换成afero.NewMemMapFs().OpenFile(...)，对比 error 是否一致 - 注意 time 相关字段：内存文件系统通常返回零值
time.Time，某些工具（如archive/zip）会据此设默认 modtime，影响校验和
虚拟文件最难的从来不是读写字节，而是时间、权限、路径解析、并发安全这些隐性契约。哪怕只用一个 bytes.Buffer，也要想清楚它到底在替谁说话。
