std::thread::hardware_concurrency() 常返回0，因标准允许实现无法可靠检测时返回“未知”，不表示无并发能力；应优先用平台API：Linux调sysconf(_SC_NPROCESSORS_ONLN)，Windows调GetLogicalProcessorInformation()，macOS用sysctlbyname("hw.ncpu")。
用 std::thread::hardware_concurrency() 获取 CPU 核心数，但别信它返回的值
std::thread::hardware_concurrency() 确实是标准库中唯一跨平台的 CPU 核心数查询接口，但它只保证返回“建议的并发线程数”，不是真实物理核心数，也不区分超线程。Windows 上可能返回逻辑处理器数（含超线程），Linux 上有时返回 0（例如容器里没权限读 /proc/cpuinfo），macOS 上则常返回逻辑核心数。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先 fallback 到系统 API：Windows 用
GetLogicalProcessorInformationEx()（需 Win7+），Linux 读/proc/cpuinfo并统计processor字段行数，macOS 调sysctlbyname("hw.ncpu", ...) - 若坚持纯 C++ 标准方案，至少加一层校验：
if (n == 0) n = 1;，避免后续逻辑崩掉 - 不要用它判断是否支持并行计算——它不反映实际调度能力，更不能替代
std::jthread或线程池的资源决策
查内存总量必须绕过 std::filesystem，改用系统级接口
std::filesystem::space() 只能查磁盘空间，C++20 标准库至今没有提供内存总量的跨平台接口。试图用 new 分配大块内存再 catch 异常来“探测”总内存，既不可靠又危险（会触发 OOM killer 或卡死）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Windows：调
GlobalMemoryStatusEx(&memInfo)，取memInfo.ullTotalPhys - Linux：读
/proc/meminfo，解析MemTotal:行，单位是 kB，注意跳过前导空格和冒号后空格 - macOS：用
sysctlbyname("hw.memsize", &size, &len, nullptr, 0)，返回字节数 - 所有路径和系统调用都应加异常防护（如文件不可读、API 返回失败），默认 fallback 到 0 或已知最小值（如 512MB）
查磁盘剩余空间别直接拼接路径字符串，std::filesystem::space() 是唯一靠谱选择
这是三个指标里唯一能用标准库干净解决的。但要注意：std::filesystem::space() 的行为在不同平台对“根路径”的解释略有差异（比如 Windows 上 "C:" 和 "C:" 可能返回不同结果），且要求路径存在、可访问。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 统一用完整根路径：Windows 上用
"C:\\"（双反斜杠转义），Linux/macOS 用"/" - 先检查路径是否存在：
std::filesystem::exists(path)，否则space()抛std::filesystem::filesystem_error - 返回的
capacity、free、available中，用户关心的是available（非 root 用户可用空间），不是free（所有空闲空间） - 如果目标是检测多个磁盘（如 Windows 的 D:、E:），需遍历
GetLogicalDrives()（Win）或getmntent()（Linux），不能硬编码
跨平台编译时最容易被忽略的链接与头文件依赖
看似只是几行系统调用，但编译时很容易漏掉关键配置。比如 macOS 上 sysctlbyname 需要 <sys></sys>，而 Linux 的 /proc 读取需要 <fstream></fstream> 和 <string></string>，Windows 的 GlobalMemoryStatusEx 不仅要 <windows.h></windows.h>，还必须定义 WIN32_LEAN_AND_MEAN 并链接 kernel32.lib。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- CMake 中按平台 conditionally add_compile_definitions 和 target_link_libraries，别写死全局链接项
- 所有系统头文件包含前加
#ifdef _WIN32/#elif __linux__/#elif __APPLE__守卫，避免头文件冲突 - 测试阶段务必在三平台最小权限下运行（比如 macOS 的 SIP 开启、Linux 的容器无
/proc挂载、Windows 的受限用户账户），很多“本地能跑”的问题就出在这里
真正的难点不在代码怎么写，而在每个平台对“硬件信息”的定义本身就不一致——CPU 核心数要不要算超线程，内存总量包不包括预留固件区，磁盘可用空间扣不扣 reserved blocks。工具能给出数字，但得让用户知道这个数字在当前环境下到底代表什么。
