go文件缓存需分内存层（map+sync.rwmutex）和http层（etag/cache-control）双层协同，小文件适用内存缓存并配过期清理，大文件应跳过内存层仅用http缓存减载，且须动态生成etag、显式失效、正确设置响应头以保障一致性与有效性。
直接用内存缓存 + HTTP 缓存双层策略，能显著降低磁盘 I/O 和网络带宽消耗，但必须按文件规模、更新频率和一致性要求分层选型，不能一刀切。
小文件（sync.Map + 定时清理
中小规模静态资源（如 JSON Schema、SVG 图标、配置模板）适合走纯内存缓存。用 sync.Map 虽简单，但要注意它不带过期机制，也不能自动淘汰旧条目。
- 每次
Store都会把 key 写入 dirty map，频繁增删会导致内存持续增长，GC 压力变大 - 别用它缓存上万条路径——数量一多，
Range扫描开销明显，且已删除的 key 仍占内存 - 真正需要 TTL 的场景，改用
github.com/bluele/gcache：初始化必须调Build()，否则Get()直接 panic -
ExpireIn(5 * time.Minute)中传负数（比如 -1），会被当作“永不过期”，不是报错，容易漏查
大文件（>10MB）禁止全量缓存，改用分块 + http.ServeFile 透传
把整份视频或日志文件读进内存，既浪费 RAM，又拖慢 GC，还可能触发 OOM。这类文件应跳过内存层，只靠 HTTP 协议级缓存减载。
-
http.ServeFile默认不设Cache-Control或ETag，客户端每次都会重拉全文本 - 用自定义
http.FileSystem包裹原路径，在Open()返回前手动写头：w.Header().Set("Cache-Control", "public, max-age=3600") -
ETag必须动态算：若文件可能被外部进程修改（如日志轮转），就不能硬编码哈希值，得用md5.Sum(fileBytes)或os.Stat().ModTime().UnixNano() - 配合
Range请求支持断点续传，避免客户端反复请求完整大文件
文件被外部修改时，内存缓存必须主动失效
Go 进程不监听 fs 事件，os.Stat() 只能拍快照。一旦配置文件被运维手动覆盖、日志被 logrotate 切走，内存里缓存的内容就彻底 stale。
- 没有通用方案能自动感知变更——inotify 在容器里常不可用，k8s hostPath 也不保证事件传递
- 最稳妥的做法是：所有写操作（如上传接口、配置热更）完成后，显式调
fileCache.Delete(filename) - 对关键配置文件，可加一层“版本号”字段，每次更新时 bump 版本并清缓存，比依赖文件时间戳更可靠
- 别指望靠定期全量扫描
os.Stat()对比 mtime 来清理——I/O 开销大，且无法区分“内容未变但 mtime 更新”的假变更
HTTP 缓存头设置不当，会让内存缓存白忙活
即使你把文件内容高速返回了，如果响应头没配对，浏览器/CDN 仍会反复请求，服务端缓存再快也没意义。
-
Cache-Control: no-cache≠ 不缓存，它只是强制每次校验，仍会发If-None-Match请求，浪费一次 RTT - 要真禁用缓存，得写
Cache-Control: no-store；要允许复用，至少设public, max-age=300 -
Last-Modified比ETag粗粒度：同一秒内多次修改，mtime 不变，就会误判为未变 - 如果文件内容不变但路径变了（如 versioned URL），
ETag值也该跟着变，否则 CDN 可能混用旧内容
缓存不是加个 map 就完事——文件是否可缓存、缓存多久、谁来负责失效，这些决策点都藏在业务逻辑里，而不是标准库函数签名中。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
