Windows 默认禁用上次访问时间更新，File.GetLastAccessTime 返回值常过时；需用 fsutil 启用且注意 NTFS 延迟写入；FileInfo 缓存时间戳，File 静态方法实时读取；跨平台时 Linux/macOS 支持更弱，应避免依赖该值做业务判断。
File.GetLastAccessTime 返回的时间不准？
windows 默认禁用上次访问时间更新，file.getlastaccesstime 很可能返回一个过时甚至完全没变过的值——不是代码写错了，是系统关掉了这个功能。
验证方法：在命令行运行 fsutil behavior query disablelastaccess，如果输出是 disablelastaccess = 1，就确认被禁用了。
- 启用它需要管理员权限：运行
fsutil behavior set disablelastaccess 0 - 启用后需重启资源管理器或整个系统，部分 NTFS 卷才开始记录
- 即使启用，NTFS 也会延迟写入（最多 1 小时），所以刚打开文件未必立刻反映在
GetLastAccessTime中 - 某些杀毒软件、备份工具或 PowerShell 的
Get-Item操作也可能触发访问时间更新，造成干扰
C# 中该用 FileInfo 还是 File 静态方法？
两者都可用，但行为有关键差异：FileInfo 实例会缓存首次访问时的元数据（包括时间戳），后续调用 LastAccessTime 属性不会重新读取磁盘；而 File.GetLastAccessTime 每次都查文件系统。
- 如果文件可能被其他进程修改，又需要最新访问时间，优先用
File.GetLastAccessTime - 如果反复读取同一文件且对时效性要求不高，
FileInfo略轻量（避免重复 P/Invoke） -
FileInfo构造函数本身不抛异常，但访问LastAccessTime属性时仍可能因权限/路径问题抛UnauthorizedAccessException或FileNotFoundException
示例对比：
var path = @"C:\test.txt"; // 每次都查磁盘 DateTime t1 = File.GetLastAccessTime(path); <p>// 缓存首次获取的值 var info = new FileInfo(path); DateTime t2 = info.LastAccessTime; // 不保证是“当前”时间
跨平台（.NET 6+）下 LastAccessTime 的可靠性
Linux/macOS 文件系统（ext4、APFS）默认不维护精确的访问时间，或仅提供秒级精度，且常被挂载选项（如 noatime）彻底禁用。.NET 的 File.GetLastAccessTime 在这些系统上可能返回 Unix epoch（1970-01-01）或抛 PlatformNotSupportedException。
- 检查运行时：用
OperatingSystem.IsLinux()或OperatingSystem.IsMacOS()做兜底 - 不要依赖
LastAccessTime做业务逻辑判断（比如“用户最近是否看过这个文件”） - 若必须采集访问行为，改用应用层日志，或监听文件系统事件（
FileSystemWatcher，但注意它不捕获所有访问类型）
权限不足时拿不到时间戳，怎么安静失败？
没有读取文件属性权限时，File.GetLastAccessTime 直接抛 UnauthorizedAccessException，而不是返回 DateTime.MinValue。想避免异常中断流程，得手动捕获。
- 别用
try/catch包裹整个业务逻辑块——太重 - 封装一个安全读取函数，只 catch
UnauthorizedAccessException和FileNotFoundException - 返回
Nullable<datetime></datetime>（即DateTime?），让调用方决定缺省值
简写示例：
public static DateTime? SafeGetLastAccessTime(string path)
{
try { return File.GetLastAccessTime(path); }
catch (UnauthorizedAccessException) { return null; }
catch (FileNotFoundException) { return null; }
}.NET 的文件时间戳机制本身就有系统级妥协，尤其 LastAccessTime 是最不可靠的一个。真要追踪用户行为，别指望它。
