Linux下可通过解析/proc/version文件提取内核编译日期，其末尾含标准日期格式（如“Fri Aug 23 18:50:29 UTC 2024”），建议空格分隔后倒序匹配月份缩写；Windows无对应API，仅能获取版本号；macOS需用sysctlbyname("kern.version")。
Linux下读取/proc/version获取内核编译日期与版本
Linux系统最直接的方式是解析/proc/version，它包含内核版本、编译器、编译用户和编译时间等信息。该文件内容格式固定，例如：
Linux version 6.8.0-45-generic (buildd@lcy02-amd64-001) (x86_64-linux-gnu-gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 23 18:50:29 UTC 2024
关键信息在末尾的#45~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 23 18:50:29 UTC 2024部分，其中日期时间即为内核编译时间。
- 用
std::ifstream打开/proc/version，逐行读取后提取最后一段含Fri Aug 23...格式的子串 - 注意：不同发行版（如RHEL/CentOS）可能用
Mon Jan 1 00:00:01 CST 2024格式，时区字段长度不固定，建议用空格分隔+倒序匹配日期模式（如含Jan|Feb|Mar等月份缩写） - 不要依赖字段索引（比如“第7个空格后”），因为GCC版本号、主机名等长度可变，容易越界
Windows下无法直接获取内核编译日期，只能查版本号
Windows NT内核不对外暴露编译时间戳，GetVersionEx已废弃，RtlGetVersion或VerifyVersionInfo仅返回主次版本、build号（如10.0.22621），没有编译日期。
-
GetKernelVersion()这类函数不存在——Windows API没提供 - 有人尝试从
ntoskrnl.exe资源节或PE头读时间戳，但那是链接时间而非实际内核编译时间，且需管理员权限+绕过ASLR/签名验证，不可靠 - 若必须估算，可用
GetTickCount64()反推系统运行时长，再结合systeminfo | findstr "Original"查安装日期，但这不是内核编译时间
跨平台封装建议：用uname() + 条件编译
POSIX系统（Linux/macOS/BSD）可用uname()获取基础版本字符串，但不带编译日期；macOS的sysctlbyname("kern.version")比/proc/version更稳定（因为/proc非标准POSIX）。
立即学习“C++免费学习笔记（深入）”；
- Linux优先走
/proc/version路径，fallback到uname() - macOS必须用
sysctlbyname("kern.version", ...)，返回字符串类似Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 - Windows直接返回
"Windows NT kernel, version X.Y.ZZZZ (no build timestamp available)"，避免伪造数据 - 别试图统一接口返回“编译时间”，不同系统语义不同，硬对齐反而误导调用方
常见错误：把__DATE__/__TIME__当系统内核时间
新手常误用C++预定义宏__DATE__和__TIME__，它们记录的是**当前程序编译时间**，和操作系统内核毫无关系。
- 即使你静态链接了glibc，
__DATE__仍是你的exe编译时间，不是linux-image-6.8.0的构建时间 - 混淆会导致监控系统误报“内核已过期”，实际只是你的工具链老旧
- 若真需要程序构建时间，应单独记录并输出，但必须明确标注为“application build timestamp”
内核编译时间本质是发行版构建流水线产物，不在运行时API里透出——Linux靠伪文件系统妥协提供，Windows则选择不暴露。拿不到就是拿不到，强行hack不如坦然返回空值或注明不可用。
