最可靠方式是执行readlink -f /proc/PID/exe获取进程真实可执行文件绝对路径，因ps仅显示命令名、which/whereis依赖当前环境且不覆盖虚拟环境或自定义路径；辅以/proc/PID/cmdline和/proc/PID/cwd可完整还原运行上下文。
怎么拿到进程真正的可执行文件绝对路径
只靠 ps 输出的命令名（比如 python 或 node）根本不能确定它到底跑的是哪个二进制文件。系统里装了多个 Python、用了 pyenv 或 conda、或者进程是用绝对路径启动的，ps 都不显示真实路径。
唯一可靠的方式是读取 /proc/<pid>/exe</pid> 这个符号链接：
- 先用
pgrep -f xxx或ps -ef | grep xxx拿到 PID - 执行
readlink -f /proc/<pid>/exe</pid>，直接输出解析后的绝对路径 - 如果看到
(deleted)后缀，说明文件已被删但进程还在跑——路径仍有效，只是磁盘上没了
为什么不能用 which 或 whereis 查进程路径
which python 返回的是当前 shell 的 $PATH 下第一个匹配项，跟正在运行的进程完全无关；whereis python 只扫系统包管理器安装路径（如 /usr/bin、/usr/local/bin），对用户自建路径（~/miniconda3/bin、~/.pyenv/versions/3.11.9/bin）或容器内路径无效。
常见失效场景：
- 进程由 systemd 启动，
ExecStart=/opt/myapp/bin/start.sh，ps显示start.sh，which根本查不到 - 脚本里用了
#!/usr/bin/env python3，实际运行的是虚拟环境里的python，which返回系统默认版本 - 进程在 Docker 容器里，宿主机的
which完全不适用
工作目录和完整命令行怎么一起看
/proc/<pid>/exe</pid> 只告诉你“程序本体在哪”，但启动行为还依赖工作目录和参数。这三个信息必须一起看才完整：
- 工作目录：
readlink -f /proc/<pid>/cwd</pid>（或用pwdx <pid></pid>） - 完整命令行：
cat /proc/<pid>/cmdline | tr '\0' ' '</pid>（注意参数间用 \0 分隔，不是空格） - 环境变量：
cat /proc/<pid>/environ | tr '\0' '\n' | grep ^PATH=</pid>，能帮你理解为什么exe指向那个路径
例如一个 Python 进程的 exe 指向 ~/.pyenv/versions/3.11.9/bin/python，但 cwd 是 /home/user/project，cmdline 里带 --config config.yaml，三者合起来才是真实上下文。
权限和兼容性要注意什么
读取 /proc/<pid>/exe</pid> 和 /proc/<pid>/cwd</pid> 需要能访问目标进程的 /proc 子目录——通常要求你是进程所有者或 root。普通用户查自己启动的进程没问题，查别人（尤其是 root 进程）会 Permission denied。
另外：readlink -f 在旧版 BusyBox 或某些嵌入式系统里可能不支持 -f 选项，这时得用 ls -l /proc/<pid>/exe</pid> 手动解析箭头后面的路径，再处理软链嵌套。
最常被忽略的一点：进程刚 fork 出来还没 exec 的瞬间，/proc/<pid>/exe</pid> 会指向 /proc/<pid>/exe (deleted)</pid> 或报错，这不是异常，而是生命周期状态——此时看 cmdline 和父进程更靠谱。
