跨平台获取进程id必须区分平台：linux/macos用unistd.h的getpid()，windows用windows.h的getcurrentprocessid()，二者不可混用，需用预处理器或cmake隔离实现。
Linux/macOS 用 getpid()，Windows 用 GetCurrentProcessId() —— 不能混用
跨平台代码里直接调 getpid() 在 Windows 上会链接失败（找不到符号），而硬写 GetCurrentProcessId() 在 Linux/macOS 下根本不存在。这不是“哪个更好”的问题，而是头文件、链接库、ABI 完全隔离的两套机制。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用预处理器区分：Linux/macOS 走
unistd.h+getpid()，Windows 走windows.h+GetCurrentProcessId() - 别试图用
fork()或CreateProcess()的返回值代替——它们返回的是子进程 PID，不是当前进程 - POSIX 标准只要求
getpid()返回非负整数，实际值在不同系统上无意义，只用于比较或日志，别做算术
用 CMake 或构建系统自动处理头文件和链接依赖
手动写 #ifdef _WIN32 容易漏掉头文件包含或宏定义，尤其在多人协作时，有人忘了加 windows.h 就直接编译报错。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- CMake 中对 Windows 加
target_compile_definitions(myapp PRIVATE WIN32_LEAN_AND_MEAN)，避免windows.h拖入一堆冗余宏 - Linux/macOS 不需要额外链接选项；Windows 下如果用了静态 CRT（
/MT），GetCurrentProcessId()仍可用，它属于 Kernel32.dll，无需额外target_link_libraries - 别在头文件里直接展开平台判断逻辑——把封装函数（如
get_current_pid()）放在 .cpp 里实现，头文件只声明，减少宏污染
注意 getpid() 在容器或 PID namespace 中的行为
Linux 上跑在 Docker 或 systemd-nspawn 里时，getpid() 返回的是**当前 namespace 内的 PID**，不是宿主机 PID。调试时看到 1 别慌，那只是容器视角的 init 进程。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 需要宿主机 PID？得读
/proc/<pid>/status</pid>或调ioctl()查 PID namespace，但跨平台就失效了——这本身就是平台特性，无法抽象 - macOS 的沙盒（App Sandbox）下
getpid()仍返回真实 PID，但部分进程信息 API（如proc_pidinfo）会被拦截，别依赖它查父进程 - Windows Subsystem for Linux（WSL）里
getpid()返回的是 WSL2 虚拟机内的 PID，和 Windows 主机完全无关
别用 std::this_thread::get_id() 替代进程 ID
这是最常踩的坑：std::this_thread::get_id() 返回的是线程 ID，类型是未指定的 std::thread::id，和进程 ID 完全无关。即使主线程 ID 碰巧和进程 ID 数值相同，也是巧合，不可靠。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 明确区分概念：进程 ID 是内核分配的全局资源标识符；线程 ID 是进程内调度单位，生命周期短、复用频繁
- Windows 上
GetCurrentThreadId()和GetCurrentProcessId()名字太像，手抖写错会导致静默逻辑错误——建议 IDE 开启拼写检查，或用static_assert验证返回类型 - 如果真要记录“当前执行上下文”，建议同时记
getpid()和std::this_thread::get_id()，两者缺一不可
跨平台 PID 获取真正难的不是语法，而是每个平台对“进程”本身的定义差异：Linux 的 namespace、macOS 的 sandbox、Windows 的 job object，都会让同一个函数调用返回看似合理但语义不同的值。写的时候想清楚——你要这个 ID 干什么，比怎么拿到它更重要。