Windows需用GetCurrentProcessId+CreateToolhelp32Snapshot+Thread32First/Next遍历匹配PID计数；Linux直接读/proc/self/status中Threads字段；二者不可互换，须分平台实现。
Windows 下用 EnumProcesses + OpenProcess + EnumProcessThreads
Windows 没有单次调用返回“当前进程线程数”的 API，必须先拿到当前进程 ID，再打开自身句柄，最后枚举其线程。关键点在于：EnumProcessThreads 并不存在——这是常见误记，正确函数是 Toolhelp32 系列中的 Thread32First/Thread32Next，但它们需要进程快照，且只能遍历**所有进程的线程**，不能限定为“当前进程”。所以实际做法是：
- 调用
GetCurrentProcessId()获取 PID - 调用
CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0)创建全系统线程快照 - 用
Thread32First/Thread32Next遍历，对每个THREADENTRY32.th32OwnerProcessID匹配当前 PID - 计数匹配项
注意：CreateToolhelp32Snapshot 在低权限进程（如被沙箱限制的 UWP 或某些容器）中可能失败，返回 INVALID_HANDLE_VALUE；另外该调用有一定开销，不适合高频轮询（如每毫秒调一次）。
Linux 下读 /proc/self/status 的 Threads 字段
Linux 最简单可靠的方式是直接读取 /proc/self/status 文件，查找以 Threads: 开头的行，提取其后的整数值。它反映的是当前进程的**线程数（含主线程）**，精度高、无竞态、开销极小。
- 该字段是内核实时维护的，无需解析
/proc/self/task/目录下的子目录来统计 - 字段格式固定为
Threads: 12（后跟空格和数字），可用fscanf(f, "Threads: %d", &count)安全提取 - 如果
fopen("/proc/self/status", "r")失败（例如在某些精简容器或 chroot 中无 procfs 挂载），应 fallback 到 1（主线程必然存在）
不要尝试用 gettid() 或 pthread_self() 推算总数——它们只返回当前线程 ID，和线程数量毫无关系。
立即学习“C++免费学习笔记（深入）”；
跨平台封装时如何避免类型与语义陷阱
表面看只是“返回一个整数”，但背后差异明显：Windows 下依赖 Toolhelp32 快照机制，Linux 下依赖 procfs 文件解析。封装时容易踩的坑包括：
- 忘记 Windows 需要链接
libpsapi.lib或libkernel32.lib（CreateToolhelp32Snapshot在 kernel32 中） - 在 Linux 封装里硬编码路径如
"/proc/" + to_string(getpid()) + "/status"，其实/proc/self/status更简洁安全，且不依赖getpid()调用时机 - 把返回值类型定为
int：Linux 的Threads:值可达数万（如 Java 进程），Windows 下也可能超INT_MAX（虽然少见），建议统一用unsigned long或size_t - 忽略错误路径：Windows 下快照失败、Linux 下文件不可读，都应返回可识别的错误码（如 0）而非抛异常——监控类代码通常要求静默容错
最简健壮封装就是两个独立函数加宏分发，不强求统一错误处理逻辑；强行抽象成一个接口反而掩盖了系统本质差异。
为什么不用 GetProcessTimes 或 /proc/self/stat 推算线程数
有人试图从 CPU 时间或状态字段反推线程数量，这是无效的：
-
GetProcessTimes只返回整个进程的累计内核/用户时间，不按线程拆分 -
/proc/self/stat第 20 个字段是num_threads，但它和/proc/self/status中的Threads:是同一内核变量，只是格式不同；直接读 status 更稳定（stat 字段顺序易受内核版本微调影响） - 试图用
std::thread::hardware_concurrency()替代——那是 CPU 核心数，不是当前进程线程数，两者完全无关
线程总数是个离散、明确、内核直报的量，没必要绕路。用对地方的 API，比任何间接估算都准。
