linux/macos下应使用getpid()（定义于），windows下必须用getcurrentprocessid()（定义于），二者语义不同，需封装统一接口如get_real_pid()避免跨平台错误。
Linux/macOS下用getpid()获取当前进程ID
在POSIX系统（包括Linux和macOS）中，getpid()是标准且唯一可靠的方式。它定义在<unistd.h></unistd.h>头文件里，返回类型为pid_t，直接调用即可，无参数、无失败可能。
常见错误是误以为需要#include <sys></sys>——现代glibc和Clang通常不强制要求，但显式包含更稳妥；另一个坑是把返回值当int打印却不加类型转换，遇到大PID时可能截断（尤其在某些嵌入式平台）。
示例：
#include <unistd.h>
#include <stdio.h>
int main() {
printf("PID: %d\n", (int)getpid()); // 显式转int更安全
return 0;
}</stdio.h></unistd.h>
Windows下必须用GetCurrentProcessId()而非getpid()
Windows的MSVC和MinGW都提供getpid()（来自<process.h></process.h>），但它返回的是CRT内部维护的伪PID，**不是Windows内核真正调度的PID**。调试器、任务管理器或OpenProcess()都认不到这个值。
正确做法是调用Win32 API GetCurrentProcessId()，定义在<windows.h></windows.h>中，返回DWORD，无需参数，永不失败。
注意点：
- MinGW-w64默认启用
__USE_MINGW_ANSI_STDIO时，printf("%u")才能正确输出DWORD；否则建议用%lu并强转(unsigned long) - 如果项目同时编译Linux/Windows，别直接宏替换
getpid——二者语义不同，应封装一层统一接口
跨平台代码怎么写才不出错
不能简单#ifdef _WIN32然后分别调用，因为头文件依赖和返回类型不一致。推荐做法是封装成内联函数或constexpr函数（C++17起），隐藏平台差异。
关键细节：
- Linux/macOS：用
pid_t，但对外统一转为unsigned long或uint64_t避免符号问题 - Windows：
GetCurrentProcessId()返回DWORD（即unsigned long），但实际范围是[0, 4294967295]，远超int - 不要用
std::to_string(getpid())混用——Windows下getpid()不可靠
最小可行封装示例：
#ifdef _WIN32
#include <windows.h>
inline unsigned long get_real_pid() { return GetCurrentProcessId(); }
#else
#include <unistd.h>
inline unsigned long get_real_pid() { return (unsigned long)getpid(); }
#endif</unistd.h></windows.h>
为什么getpid()在Windows上看起来“能用”却要避免
MSVC的getpid()确实返回一个数字，也常和真实PID一致——这是巧合。它的实现本质是缓存了进程启动时由CreateProcess返回的PID，但如果进程被调试器附加、或通过Job Object创建，该缓存就可能滞后甚至错误。
实测陷阱：
- 用VS调试器启动程序时，
getpid()返回的是调试器进程的PID（不是被调试进程） - 用
start /min cmd.exe派生子进程再调getpid()，可能拿到父cmd的PID - 调用
OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, getpid())在Windows上大概率失败，而用GetCurrentProcessId()一定成功
跨平台日志、进程间通信、权限检查等场景，一旦依赖了错误PID，问题会延迟暴露且极难定位。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
