File.GetLastWriteTime() 和 File.GetCreationTime() 是获取文件时间戳最简单的方式，返回 DateTime 类型，需确保路径存在且有读取权限；底层调用 Windows API，在 NTFS 上准确，FAT32 或网络共享中 CreationTime 可能不可靠；推荐使用 UTC 版本避免时区问题。
File.GetLastWriteTime() 和 File.GetCreationTime() 最常用
直接调用 File.GetLastWriteTime() 和 File.GetCreationTime() 是获取文件时间戳最简单的方式，它们返回 DateTime 类型，支持时区转换和格式化输出。
- 必须确保传入的路径存在且有读取权限，否则抛出
FileNotFoundException或UnauthorizedAccessException - 这两个方法底层调用 Windows API，对 NTFS 卷准确；在 FAT32 或网络共享上，
CreationTime可能不可靠（实际是写入时间） - 如果只需判断是否“比某个时间新”，建议用
DateTime.Compare()或直接比较运算符，避免 ToString() 再解析
FileInfo 类更适合多次访问同一文件
当需要同时读取修改时间、创建时间、访问时间或文件大小时，用 FileInfo 实例更高效——它只做一次系统调用，缓存所有属性。
- 构造
FileInfo对象不触发 IO，真正读取时间属性（如fileInfo.LastWriteTime）时才访问磁盘 -
FileInfo的LastAccessTime在 Windows 10 1803+ 默认禁用，需手动开启才能保证更新 - 注意
FileInfo不会自动刷新缓存，若文件被外部程序修改，再次访问属性仍返回旧值；必要时可新建实例或调用Refresh()
处理时区与 UTC 时间
默认返回的是本地时区时间（DateTimeKind.Local），跨系统或日志记录时容易出错。推荐统一用 UTC：
- 改用
File.GetLastWriteTimeUtc()和File.GetCreationTimeUtc() - 或对
FileInfo属性调用.ToUniversalTime()，但要注意：如果原始值已是 UTC，再转会重复偏移 - 检查
DateTime.Kind值比硬编码转换更安全，尤其在混合环境（如 Docker 容器时区未同步）下
常见错误：路径不存在、权限不足、符号链接陷阱
看似简单的调用，实际运行时最容易卡在三类问题上：
-
DirectoryNotFoundException：路径中某级目录不存在，不是文件本身不存在——先用File.Exists()或new FileInfo(path).Exists校验 -
UnauthorizedAccessException：常见于系统目录（如C:\Windows）或加密文件，.NET 6+ 可捕获后降级为跳过，而非崩溃 - 符号链接（symlink）：
File.GetLastWriteTime()返回链接本身的修改时间，不是目标文件；要用File.GetLastWriteTime(new FileInfo(path).ResolveLinkTarget(false).FullName)获取目标时间
时间戳精度取决于文件系统：NTFS 是 100 纳秒，FAT32 是 2 秒——别拿它做毫秒级并发控制。
