Go标准库不提供跨平台atime获取能力，os.FileInfo.ModTime()返回的是修改时间而非访问时间；需通过syscall.Stat_t（Unix）或syscall.Win32FileAttributeData（Windows）平台特异性获取，且atime常被禁用或不可靠。
Go 标准库不提供跨平台的文件最后访问时间（atime）获取能力，必须依赖 syscall 包做平台特定断言，且 Linux/macOS 可行、Windows 需另用 syscall.Win32FileAttributeData，但实际中 atime 常被禁用或延迟更新 —— 直接调用 os.FileInfo.ModTime() 并不能得到访问时间。
为什么 os.FileInfo.ModTime() 不是最后访问时间
ModTime() 返回的是修改时间（mtime），不是访问时间（atime）。这是最常踩的坑：把函数名里的 “Mod” 当成泛指“最近一次操作”，结果逻辑出错。
常见错误现象：
- 代码里写
finfo.ModTime()却期望它反映文件被cat或open()读取的时间 - 在 ext4 文件系统上启用了
noatime挂载选项（默认行为），此时即使文件被读取，atime也不会更新 - macOS 上部分 APFS 卷对 atime 的支持不稳定，
Atim字段可能为零值
Linux/macOS 下用 syscall.Stat_t 提取 Atim
Unix-like 系统中，os.FileInfo.Sys() 返回的是 *syscall.Stat_t，其 Atim 字段才是真正的访问时间戳。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 必须用
time.Unix(stat.Atim.Sec, stat.Atim.Nsec)构造time.Time，不能只用秒数（否则丢失纳秒精度） - 类型断言失败不等于文件不存在，可能是运行在非 Unix 系统，或 Go 版本较新导致底层结构变更（如 Go 1.20+ 在某些构建下返回
syscall.Statx_t） - 记得检查
err：如果os.Stat()失败，后续断言无意义 - 示例片段：
info, err := os.Stat("data.log")
if err != nil {
log.Fatal(err)
}
if stat, ok := info.Sys().(*syscall.Stat_t); ok {
atime := time.Unix(stat.Atim.Sec, stat.Atim.Nsec)
fmt.Printf("Accessed at: %v\n", atime)
} else {
fmt.Println("Not on Unix-like system, or unsupported file info type")
}
Windows 下要换用 syscall.Win32FileAttributeData
Windows 没有 syscall.Stat_t，而是通过 os.FileInfo.Sys() 返回 *syscall.Win32FileAttributeData，其中 LastAccessTime 是 64 位 FILETIME（100 纳秒单位，自 1601-01-01 起）。
关键差异：
- FILETIME 需转为 Unix 时间戳再喂给
time.Unix()，不能直接传LastAccessTime - Windows 的 atime 默认也禁用（受
lastaccess注册表策略控制），即使代码正确也可能返回旧值 - 跨平台代码需做
build tag分离，例如用//go:build windows和//go:build !windows - 别用
unsafe强转——Win32FileAttributeData是 struct，字段顺序和对齐在不同架构下不保证
atime 实际不可靠，优先考虑替代方案
文件系统级 atime 天然有缺陷：性能开销大、易被挂载选项屏蔽、用户可手动 touch 修改。生产环境慎用它做业务逻辑判断。
更可行的做法：
- 用
os.Chtimes()主动记录业务层“访问时间”到文件扩展属性（xattr）或单独元数据文件 - 监控日志（如 auditd 或 Windows Event Log）比依赖 atime 更准确
- 若只是想判断“是否近期活跃”，改用 mtime + 文件大小变化组合判断，稳定性高得多
- 注意：Go 的
os.Chtimes()能设 atime，但设完后立刻os.Stat()读回来仍可能因内核延迟未刷新 —— 不要设完就 assert 相等
真正难的从来不是怎么取 atime，而是搞清你到底需不需要它、以及系统是否真给了你一个有效的值。
