启动后直接访问 proc.pid 即可获取 PID，但需避免 shell=True 和链式调用（如 .wait()）导致 proc 变为 None；推荐 shell=False + 参数列表，并用 psutil.pid_exists() 或进程启动时间校验 PID 有效性。
用 subprocess.Popen 启动进程后怎么拿到 PID
启动后立刻读 proc.pid 就行，但前提是别用 shell=True 且没被封装成函数悄悄调了 wait() 或 communicate() —— 这俩会阻塞，等进程结束才返回，PID 虽然还在，但你可能误以为“没拿到”。
常见错误现象：proc.pid 是 0 或负数，或者抛 AttributeError: 'NoneType' object has no attribute 'pid'，基本都是因为赋值写成了 proc = subprocess.Popen(...).wait() 这种链式调用，把返回值搞丢了。
- 正确写法：
proc = subprocess.Popen(['python', 'script.py'])，然后直接用proc.pid - 如果用了
shell=True，Linux/macOS 下实际 PID 是 shell 进程的，不是你真正想监控的子命令；Windows 稍好些，但依然不推荐 - 想跨平台稳拿真实目标进程 PID，优先用
shell=False+ 参数列表形式
检查 PID 对应进程是否还在运行，别只靠 os.kill(pid, 0)
os.kill(pid, 0) 是最轻量的存活检测，但它只判断“当前用户是否有权限向该 PID 发信号”，不保证进程在干你想让它干的事——比如进程已僵死、卡在系统调用里、或被 SIGSTOP 暂停，它都返回正常。
更糟的是：PID 可能已被系统回收并分配给新进程，os.kill(pid, 0) 会误报“活着”。尤其在高频率启停场景下，这个坑很隐蔽。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 必须配合进程启动时记录的
start_time（如proc.start_time = time.time()）做二次验证 - Linux 上可读
/proc/<pid>/stat</pid>的第 22 字段（start_time，单位是 jiffies），和你记录的时间比对，偏差过大就说明 PID 复用 - Windows 上可用
psutil.Process(pid).create_time()，比os.kill多一层时间锚点
用 psutil 替代纯 subprocess 做存活监控更可靠
纯 subprocess 只管启动，不负责后续状态跟踪。psutil 提供统一接口查进程是否存在、状态、CPU/内存占用，还能跨平台处理 PID 复用、僵尸进程等边界情况。
不用它的话，你得自己轮询 os.kill + 解析 /proc 或调 Windows API，容易漏掉退出码、信号终止、OOM kill 等静默失败。
- 安装：
pip install psutil - 检测示例：
psutil.pid_exists(pid)比os.kill(pid, 0)更准；psutil.Process(pid).status()返回'running'、'zombie'、'dead'等明确状态 - 注意：
psutil.Process(pid)构造时若进程已不存在，会抛psutil.NoSuchProcess，得包try/except - 性能影响小，单次查询毫秒级；但别在 tight loop 里高频调，加个 1–3 秒间隔更稳妥
进程意外退出后怎么拿到退出码和原因
subprocess.Popen 对象的 returncode 属性只有在进程结束后才有值，而且**不会自动更新**——你得主动调 proc.poll() 或 proc.wait(timeout=...) 才能刷新它。不调就一直为 None，容易误判“还在跑”。
更麻烦的是：进程被信号杀死（比如 SIGKILL）时，returncode 是负的信号编号（如 -9），不是常规退出码，得用 os.WIFSIGNALED 和 os.WTERMSIG 判断。
- 轮询检测时，用
proc.poll() is not None判断是否结束，再读proc.returncode - 若
returncode ，说明被信号终止：<code>signal_name = signal.Signals(-returncode).name - 别依赖
proc.stdout.read()获取日志来判断成败——进程崩溃时 stdout 可能缓冲未刷出，日志为空但其实挂了
pid_exists 或 returncode 不够，得把启动时间、信号类型、进程状态字符串三者串起来看，才能真正确认“它是不是按你预期的方式活着”。 
