getpid() 最简单：POSIX 系统（Linux/macOS）直接提供，返回当前进程 PID（pid_t 类型），声明于 ，无需 fork() 等额外调用。
Linux/macOS 下用 getpid() 获取 PID 最简单
POSIX 系统（包括 Linux 和 macOS）直接提供 getpid()，它返回当前进程的 PID，类型是 pid_t，本质是带符号整数。无需额外头文件，在 getpid() 属于 POSIX，不是 C 标准函数）。
常见错误是误以为要调用 fork() 或 waitpid()——完全不需要。只要进程已启动，getpid() 就能立刻返回有效值。
- 示例：
#include
#include int main() { std::cout << "PID: " << getpid() << std::endl; return 0; } - 注意：在子进程中调用
getpid()返回的是子进程自己的 PID，不是父进程的 - 返回值为 0 是合法的（例如某些容器或 chroot 环境中），不能当作错误判断依据
Windows 下必须用 GetCurrentProcessId()
Windows 没有 getpid()，对应的是 Win32 API 函数 GetCurrentProcessId()，定义在 DWORD（即 unsigned long）。它和 getpid() 行为一致，但不可混用。
容易踩的坑是忘记链接依赖或头文件顺序问题：如果先包含其他 Windows 相关头文件（比如
立即学习“C++免费学习笔记（深入）”；
- 示例：
#include
#include int main() { std::cout << "PID: " << GetCurrentProcessId() << std::endl; return 0; } - 不要用
GetProcessId(GetCurrentProcess())—— 多余且有风险：后者需要 HANDLE，而GetCurrentProcess()返回伪句柄，传给GetProcessId()虽然通常能工作，但文档未保证其行为稳定 -
GetCurrentProcessId()在 UWP 应用中不可用，仅适用于传统 Win32 进程
C++ 跨平台封装建议：宏 + 内联函数
不推荐用第三方库（如 Boost.Process）只为取一个 PID；轻量级跨平台封装更可控。核心是用预处理器区分平台，再统一接口名，比如 get_current_pid()。
关键点在于：不要试图把返回类型强行统一成 int——Linux/macOS 的 pid_t 可能是 int 或 long，Windows 的 DWORD 是无符号类型。安全做法是统一用 long 或 int64_t 做返回，或直接暴露原生类型并注明平台差异。
- 最小可行封装：
#ifdef _WIN32 #include
inline long get_current_pid() { return static_cast (GetCurrentProcessId()); } #else #include inline long get_current_pid() { return static_cast (getpid()); } #endif - 若需支持 C++17 及以上，可用
std::process::id（C++20 才正式加入），但目前主流编译器（GCC/Clang/MSVC）对 - 避免在头文件里写
#include后又没加WIN32_LEAN_AND_MEAN，否则会拖入大量不必要的宏和类型定义，增大编译时间
别把线程 ID 当 PID：std::this_thread::get_id() 不行
有人看到 std::this_thread::get_id() 就以为能拿到进程 ID，这是典型误解。get_id() 返回的是线程标识符，类型是 std::thread::id，和操作系统级 PID 完全无关，也无法转换。
即使主线程的线程 ID 在某些系统上数值巧合地接近 PID，也不能依赖——它既不跨平台，也不稳定，重启或不同构建下都可能变。
- Windows 下可用
GetCurrentThreadId()获取当前线程 ID，但它仍是线程维度，和 PID 无映射关系 - Linux 下
gettid()返回线程 ID（LWP），也不是 PID；主执行流的 LWP 通常等于 PID，但 clone/fork 后就不成立了 - 真正需要区分进程和线程场景时（如日志打标、调试跟踪），务必确认你调用的是进程级 API，而不是线程级
