go语言中无法直接设置文件ctime（创建时间），仅能通过os.chtimes修改atime和mtime；ctime由系统自动更新，任何元数据变更（包括调用os.chtimes）均会触发其变化，但不可主动赋值。
Go 语言中不能直接更新文件的“创建时间”（ctime），只能通过 os.Chtimes 设置 atime 和 mtime；ctime 是系统自动维护的元数据变更时间，任何属性修改（包括调用 os.Chtimes）都会触发它更新，但你无法主动赋值。
用 os.Chtimes 更新 mtime 和 atime
这是标准库唯一支持的时间戳写入方式，跨平台可用，但行为有隐含限制：
-
os.Chtimes接收两个time.Time参数：第一个是访问时间（atime），第二个是修改时间（mtime） - 若传入
time.Time{}（零值），对应时间戳保持不变 —— 但注意：在某些旧版 Linux 内核或 NFS 上，零值可能被解释为 Unix epoch 而意外覆盖 - Windows 下 atime 默认禁用（挂载选项
noatime类似行为），调用后可能不生效，os.Chtimes不会报错，需额外验证 - 示例：只更新 mtime，保留 atime 不变
fi, _ := os.Stat("data.txt")
atime := fi.ModTime() // 先读出现有 atime（注意：这不是原子操作，可能已过期）
mtime := time.Now()
os.Chtimes("data.txt", atime, mtime)
为什么不能设置 ctime？
ctime（change time）不是文件内容或用户可设属性，而是 inode 元数据最后一次变更的系统记账时间。只要发生以下任一操作，ctime 就会自动更新：
- 修改文件内容（触发 mtime + ctime）
- 更改权限、所有者、扩展属性（触发 ctime）
- 调用
os.Chtimes（即使只改 mtime，也属于元数据操作，触发 ctime） - 重命名、硬链接、软链接目标变更等
Go 标准库没有提供任何接口写入 ctime，syscall 层面也无对应系统调用（Linux utimensat 不接受 ctime 参数）。试图绕过标准库强写，不仅无效，还可能因平台差异导致 panic 或静默失败。
跨平台时间精度差异必须考虑
不同文件系统对时间戳的存储精度不同，直接影响你能否“精确还原”或“可靠比较”：
- ext4 / XFS：支持纳秒级 mtime/atime，但
os.Chtimes实际写入精度取决于内核和挂载选项 - NTFS（Windows）：mtime/atime 精度通常为 100ns，但 Go 的
time.Now()在 Windows 上默认只到毫秒级，需用syscall.GetSystemTimeAsFileTime补足 - NFSv3：普遍只支持秒级，多次调用
os.Chtimes可能全部落到同一秒，导致看似“没更新” - 别用
==比较两个ModTime()结果；用t1.After(t2.Add(-2 * time.Second))这类带容差的方式判断“是否更新”更稳妥
获取时间戳时别误用 os.Lstat 和 os.Stat
两者返回的 FileInfo 对象，其 ModTime() 指向的目标不同：
-
os.Stat("link")→ 返回链接指向的目标文件的 mtime（跟随符号链接） -
os.Lstat("link")→ 返回链接文件自身的 mtime（不跟随，即链接元数据的修改时间） - 如果你要批量统一重置某目录下所有条目的 mtime（含符号链接本身），必须用
os.Lstat+os.Chtimes组合，否则链接会被跳过，实际改的是目标文件 - Windows 上符号链接行为与 Unix 不同，
os.Lstat可能返回与os.Stat相同结果，需实测验证
真正麻烦的从来不是“怎么写”，而是“写完之后，别人（或自己一周后）再读这个时间戳时，它到底代表什么”。mtime 的语义清晰，但 atime 易受系统策略干扰，ctime 根本不可控 —— 所以除非业务强依赖，否则别把逻辑锚定在 atime/ctime 上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
