os.ReadFile会一次性加载整个文件致OOM，正确做法是os.Open+io.ReadFull按需读块；必须Seek定位再ReadFull，缓冲区≤剩余长度，并用{path}:{offset}为key做块级缓存。
os.ReadFile 会一次性把整个文件加载进内存，对大文件来说不是“碎片化管理”，而是制造内存碎片——这不是在解决碎片问题，是在触发 GC 压力和 runtime: out of memory。
真正的文件碎片化管理，核心是按需加载、块级隔离、元数据分离。它不追求“把文件切开存”，而是让每次访问只触达真正需要的那部分数据。
os.Open + io.ReadFull 是读取指定块的唯一安全组合
常见错误是用 io.Read 替代 io.ReadFull，导致末尾块读不满、数据截断却无报错。
-
io.ReadFull要求必须填满缓冲区，读不满就返回io.ErrUnexpectedEOF，能及时暴露边界越界问题 - 必须先
f.Seek(offset, 0)，再调io.ReadFull；跳过 Seek 直接 Read 会从开头读起 - 缓冲区大小（
size）必须 ≤ 文件剩余长度，否则ReadFull必然失败 - 每次读块前应校验：
if offset+size > fileInfo.Size() { return nil, errors.New("out of range") }
示例关键片段：
立即学习“go语言免费学习笔记（深入）”；
func readBlock(filename string, offset, size int64) ([]byte, error) {
f, err := os.Open(filename)
if err != nil {
return nil, err
}
defer f.Close()
<pre class="brush:php;toolbar:false;">if _, err := f.Seek(offset, 0); err != nil {
return nil, err
}
buf := make([]byte, size)
if _, err := io.ReadFull(f, buf); err != nil {
return nil, err
}
return buf, nil}
sync.Map 是块级缓存的合理选择，但 key 设计不能错
用整个文件路径当 key（如 "log.txt"）会导致所有块共享一个缓存项，无法局部失效、无法支持 Range 请求。
- 正确 key 格式是
"{filepath}:{offset}"，例如"/var/log/app.log:2097152" - value 存结构体：
struct{ data []byte; mtime time.Time; etag [32]byte }，不能只存[]byte - 写入用
Store，读取用Load，首次加载用LoadOrStore避免重复读盘 - 不要用
map[string]interface{}+sync.RWMutex，写竞争高，且 Go 1.23 后sync.Map性能已足够稳定
注意：sync.Map 的 key 和 value 都不能是 interface{} 类型的泛型容器，否则 runtime 无法做类型特化，性能反降。
分片写入必须用 io.SectionReader 或 io.LimitReader，禁用 bytes.Split
bytes.Split 要求先把整文件 load 进内存，完全违背碎片化初衷。
- 大文件分片上传/存储时，用
os.Open打开源文件，再为每个分片构造io.SectionReader：sr := io.NewSectionReader(f, offset, size) - 然后直接
io.Copy(dstFile, sr)，全程零拷贝、内存恒定（仅 buffer 大小） - 分片大小建议设为
4 <em> 1024 </em> 1024（4MB）：太小增加 I/O 次数，太大仍可能卡 GC - 别在循环里反复
os.OpenFile(..., os.O_CREATE)，先批量创建好所有目标文件句柄再写，避免too many open files
块级缓存的真正难点不在读写逻辑，而在于 mtime 和 etag 的一致性维护：源文件更新后，旧块若没被主动淘汰，就会提供脏数据。这要求每次读块前检查元数据是否过期，而不是依赖 TTL 简单清理。
