std::filesystem::last_write_time 是唯一跨平台可靠时间戳，因修改时间（mtime）在所有系统内核中均原生支持且语义一致；创建时间（creation_time）在Linux/macOS上非标准字段，Windows虽支持但被C++标准忽略。
C++ 标准库 std::filesystem 无法获取文件的精确创建时间戳（creation_time）——它在 Linux/macOS 上根本不存在，在 Windows 上虽有但被标准刻意忽略。
为什么 std::filesystem::last_write_time 是唯一跨平台可靠时间戳
std::filesystem::last_write_time 返回的是修改时间（mtime），它在所有 POSIX 系统和 Windows 上都由内核原生支持且语义一致。而创建时间（birth time 或 crtime）不是 POSIX 标准要求的字段：Linux 的 ext4/xfs 虽可存储，但需特定挂载选项（如 ext4 + birthtime）且 statx(2) 才暴露；macOS 的 APFS/HFS+ 支持 birthtime，但 libc 不通过 stat 暴露；Windows 的 FILETIME CreationTime 存在，但 std::filesystem 规范明确只要求实现 last_write_time、last_access_time 和 file_size。
实操建议：
- 别尝试用
std::filesystem::status或std::filesystem::symlink_status提取创建时间——它们不提供该字段 - 若必须用创建时间，放弃“跨平台”幻想，按系统条件编译
- 用
std::filesystem::last_write_time做业务逻辑基准最安全，比如资源热重载、缓存失效判断
Windows 下获取创建时间：用 GetFileInformationByHandle + FILE_BASIC_INFO
Windows API 提供稳定、高精度（100ns）的创建时间，但需 HANDLE 和额外转换。C++ 标准库不封装它，必须手撸。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 先用
std::filesystem::canonical获取绝对路径，再调用CreateFileW（注意加FILE_FLAG_BACKUP_SEMANTICS支持目录） - 调用
GetFileInformationByHandleEx传入FileBasicInfo，比GetFileTime更简洁且含时区无关的 UTC 时间 - 把
FILETIME转成std::chrono::file_clock::time_point需手动计算：1601-01-01 到 1970-01-01 是 11644473600 秒，再换算为 100ns 单位 - 示例关键片段：
#include <windows.h>
#include <chrono>
#include <filesystem>
<p>std::optional<std::chrono::file_clock::time_point> get_creation_time_win(const std::filesystem::path& p) {
HANDLE h = CreateFileW(p.c_str(), 0, FILE_SHARE_READ, nullptr,
OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, nullptr);
if (h == INVALID_HANDLE_VALUE) return std::nullopt;</p><pre class='brush:php;toolbar:false;'>FILE_BASIC_INFO info;
if (!GetFileInformationByHandleEx(h, FileBasicInfo, &info, sizeof(info))) {
CloseHandle(h);
return std::nullopt;
}
CloseHandle(h);
// FILETIME is 100ns intervals since 1601-01-01; file_clock since 1970-01-01
auto ft_as_ns = (static_cast<uint64_t>(info.CreationTime.dwHighDateTime) << 32) |
info.CreationTime.dwLowDateTime;
auto secs_since_epoch = (ft_as_ns / 10000000) - 11644473600ULL;
auto ns_part = (ft_as_ns % 10000000) * 100;
return std::chrono::file_clock::from_time_t(secs_since_epoch) +
std::chrono::nanoseconds(ns_part);}
Linux/macOS 下：没有通用创建时间，只有妥协方案
Linux 内核从 4.11+ 支持 statx(2) 的 stx_btime 字段，但 glibc 直到 2.28 才暴露接口，且需编译时定义 _GNU_SOURCE；macOS 的 stat 不返回 birth time，得用 getattrlist(2)（私有 API，不推荐）或第三方库（如 libmagic）间接推断。
实操建议：
- 不要依赖
stat的st_ctime—— 它是“状态更改时间”（ctime），不是创建时间，权限/硬链接数变更都会触发更新 - 若真要试
statx，确保目标系统内核 ≥ 4.11、glibc ≥ 2.28，并检查statx返回值中STATX_BTIME是否在stx_mask中置位 - 更现实的做法：记录首次写入时的时间戳到 sidecar 文件（如
.filename.created），或用数据库维护元数据 - 跨平台构建时，用
#ifdef __linux__或#ifdef __APPLE__隔离不可用分支，避免链接失败
真正难的不是写几行代码拿时间，而是接受“创建时间”在多数生产环境里本就不可靠：文件复制、打包解压、网络传输、容器镜像层都会丢失或重置它。如果业务逻辑强依赖“首次生成时刻”，优先考虑应用层打标，而不是寄希望于文件系统。
