st_ctime 表示 inode 元数据最后一次变更时间（如权限、所有者变化），非创建时间；Linux/macOS 通过 stat() 获取，Windows 无对应 API，只能降级处理或报错。
Linux/macOS 下用 stat 系统调用获取 st_ctime
Unix-like 系统中，“状态改变时间”对应的是 st_ctime 字段（注意：不是“创建时间”，而是 inode 元数据最后一次变更的时间，比如权限、所有者、硬链接数变化等）。C++ 标准库不提供跨平台接口，必须调用系统 API。
关键点：st_ctime 是 struct stat 的成员，类型为 time_t，需用 localtime 或 gmtime 转换为可读格式。常见错误是误以为它代表文件内容修改时间（那是 st_mtime）或创建时间（POSIX 无此字段）。
示例代码片段：
#include <sys/stat.h>
#include <ctime>
#include <iostream>
<p>struct stat sb;
if (stat("/path/to/file", &sb) == 0) {
std::cout << "Status change time: "
<< std::ctime(&sb.st_ctime); // 包含换行
}-
stat()不跟随符号链接；如需跟随，改用lstat() - 在 macOS 上，
st_ctime和st_birthtime（创建时间）不同，后者需用getattrlist()扩展获取，stat不提供 - Linux 内核 2.6+ 默认启用
relatime，但不影响st_ctime更新逻辑
Windows 下用 GetFileInformationByHandle 获取 dwCreationTime？错
Windows 没有直接对应 POSIX st_ctime 的概念。NTFS 中的 “change time”（文档常称 “Last Change Time”）实际对应 BY_HANDLE_FILE_INFORMATION::ftLastWriteTime？不，那是内容修改时间。真正接近的是 ftLastWriteTime 的兄弟字段：ftLastAccessTime？也不是。
立即学习“C++免费学习笔记（深入）”；
准确来说：Windows NTFS 的 “Change Time”（即文件记录（MFT entry）最后一次被修改的时间）由 BY_HANDLE_FILE_INFORMATION::ftLastWriteTime **以外** 的字段承载——它叫 ftLastWriteTime？不，是 ftLastWriteTime 的别名？错。真实答案是：Windows 没有公开 API 直接暴露 NTFS Change Time。Win32 API 提供的三个时间戳只有：ftCreationTime、ftLastAccessTime、ftLastWriteTime —— 它们分别近似于 birth / atime / mtime，但 没有 ctime。
如果你看到某些工具（如 PowerShell 的 Get-Item）显示 “LastModified”、“LastAccessed”、“CreationTime”，那只是对上述三者的封装，不包含状态变更时间。NTFS 底层确有 Change Time，但 Win32 层未导出。
- 尝试用
GetFileInformationByHandle只能拿到三个标准时间，st_ctime语义无法映射 - 使用 WMI（
Win32_FileInfo）或 NT API（NtQueryInformationFile+FileBasicInformation）仍只返回这三者 - 跨平台程序若依赖 ctime，在 Windows 上只能降级处理（例如用
ftLastWriteTime替代，或明确报错不支持）
跨平台封装时怎么处理 ctime 缺失问题
没有银弹。C++ 项目若需统一抽象文件时间，必须接受 Windows 无 ctime 的事实，并在设计层面做取舍。
常见做法是定义一个枚举和结构体，但对 Windows 明确设为无效值：
enum class FileTimeType { Modified, Accessed, Created, StatusChanged };
struct FileTimes {
std::optional<std::time_t> modified;
std::optional<std::time_t> accessed;
std::optional<std::time_t> created;
std::optional<std::time_t> status_changed; // Linux/macOS: st_ctime; Windows: nullopt
};- 不要试图用
GetFileAttributesEx或FindFirstFile填充status_changed，它们不提供该字段 - 若业务逻辑强依赖 ctime（例如检测 chmod 是否发生），Windows 用户需被告知功能受限，或改用 WSL/容器运行
- CMake 构建时可通过
#ifdef _WIN32条件编译，避免链接失败，但逻辑分支必须显式处理缺失场景
容易被忽略的权限与挂载选项影响
即使代码正确，stat() 也可能失败或返回过期值，原因常不在代码本身。
- 目标路径无执行权限（x）时，
stat()会因无法进入目录而失败，错误码为EACCES，不是ENOENT - NFS 挂载时若启用
noac（关闭属性缓存），st_ctime读取变慢但准确；默认ac模式下可能延迟数秒 - 某些容器环境（如 rootless Podman）中，用户命名空间映射可能导致
stat()返回 0 或 -1，需检查errno而非仅返回值 - ext4 启用
lazytime挂载选项时，st_ctime更新会被延迟到 sync 或 umount，但行为对应用透明
真正麻烦的是：ctime 变更不触发 inotify 的 IN_ATTRIB 事件 —— 如果你靠 inotify 监控状态变化，得同时监听 IN_ATTRIB 和 IN_MOVED_TO（重命名也改 ctime），且仍可能漏掉 chown/chmod 的瞬间。
