Windows用CreateToolhelp32Snapshot+PROCESSENTRY32查进程名最可靠，需设dwSize、用_stricmp比较；Linux用/proc/[pid]/comm读取任务名，注意权限与换行处理；跨平台应避免shell命令，采用原生API并加超时重试。
Windows下用 CreateToolhelp32Snapshot 遍历进程查名字
直接调用 Windows API 是最可靠的方式，不依赖外部命令或权限提升。关键在于用 PROCESSENTRY32 结构体匹配进程名，注意 szExeFile 字段只含文件名（不含路径），且大小写不敏感。
实操要点：
-
CreateToolhelp32Snapshot必须传TH32CS_SNAPPROCESS，否则返回空； - 第一次调用
Process32First前要将dwSize设为sizeof(PROCESSENTRY32)，否则后续遍历失败； - 比较进程名时用
_stricmp或std::equal+std::tolower，避免大小写导致漏判； - 示例片段：
PROCESSENTRY32 pe{0}; pe.dwSize = sizeof(pe); HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if (hSnap != INVALID_HANDLE_VALUE && Process32First(hSnap, &pe)) { do { if (_stricmp(pe.szExeFile, "notepad.exe") == 0) { // 找到了 break; } } while (Process32Next(hSnap, &pe)); }
Linux下用 opendir("/proc") + readlink 解析 /proc/[pid]/comm
Linux 没有统一“进程名”概念，/proc/[pid]/comm 存的是内核态任务名（通常为可执行文件 basename），比 /proc/[pid]/cmdline 更轻量、更稳定，适合快速判断。
常见坑：
立即学习“C++免费学习笔记（深入）”；
- 不是所有 PID 目录都可读（如其他用户进程），
opendir失败要跳过，不能直接报错退出； -
/proc/[pid]/comm内容末尾无换行符，用fgets读取后需手动截断\n； - 某些容器环境或低权限下
/proc/[pid]/comm可能被裁剪或不可读，此时可 fallback 到/proc/[pid]/stat的第2字段（括号包裹的 name）； - 示例关键逻辑：
char comm[256]; snprintf(path, sizeof(path), "/proc/%s/comm", entry->d_name); int fd = open(path, O_RDONLY); if (fd >= 0 && read(fd, comm, sizeof(comm)-1) > 0) { comm[strcspn(comm, "\n")] = '\0'; if (strcmp(comm, "nginx") == 0) { /* found */ } close(fd); }
跨平台封装要注意 std::this_thread::sleep_for 不解决竞态，得靠重试+超时
查进程是否“正在运行”本质是瞬时快照，无法保证结果下一毫秒仍有效。很多代码误以为调一次就稳了，实际在服务启停边界容易误判。
合理做法：
- 单次检查后不要立即做关键决策（比如自动重启）；
- 若用于健康检查，应连续 2–3 次间隔 100–500ms 查询，全部失败才认为已退出；
- 总超时建议设为 2–5 秒，避免卡死（尤其 Linux 下遇到大量僵尸进程时
/proc遍历可能变慢）； - Windows 下如果目标进程刚启动但尚未创建主线程，
CreateToolhelp32Snapshot可能暂时看不到——这不是 bug，是时机问题。
别用 system("tasklist | findstr") 或 popen("ps aux | grep")
看似简单，但隐患极多：启动 shell 进程开销大、输出格式不稳定（不同系统 locale 或 ps 版本会导致列偏移）、grep 可能匹配到自身或子串（如查 python 会命中 python3.9 和 ipython）、权限受限时命令根本执行不了。
真实项目里这些写法基本等于埋雷：
- Windows 上
tasklist在 Server Core 或 Minimal Shell 环境可能不存在； - Linux 上
ps默认只显示当前终端进程，加-e才全量，但部分嵌入式 busybox 版本不支持； - 字符串解析一旦出错（比如进程名含空格或特殊字符），整个判断逻辑就崩；
- 没有错误码反馈机制，失败时只能靠 stderr 字符串匹配，脆弱得难以调试。
真要兼容性优先，宁可用条件编译分 Windows/Linux 走原生 API，也别碰 shell 管道。
