修改文件创建时间必须用 File.SetCreationTime，它调用 Win32 SetFileTime API；需写权限、路径有效且非目录；不支持跨平台，Linux/macOS 上静默无效。
修改文件创建时间要用 File.SetCreationTime，不是改文件名或复制
很多人试过重命名、移动再移回，或者用资源管理器“属性”里点来点去，发现创建时间纹丝不动——因为 Windows 的创建时间（CreationTime）是内核级元数据，必须用 API 显式设置，且需要写权限。C# 中最直接的方式就是 File.SetCreationTime，它底层调用的是 SetFileTime Win32 API。
常见错误现象：UnauthorizedAccessException（没管理员权限但目标是系统目录）、FileNotFoundException（路径存在但文件被占用或已删除）、设完后资源管理器不刷新（缓存问题，F5 或重启资源管理器即可）。
- 必须确保当前进程对文件有写权限；UAC 提权不是自动的，桌面程序默认无权改
C:\Windows下文件 - 路径必须指向真实存在的文件，不能是目录（设目录创建时间要用
Directory.SetCreationTime） - 传入的
DateTime值会被截断到 100ns 精度，但 Windows 文件系统实际只支持 100ns 对齐，所以无需手动 Round - 如果文件正被其他进程以独占方式打开（比如 Excel 正在编辑 .xlsx），调用会失败
示例：
string path = @"C:\test\log.txt";
if (File.Exists(path))
{
File.SetCreationTime(path, new DateTime(2020, 1, 1, 12, 0, 0, DateTimeKind.Utc));
}
File.SetLastWriteTime 和 File.SetLastAccessTime 要分开调，不能一并设置
C# 的 File 类没有“一次性设置全部时间戳”的方法。每个时间属性（创建、最后写入、最后访问）都对应独立函数，而且它们互不影响。比如你只调 File.SetCreationTime，不会动 LastWriteTime；反过来也一样。
使用场景：日志归档时想把一批旧文件的创建时间统一设为归档当天，但保留原始修改时间；或者测试代码中模拟“文件是昨天生成的”，只需改 CreationTime，LastWriteTime 保持原样即可。
- Windows 默认禁用 LastAccessTime 更新（性能优化），所以即使你调了
File.SetLastAccessTime，下次读取可能还是旧值——除非先用fsutil behavior set disablelastaccess 0开启（需管理员） -
DateTimeKind必须明确：传Local会按本地时区转成 UTC 存储；传Utc则直接写入。混用容易导致显示偏差（比如资源管理器显示比预期早/晚 8 小时） - 某些网络文件系统（如 SMB 共享）可能忽略 LastAccessTime 设置，这是服务端策略，客户端无法绕过
修改 NTFS 扩展属性（如作者、标题）得用 Shell API 或第三方库，File 类做不到
File.SetCreationTime 只管基础时间戳，和资源管理器“详细信息”页签里的“作者”“标题”“标签”完全无关。那些是 NTFS 的可选数据流（Alternate Data Streams）或 Shell 属性集（Property System），C# 标准库不提供操作接口。
常见错误现象：以为改了 CreationTime 就能影响“作者”字段；或者用 File.WriteAllText 写入新内容后，“作者”自动变成本地用户名——其实那是 Office 应用自己写的文档属性，和文件系统无关。
- 真要改 Shell 属性（如 .docx/.jpg 的作者），得用 Windows API Code Pack 或
Shell32.dll的 COM 接口，代码量大且仅限 Windows - 对纯文本文件（.txt/.log），这些字段根本不存在；资源管理器显示的“作者”只是空值或占位符
- PowerShell 的
Set-ItemProperty也无法跨平台操作这些属性，它背后也是调 Shell API
跨平台兼容性差，Linux/macOS 上 File.SetCreationTime 实际无效
.NET Core/.NET 5+ 在非 Windows 平台调用 File.SetCreationTime 不会报错，但也不会生效——Unix-like 系统传统上只有修改时间（mtime）和状态变更时间（ctime），没有“创建时间”概念。部分现代文件系统（如 ext4、APFS）虽支持 birthtime，但 .NET 运行时并未暴露该能力。
这意味着：如果你的程序要跑在 Linux 容器里，或者用 GitHub Actions 跑 CI，所有 SetCreationTime 调用都是静默丢弃的。别指望它能用于构建时间戳控制或归档逻辑。
- 检查是否生效的唯一办法是调
File.GetCreationTime读回来对比，而不是看异常 - macOS 上
stat -f "%B" path可查 birthtime，但 .NET 没对应 API；Linux 上stat -c "%w" path多数返回 “-”，代表不支持 - 若必须跨平台一致行为，建议改用文件名或内容里嵌入时间戳（如
report_20240520T143000.json），别依赖文件系统元数据
真正难的不是调哪个函数，而是意识到“创建时间”这个概念本身在不同系统里就不是一回事。Windows 上改得再准，到了 Linux 构建环境里就没了，这种隐性差异最容易漏测。
