std::thread::hardware_concurrency() 返回逻辑核心数而非物理核心数，且在嵌入式、容器或WSL中可能返回0；应先校验是否为0，再fallback至平台API（如Windows用GetSystemInfo，Linux用sysconf(_SC_NPROCESSORS_ONLN)）。
用 std::thread::hardware_concurrency() 获取 CPU 核心数，但要注意它不总是准确
这个函数返回的是系统**逻辑处理器数量**（比如开启超线程后可能是物理核心的两倍），不是物理核心数。Windows/macOS/Linux 都支持，但行为有差异：std::thread::hardware_concurrency() 在某些嵌入式或容器环境中可能返回 0（表示无法检测）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先检查返回值是否为 0，如果是，fallback 到平台特定方法（如 Windows 用
GetSystemInfo()，Linux 读/proc/cpuinfo） - 若只需逻辑核心数（多数诊断场景已够用），直接用该函数最轻量；不要把它当“物理核心数”硬解
- macOS 上它通常返回逻辑核心数，但无法区分超线程与否——真要分物理/逻辑，得调
sysctlbyname("hw.physicalcpu")和"hw.logicalcpu"
跨平台获取内存总量必须绕过 std::filesystem，改用系统 API 封装
std::filesystem::space() 只能查磁盘空间，完全不提供内存信息。内存总量属于系统资源层面，C++ 标准库至今没抽象这一能力。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Windows：调
GetPhysicallyInstalledSystemMemory()（返回真实安装容量，单位 KB）或GlobalMemoryStatusEx()（返回当前可用+总量，含虚拟内存） - Linux/macOS：用
sysconf(_SC_PHYS_PAGES)×sysconf(_SC_PAGESIZE)计算物理内存字节数；注意_SC_PHYS_PAGES在某些容器中可能被 cgroup 限制，需结合/sys/fs/cgroup/memory.max判断 - 统一处理时，建议封装成
get_total_physical_memory_bytes()函数，内部用#ifdef _WIN32/#elif __linux__/#elif __APPLE__分支
查磁盘空间别只信 std::filesystem::space() 的 capacity 字段
它在大多数桌面系统上工作正常，但在 WSL、Docker、某些 NAS 挂载点或 FUSE 文件系统中，capacity 可能返回 0 或远小于实际值——因为底层 statvfs 调用被截断或未实现。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 始终先检查
space.available是否为static_cast<uintmax_t>(-1)</uintmax_t>（POSIX 表示不可用），再判断capacity - 对根路径（如
"/"或"C:\"）检测时，Windows 上推荐同时调GetDiskFreeSpaceEx()做交叉验证 - Linux 下若发现
std::filesystem::space()异常，可 fallback 到statvfs()并检查f_frsize * f_blocks，注意部分网络文件系统（如 NFSv4）可能把f_blocks设为 0
编译与链接时容易漏掉的平台依赖
跨平台工具不是写完条件编译就完事——链接阶段会暴露隐性依赖。
常见坑：
- macOS 上用
sysctlbyname需链接-lSystem（通常默认带，但用 Clang++ 15+ 的-stdlib=libc++时偶发丢失） - Linux 下
sysconf属于 libc，但若用 musl（如 Alpine 容器），需确保编译器没加--static导致sysconf符号解析失败 - Windows 上
GetPhysicallyInstalledSystemMemory在minwindef.h后声明，且要求_WIN32_WINNT >= 0x0601（即 Win7+），否则编译报错unresolved external
真正麻烦的从来不是代码怎么写，而是某台客户的旧 Linux 发行版内核不支持 meminfo 的某个字段，或者某台工控机 BIOS 把 SPD 信息锁死了——硬件诊断工具的鲁棒性，90% 在兜底逻辑里。
