sysconf和sysctl是Linux/macOS获取CPU核心数与内存大小的POSIX标准方法，Windows则需用GetSystemInfo和GlobalMemoryStatusEx；跨平台封装须处理errno、结构体初始化及沙箱拦截等实际坑。
用 sysconf 和 sysctl 读 CPU 核心数（Linux/macOS）
Linux 和 macOS 下最直接的方式是调用系统 API，而不是解析 /proc 或执行 shell 命令——前者稳定，后者易受权限、路径或发行版差异影响。
-
sysconf(_SC_NPROCESSORS_ONLN)返回当前在线的逻辑核心数（含超线程），多数场景够用；sysconf(_SC_NPROCESSORS_CONF)是配置总数，可能包含离线核 - macOS 需用
sysctl：传"hw.ncpu"获取逻辑核数，"hw.physicalcpu"获取物理核数；注意要传int类型指针和长度 - 别硬编码
/proc/cpuinfo的行数或关键词匹配——某些容器环境或精简系统里它可能不存在或格式异常
获取总内存大小：优先用 sysconf，慎用 get_phys_pages
sysconf(_SC_PHYS_PAGES) 和 sysconf(_SC_PAGESIZE) 相乘可得物理内存字节数，这是 POSIX 标准做法，兼容性好。
-
get_phys_pages()只返回页数，没配getpagesize()就会出错；而且它不区分是否被预留或 cgroup 限制，数值偏高 - Windows 不支持这些函数，如果要做跨平台，得用条件编译分支；Linux 下也别依赖
/proc/meminfo的MemTotal字段——有些嵌入式系统压根没/proc - 注意返回值是
long，在 32 位系统上可能溢出，建议转成uint64_t再计算
Windows 上怎么拿到等效信息？用 GetSystemInfo 和 GlobalMemoryStatusEx
Windows 没有 sysconf，但两个 Win32 API 足够覆盖常见需求，且无需管理员权限。
-
GetSystemInfo()填充SYSINFOSTRUCT，其中dwNumberOfProcessors是逻辑核心数；注意它不区分超线程开关状态 -
GlobalMemoryStatusEx()的ullTotalPhys字段才是真实可用物理内存（单位字节），比旧版GlobalMemoryStatus()更可靠，后者在 >4GB 内存时会截断 - 别用
GetTickCount64()或性能计数器凑 CPU 使用率——那是另一个维度，和“核心数”“内存大小”无关，混用会导致逻辑错乱
跨平台封装要注意的三个实际坑
写个头文件统一接口看似简单，但几个细节不处理就会在 CI 或客户环境里崩：
立即学习“C++免费学习笔记（深入）”；
- macOS 的
sysctl调用失败时返回 -1，但errno不一定被设，得先清零再检查；Linux 下sysconf出错也返回 -1，但 errno 可能是EINVAL（参数不支持）或0（无错误） - Windows 的
GlobalMemoryStatusEx要求结构体dwLength字段必须初始化为sizeof(MEMORYSTATUSEX)，漏掉就返回 false - 所有系统调用都可能被 seccomp、容器 cgroup 或沙箱拦截——比如 Docker 默认禁用
sysctl，这时应提供 fallback（如返回 0 或抛异常），而不是静默返回错误值
真正难的不是调哪个函数，而是判断“这个值此刻是否可信”。比如容器里看到 64 核，但 cgroup 限了 2 核——环境信息本身没错，错的是你把它当调度依据用了。
