单用os.Stat()的ModTime不能可靠标识文件版本，因其非内容指纹；必须结合Size校验，或对静态资源、配置等强一致场景直接计算SHA256哈希。
os.Stat() 返回的 ModTime 不能单独用作文件版本标识——它不是内容指纹，误判率高。真要靠元数据做版本控制，必须搭配 Size 校验；若要求强一致（如静态资源、配置生效），就得直接算哈希。
为什么单用 ModTime 会出错
文件系统时间戳不是内容摘要，以下场景都会导致 ModTime 变但内容没变，或内容变了但 ModTime 没变：
-
touch命令更新时间戳，内容完全不变 → 误触发重加载 - NFS 或某些容器卷（如 Docker bind mount）中
ModTime精度退化为秒级 → 两次毫秒级写入可能产生相同时间戳，漏掉变更 - 文件被
rsync --inplace覆盖，内容已变但ModTime未更新 → 完全失效 - 权限重置（如
chmod）触发ModTime更新，但你并不关心权限是否变化 → 干扰版本判断逻辑
ModTime + Size 组合判断的实操要点
这是轻量且多数场景下足够可靠的折中方案，但要注意检查顺序和缓存结构：
- 缓存值应是结构体：
CachedMeta{ModTime time.Time, Size int64}，不能只缓存其中一个字段 - 判断逻辑必须是「两者都相等才跳过」：
!info.ModTime().Equal(meta.ModTime) || info.Size() != meta.Size - 缓存 key 用绝对路径，避免软链路径导致重复 stat（
filepath.EvalSymlinks应在缓存前完成） - 不要每次访问都调用
os.Stat()—— 用sync.Map缓存结果，key 是解析后的绝对路径 - 注意时区与纳秒精度：比较
ModTime用.Equal()，别用==，否则跨平台或 NFS 下易失败
什么时候必须放弃元数据，直读文件算哈希
以下情况不建议依赖任何文件系统元数据，必须打开文件、读取全部内容并计算 sha256：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 静态资源服务（CSS/JS/图片）：用户看到的版本必须 100% 对应内容，一个空格都不能错
- 配置文件驱动关键逻辑（如限流阈值、功能开关白名单）：不允许因文件系统行为导致状态漂移
- 部署流程使用
rsync --inplace或类似 in-place 覆盖方式：ModTime不变但内容已替换 - 文件可能被编辑器以“写新删旧”方式保存（如 vim 默认行为）：旧文件 inode 已删，新文件
ModTime是创建时间，和原内容无继承关系
软链接做版本切换的原子性保障
用 os.Symlink 实现多版本切换最轻量，但必须规避中间态风险：
立即学习“go语言免费学习笔记（深入）”；
- 切勿用
os.Rename覆盖软链——它在某些文件系统上非原子，可能短暂出现 broken link - 正确做法是两步：先
os.Remove("current")，再os.Symlink("config-v1.3.0.yaml", "current") - 读取前必须调用
filepath.EvalSymlinks("current")获取真实路径，否则os.Open或os.Stat可能 panic 或返回错误路径信息 - Windows 下普通用户无法创建符号链接，需启用开发者模式或改用
os.Link（硬链接，仅限同一文件系统） - 版本号推荐语义化格式（如
v1.3.0）或 ISO 时间戳（如20240520T143000Z），避免纯数字排序异常
