getpid() 是 posix 系统获取 pid 最简单可靠的方式，需包含 ；windows 用 getcurrentprocessid()，需 ；/proc/self/pid 效率低且不通用；c++ 标准至今无原生 pid 接口。
直接调用 getpid() 是最简单可靠的方式
在 POSIX 兼容系统（Linux、macOS）上，getpid() 是标准且零依赖的获取当前进程 ID 的方法。它定义在 <unistd.h></unistd.h> 中，返回类型为 pid_t，本质是带符号整数，但实际值非负。
常见错误是忘记包含头文件或误用返回值类型（比如用 int 接收但未考虑平台差异）。
- 必须
#include <unistd.h></unistd.h>，C++ 中不推荐用<cstdlib></cstdlib>替代 -
pid_t在不同系统可能为int或long，直接打印建议用%d（Linux/macOS 下安全），或统一转成long后用%ld - 该函数永不失败，无 errno 设置，无需检查返回值
#include <unistd.h>
#include <iostream>
int main() {
std::cout << "PID: " << getpid() << "\n";
return 0;
}
Windows 下要用 GetCurrentProcessId()，头文件和语义都不同
Windows 没有 getpid()，对应的是 GetCurrentProcessId()，定义在 <windows.h></windows.h> 中，返回 DWORD（即 unsigned long）。它和 POSIX 版本语义一致，但不可跨平台混用。
容易踩的坑是条件编译遗漏、头文件冲突，或误以为 GetCurrentProcessId() 返回的是句柄（它返回的是 PID，不是进程句柄）。
立即学习“C++免费学习笔记（深入）”；
- 必须
#include <windows.h></windows.h>，不能只靠<unistd.h></unistd.h>或其他通用头文件 - 跨平台项目建议封装：用
#ifdef _WIN32分支，避免宏污染或链接错误 - 不要把返回值当句柄传给
CloseHandle()—— 这是常见误操作，会触发运行时错误
不推荐用 /proc/self/pid 读文件方式获取 PID
Linux 下可通过读取 /proc/self/pid 文件内容拿到 PID，但这属于绕路方案，纯属“能跑但不该用”。
问题在于：它引入了 I/O、字符串解析、错误处理等额外开销；路径依赖 Linux 内核 + procfs 挂载；且在容器或某些精简环境（如 initramfs）中可能不可用。
- 读文件需打开
/proc/self/pid，然后用read()或std::ifstream，再转换字符串为整数 - 比
getpid()慢至少一个数量级，且存在ENOENT、EACCES等异常分支 - 唯一适用场景：极特殊调试工具中需验证内核视角 PID（比如检查是否被 ptrace 修改），否则毫无必要
C++20 起仍无标准库原生 PID 接口，别等 std::this_process::id()
目前 C++ 标准（包括 C++20 和 C++23）仍未提供跨平台获取 PID 的标准设施。提案（如 P1165R4）长期处于讨论阶段，尚未进入 TS 或正式标准。
这意味着所有“跨平台抽象”都得自己写，或依赖第三方（如 Boost.Process 的 boost::this_process::get_id()），但后者本质仍是封装 getpid() 或 GetCurrentProcessId()。
- Boost 版本需注意：
boost::this_process::get_id()返回的是boost::process::pid_t，底层映射到原生类型，不是标准pid_t - 自己封装时，建议用 inline 函数而非宏，便于调试和类型检查
- 不要因为“想写标准 C++”而回避系统 API —— PID 本身就是操作系统概念，强求标准抽象反而增加维护成本
真正要注意的是：多线程环境下 PID 不变，但线程 ID（TID）不同；如果误把 std::this_thread::get_id() 当作进程 ID，会导致逻辑崩溃，这个混淆点比跨平台更常出错。
