用process.getprocessesbyname判断进程存在需注意：只匹配无后缀名、大小写建议小写、结果长度>0才存在；getprocessbyid需捕获argumentexception和invalidoperationexception；hasexited为false不保证进程正常响应，gui进程应加responding检查。
怎么用 process.getprocessesbyname 判断进程是否存在
直接查进程名是最常用也最容易出错的方式。它不看路径、不看用户上下文，只匹配 process.processname（即去掉 .exe 后缀的名称），所以 notepad 能匹配 notepad.exe，但也会误匹配 notepad_plusplus.exe（如果名字含子串）。
实操建议：
- 始终用
Process.GetProcessesByName("chrome")而不是Process.GetProcessesByName("chrome.exe")—— 后者会返回空数组 - 检查结果长度：
if (Process.GetProcessesByName("explorer").Length > 0)，别用!= null，这个方法从不返回null - 注意大小写：Windows 上通常不敏感，但某些容器或模拟环境可能敏感，建议统一用小写比对
- 权限问题：跨用户进程（如系统服务启动的进程）在非管理员权限下可能查不到，
Access denied错误不会抛异常，而是直接不出现在结果里
为什么 Process.GetProcessById 会抛 ArgumentException
这不是“进程不存在”的信号，而是你传了个根本没用过的 PID，或者该 PID 曾经存在但已退出、被复用——Windows 的 PID 是可重用的，且重用前有短暂空窗期。
常见错误现象：
- 刚杀掉一个进程，立刻用它的 PID 去
GetProcessById，报ArgumentException: The parameter is incorrect - 缓存了某个进程的 PID，几秒后去查，发现报错，其实进程早死了，PID 被新进程占用了
正确做法是加 try-catch，并把 ArgumentException 和 InvalidOperationException（进程已退出）都视为“进程不可用”：
try {
var p = Process.GetProcessById(pid);
return !p.HasExited; // 注意：即使拿到对象，也要再 check HasExited
} catch (ArgumentException) {
return false;
} catch (InvalidOperationException) {
return false;
}
判断进程是否“真正运行中”：不能只看 HasExited == false
HasExited 返回 false 只代表内核对象还在，不代表进程响应正常。比如 GUI 进程卡死、后台服务假死、或处于挂起状态，HasExited 依然为 false。
使用场景决定你需要多深的探测：
- 简单存活检测：查
HasExited+Responding（仅限有窗口的进程，如notepad） - 服务类进程（无窗口）：得靠 IPC、端口监听、或心跳文件，C# 自身 API 没法判断它是否“逻辑上活着”
- 避免误判：不要依赖
StartTime是否“很老”，有些服务启动后长期不更新时间戳
示例（带响应性检查）：
var ps = Process.GetProcessesByName("devenv");
if (ps.Length > 0 && !ps[0].HasExited && ps[0].Responding) {
// 这才算“活得好”
}
64位系统上查 32位进程要注意什么
没有额外注意事项 —— Process 类本身不区分位数。但容易踩的坑在路径和模块加载上：
-
Process.MainModule.FileName在 32 位进程里可能返回C:\Windows\SysWOW64\...，而你以为是System32；反过来，64 位进程读System32才是真 System32 - 如果你用
Process.Modules遍历 DLL，32 位进程看不到 64 位模块，反之亦然 —— 但这不影响“是否存在”的判断 - 真正影响判断的是：某些杀毒软件或沙箱会拦截
EnumProcesses系统调用，导致GetProcessesByName返回空，哪怕进程明明在跑
这种拦截无法绕过，只能换方案：比如检查目标进程是否监听了某个已知端口，或读取其创建的互斥体（Mutex.OpenExisting）。
进程判断这事，表面是 API 调用，实际是跟操作系统、权限模型、甚至安全软件博弈。最稳的路不是“查一次就信”，而是结合名称、PID 生命周期、响应性、外部信号，交叉验证。尤其在自动化脚本或看门狗逻辑里，单点判断失败率远高于预期。
