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