os.stat 与文件读取不能直接拼凑可靠缓存，因存在三坑：modtime精度不足（如nfs秒级）、符号/硬链接导致行为不一致、检查与读取非原子致竞态；应改用 inode+dev（linux/macos）或 fileid（windows）作唯一标识，或轻量哈希内容，并用带lru驱逐的结构体管理缓存。
为什么 os.Stat 和文件读取不能直接拼凑出可靠缓存
直接用 os.Stat 检查修改时间再决定是否读文件，看似简单，但会踩三个坑：一是 NFS 或某些容器挂载场景下 os.Stat 返回的 ModTime() 精度可能只有秒级，导致 1 秒内多次更新被忽略；二是硬链接和符号链接会让 os.Stat 和 os.Lstat 行为不一致，缓存可能误判源文件变更；三是没有原子性——检查完、读取前文件可能已被删或重命名，触发 no such file 错误。
所以必须把「检查 + 读取」合并为一次系统调用级别的原子操作，或者用更稳定的标识代替时间戳。
- 优先用文件的
inode+dev组合（Linux/macOS）或FileID（Windows）做唯一标识，比ModTime()更可靠 - 若需跨平台且不依赖 syscall，可退而求其次：对文件内容做轻量哈希（如
xxhash.Sum64），只在首次读或缓存失效时计算 - 避免在每次 Get 时都调用
os.Stat—— 把元数据缓存起来，和内容一起存，读缓存时直接比对
用 sync.Map 还是带驱逐策略的结构体
sync.Map 适合高并发读、低频写的场景，但它不支持自动过期或内存限制，本地文件缓存往往需要控制总大小或按 LRU 踢出旧项。硬塞 sync.Map 容易让缓存无限增长，最终吃光内存。
更务实的做法是封装一个结构体，内部用 map[string]*cacheEntry + sync.RWMutex，再加一个简单的 LRU 链表（用 list.List）管理访问顺序。不需要引入完整 Go cache 库（如 gocache），因为文件缓存的 key 是路径字符串，value 是字节切片或结构体，没必要泛型化。
- key 用绝对路径（
filepath.Abs处理一次，避免软链导致重复缓存） - value 中至少包含：
data []byte、inode uint64（Linux/macOS）、size int64、accessedAt time.Time - 每次
Get时更新accessedAt并移动到 LRU 表头；Set时检查总 size，超限时从尾部逐个删除
如何安全地检测文件是否变更
最稳妥的方式不是监听，而是每次读缓存前做一次「轻量验证」：打开文件（os.OpenFile(path, os.O_RDONLY, 0)），然后 f.Stat()，再对比 inode/dev 和之前缓存的值。这个过程比读全部内容快得多，且能规避权限变化、删除后重建等边界情况。
注意不要用 os.Open 后忘记 Close，否则在 Linux 上可能快速耗尽文件描述符。建议用 defer f.Close() 包裹验证逻辑，或直接用 os.Stat（它不打开文件，但无法获取 inode —— 所以仍需 Open + Stat 组合）。
- Windows 下用
syscall.GetFileInformationByHandle取FileIndexLow/High替代 inode - 如果业务允许「最多 N 秒延迟感知变更」，可以加一个
staleDuration time.Duration字段，在Get时跳过验证（节省 syscall 开销） - 永远不要信任
os.SameFile的结果来判断缓存有效性——它只比 path，不比实际内容或 inode
要不要支持内存映射（mmap）读大文件
对 >10MB 的文件，用 os.ReadFile 会一次性分配等长内存，GC 压力大；而 mmap（Go 中通过 golang.org/x/sys/unix.Mmap）能按需页加载，降低峰值内存。但代价是：Windows 支持弱（syscall.CreateFileMapping 封装复杂）、无法跨平台统一 API、且 mmap 区域在 GC 不感知，容易被误认为内存泄漏。
除非明确知道缓存的大文件会被随机访问（比如日志检索、二进制解析），否则不值得引入 mmap。更通用的解法是：缓存里只存 *os.File 句柄 + offset/length，配合 io.ReadAt 按需读块——这样既省内存，又保持跨平台。
- 缓存 value 类型可定义为
interface{ ReadAt([]byte, int64) (int, error) }，底层是*os.File或bytes.Reader - 小文件走内存缓存（
[]byte），大文件走句柄缓存（*os.File），由大小阈值自动切换 - 务必在
Set时记录文件是否已打开，并在缓存淘汰时Close()，否则 fd 泄漏比内存泄漏更快出问题
