直接用sync.Map做文件内容缓存简单有效，但必须加TTL或手动清理，否则内存无限增长；因os.ReadFile每次触发系统调用和磁盘I/O，高频读小文件时性能损耗显著，缓存核心是避免重复I/O。
直接用 sync.Map 做文件内容缓存，简单有效；但必须加 TTL 或手动清理，否则内存会无限增长。
为什么不用 os.ReadFile 反复读？
每次调用 os.ReadFile 都触发一次系统调用 + 磁盘 I/O，对配置文件、模板、静态资源这类高频小文件，性能损耗明显。尤其在并发请求下，磁盘成为瓶颈。缓存的核心目标不是“省代码”，是避免重复 I/O。
- 典型场景：Web 服务启动后反复读取
config.yaml或templates/*.html - 风险点：不加控制的缓存会导致内存持续上涨，服务运行数天后 OOM
- 注意：
os.ReadFile返回的是新分配的[]byte，即使内容相同，也不等于可复用 —— 必须显式缓存
sync.Map 缓存实现与过期判断
sync.Map 适合读多写少的并发场景，但本身不支持过期，需自行封装结构体。不要把过期逻辑塞进 Load 后再判断 —— 这样仍会返回已过期数据。
- 正确做法：读取时先
Load，检查是否过期；若过期，Delete后重新Store - 示例结构：
type cachedFile struct { data []byte; expiry time.Time } - 避免用
time.Now().Before(c.expiry)判断 —— 推荐用c.expiry.After(time.Now())，语义更清晰且避免时区陷阱 - 不要在
Store前做os.Stat检查文件修改时间 —— 这又引入一次 I/O，违背缓存初衷
大文件或动态内容要不要缓存？
缓存不是万能的，要按文件类型分策略，否则得不偿失。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 配置类（
app.conf）、模板类（index.html）：可设长 TTL（如 5 分钟），并暴露ClearCache方法供热重载调用 - 日志、监控输出等动态文件：不缓存，或只缓存最近 N 行（用
bufio.Scanner+ ring buffer 实现） - 超大文件（>100MB）：不全量缓存，改用
mmap或分块缓存热点 offset，避免内存爆炸 - 注意权限变更：文件被
chmod或chown后，缓存内容可能仍可读，但后续os.ReadFile会失败 —— 需捕获os.IsPermission并主动Delete对应 key
第三方库选 golang-lru 还是 go-cache？
如果项目已依赖 golang-lru，优先用它的 expirable.NewLRU；若需要自动清理 + 简单 API，go-cache 更轻量。
-
golang-lru/expirable：支持 TTL，但不自动 GC —— 过期项只在Get时惰性清理，内存占用可能虚高 -
go-cache：自带定时清理 goroutine，但默认每秒扫描，对低频服务略冗余 - 共通坑：两者都不监听文件系统事件，文件内容更新后缓存不会自动失效 —— 必须靠 TTL 或手动触发刷新
- 别为“高级算法”过早优化：95% 场景用 LRU 就够了，ARC/2Q 带来的是复杂度，不是性能提升
真正容易被忽略的点是：缓存键的设计。用绝对路径作 key 看似合理，但一旦涉及符号链接、挂载点迁移或容器内路径映射，就会导致同一文件被多次缓存。更稳妥的做法是用 filepath.EvalSymlinks + os.Stat().Sys().(*syscall.Stat_t).Ino 构造唯一 inode key —— 但这增加了 syscall 开销，需权衡。
