最轻量可靠检查进程存在的方式是linux/macos用kill(pid, 0)，返回0表示存在且可访问，esrch表示不存在，eperm表示存在但无权限；windows需openprocess()+getexitcodeprocess()判断still_active。
用 kill(0) 检查进程是否存在（Linux/macOS）
最轻量、最可靠的方式是调用 kill(pid, 0)：它不发信号，只做权限和存在性校验。返回 0 表示进程存在且当前用户有权限向其发信号；返回 -1 且 errno == ESRCH 表示进程不存在；返回 -1 且 errno == EPERM 表示进程存在但无权限（比如是 root 启动的普通用户进程）。
注意：pid 必须是正整数（不能是 0 或负数），且不能是已退出但尚未被父进程 wait() 的僵尸进程（此时 kill(0) 仍会返回 0）。
示例片段：
if (kill(pid, 0) == 0) {
// 进程存在（且可访问）
} else if (errno == ESRCH) {
// 进程不存在
} else if (errno == EPERM) {
// 进程存在，但无权限检查（常见于跨用户场景）
}
Windows 下用 OpenProcess() + GetExitCodeProcess()
Windows 没有等价的轻量系统调用，必须打开句柄再查状态。OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, FALSE, pid) 成功仅说明 PID 当前“可能”有效；真正判断是否存活，需紧接着调用 GetExitCodeProcess() 并检查返回值是否为 STILL_ACTIVE（即 259）。
立即学习“C++免费学习笔记（深入）”；
常见误操作：
- 只调用
OpenProcess()就认为进程存在 —— 实际上刚退出的进程句柄可能还短暂有效 - 忽略
GetExitCodeProcess()返回值，直接用GetLastError()判断 —— 错误码不可靠，必须看函数返回值和输出参数 - 没加
PROCESS_QUERY_LIMITED_INFORMATION权限（Win8+ 推荐），而用旧的PROCESS_QUERY_INFORMATION可能因 UAC 或权限策略失败
不要依赖 /proc/pid 或 ps 命令解析
虽然 Linux 下 access("/proc/1234", F_OK) 看起来简单，但它有严重缺陷：
-
/proc/pid目录在进程刚退出、内核尚未回收时仍存在（尤其在高负载或调试环境下） - 需要
procfs挂载且路径固定，容器环境（如 PID namespace）中不可靠 - 调用
ps或pgrep命令再 parse 输出 —— 开进程、fork、exec、pipe、字符串匹配，开销大且易受 locale、字段顺序、空格转义影响
除非你明确在做运维脚本而非系统编程，否则绕过 kill(0) 是典型的“看起来快，实际错得稳”。
跨平台封装要注意的边界条件
如果写通用函数，需区分平台并处理以下情况：
- PID 为 0：Linux 下
kill(0, 0)检查的是调用者所在进程组，不是单个进程；Windows 不允许 PID 0 - PID 为负数：Linux 下表示进程组，
kill(-pgid, 0)可查组是否存在，但语义不同；Windows 无对应概念 - 子进程刚
exit()但父进程未wait()：此时进程已终止，但内核保留其 PID 和少量元数据 ——kill(0)和OpenProcess()都可能返回“存在”，这是正常行为，不代表进程还在运行
真正可靠的“进程正在运行”判断，必须结合业务逻辑：比如检查其监听的 socket 是否可连、共享内存是否更新、或通过 IPC 协议主动 ping。
