最可靠方式是通过readlink -f /proc//exe获取进程绝对路径，因ps仅显示命令名，which/whereis依赖当前环境且不覆盖虚拟环境或自定义路径；辅以/proc//cmdline和/proc//cwd可完整还原运行上下文。
ps + /proc/PID/exe 是最可靠的方式
直接看 ps 输出的命令名（比如只显示 python）根本不能确定它到底跑的是哪个可执行文件，尤其是系统里装了多个 Python 版本、或用了 pyenv、conda 时。真正能拿到绝对路径的，只有 /proc/<pid>/exe</pid> 这个符号链接。
操作分三步：
- 用
ps -ef | grep xxx或pgrep -f xxx拿到目标进程的 PID - 执行
ls -l /proc/<pid>/exe</pid>，输出类似/proc/12345/exe -> /home/user/.pyenv/versions/3.11.9/bin/python - 如果看到
(deleted)后缀，说明该二进制文件已被删除但进程仍在运行——路径仍有效，只是磁盘上已不存在
注意：readlink -f /proc/<pid>/exe</pid> 可以直接输出解析后的绝对路径，省去 ls -l 的解析步骤。
不要依赖 which 或 whereis 查进程路径
which python 返回的是当前 shell 环境下 $PATH 找到的第一个可执行文件，跟正在运行的进程完全无关；whereis python 只查系统预装或包管理器安装的路径，对用户自编译、虚拟环境、容器内进程无效。
常见误判场景：
- 进程是通过绝对路径启动的（如
/opt/myapp/bin/start.sh），ps显示的却是start.sh，which根本查不到 - 进程由 systemd 启动，
ExecStart=配置里用了~/bin/app或环境变量展开，which在当前 shell 下无法还原 -
whereis不会扫描/home或/opt下的自定义安装路径，返回空或错误路径
cmdline 和 cwd 能补全关键上下文
单靠 exe 只知道“程序本体在哪”，但实际运行行为还依赖启动参数和工作目录。这两个信息同样藏在 /proc/<pid>/</pid> 下：
-
cat /proc/<pid>/cmdline</pid>：原始命令行参数，用 \0 分隔，建议用tr '\0' ' ' /cmdline读取 -
ls -l /proc/<pid>/cwd</pid>：指向进程当前工作目录，对调试配置文件加载路径特别有用 - 注意：
cmdline对僵尸进程为空，cwd对某些特权进程（如 init）可能不可读
例如某 Node.js 进程 exe 指向 /usr/bin/node，但 cmdline 显示它实际跑的是 /var/www/app/server.js，而 cwd 是 /var/www/app——这三者缺一不可。
自动化脚本要处理权限和竞态
写一键定位脚本时容易忽略两点：一是非 root 用户访问其他用户进程的 /proc/<pid>/</pid> 目录会被拒绝；二是进程可能在你读取过程中退出，导致 /proc/<pid>/</pid> 目录消失。
稳妥做法：
- 加
2>/dev/null忽略Permission denied和No such file错误 - 用
stat /proc/<pid>/exe && readlink -f /proc/<pid>/exe</pid></pid>组合，避免先查后读的竞态 - 不要用
ps aux --no-headers | awk '{print $2}'提取 PID 后再逐个查——应优先用pgrep精准匹配，减少误杀
真实环境中，/proc 下的符号链接不是“元数据快照”，而是实时内核接口；路径是否有效、能否读取，取决于此刻进程状态和你的权限边界——这点比任何文档都重要。
