Linux下最可靠方式是调用uname()读取utsname.version字段，因其包含不可篡改的完整编译信息（如#1 SMP PREEMPT_DYNAMIC Debian 6.12.12-1~bpo12+1 (2024-04-15)），而release、/proc/version、sysctl均不满足精确性与可靠性要求。
Linux 下用 uname -v 和 /proc/sys/kernel/osrelease 获取内核编译版本字符串
Linux 内核的“详细编译版本字符串”（即包含编译时间、用户、主机、GCC 版本等的完整 uname -v 输出）不直接暴露在标准 C++ API 中，必须通过系统接口或读取文件获取。最可靠的方式是调用 uname() 系统调用并解析其返回的 struct utsname 中的 version 字段——它正是内核编译时生成的完整字符串。
注意：uname().release 是版本号（如 6.8.0-52-generic），而 uname().version 才是你要的“详细编译版本字符串”，例如：
#52~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Nov 1 17:23:49 UTC 2024
实操建议：
- 包含
<sys/utsname.h>，声明struct utsname buf，调用uname(&buf)；失败时检查errno -
buf.version是以\0结尾的 C 字符串，可直接转为std::string；长度通常 ≤ 65 字节，但标准未保证，建议 strncpy + 显式截断 - 不要依赖
/proc/version：它内容冗余（含 “Linux version” 前缀），且某些容器环境（如 unprivileged pod）可能被挂载屏蔽
Windows 下无法获取内核“编译序列号”，GetVersionEx 已废弃且不提供该信息
Windows 没有类 Unix 的“内核编译版本字符串”概念。NT 内核版本（如 10.0.22631）由 RtlGetVersion() 或 VerifyVersionInfo() 获取，但它只反映系统更新级别，与内核源码编译行为无关。所谓“序列号”在 Windows 内核中不存在公开导出字段——微软不发布内核构建元数据，也不提供类似 Linux CONFIG_LOCALVERSION 的机制。
立即学习“C++免费学习笔记（深入）”；
常见误解和坑：
-
GetVersionEx()在 Win8.1+ 已被禁用，返回固定值（如 6.2），必须用RtlGetVersion()（需链接ntdll.lib）或VerifyVersionInfo() - 注册表路径
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion下的BuildLabEx值看起来像构建信息，但它只是字符串标记（如22631.1.amd64fre.rs5_release.180914-1434），非编译时嵌入的 GCC 风格版本字符串，也无唯一序列号语义 - 试图从
ntoskrnl.exePE 头读取时间戳或校验和，属于逆向范畴，不稳定、无文档支持，且受 PatchGuard 限制
macOS 不提供内核编译序列号，sysctlbyname("kern.version") 是唯一可用字段
macOS（Darwin）内核的 kern.version sysctl 值接近 Linux 的 uname -v，但内容精简：它包含 XNU 版本、编译日期、目标架构和部分编译主机信息，例如：
Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T8103
这已是用户空间能合法获取的最详细内核构建描述。实操要点：
- 调用
sysctlbyname("kern.version", ...)，缓冲区大小建议 ≥ 512 字节；失败时检查errno == ENOMEM并重试 - 没有独立的“序列号”字段；末尾的
T8103是 SoC 标识，不是构建序列号；RELEASE_ARM64是配置名，非唯一 ID - 不要尝试读取
/System/Library/Kernels/kernel的 Mach-O load commands：LC_SOURCE_VERSION可能为空，且 Apple 不保证其存在或格式稳定
跨平台封装时别硬凑“序列号”，优先明确业务需求是否真需要它
很多场景声称要“内核序列号”，实际只需要区分内核构建唯一性（如调试崩溃上下文）或验证运行环境一致性。这时更可靠的做法是：
- Linux：拼接
uname().version+uname().machine+getauxval(AT_HWCAP)（用于检测 CPU 特性差异） - Windows：用
RtlGetVersion()获取MajorVersion/MinorVersion/BuildNumber，再加GetProductInfo()判断 edition（如 Enterprise vs Pro） - macOS：用
sysctlbyname("kern.version")+sysctlbyname("hw.model")，避免解析模糊字段 - 所有平台都应忽略“序列号”字面意思——它既不可靠，也不可移植；若需唯一标识，应由上层服务生成并注入（如启动时写入
/run/myapp/kernel_id）
真正的难点不在读取，而在理解：不同内核对“版本”的定义根本不同。强行统一字段名只会掩盖差异，导致线上环境误判。
