/proc/PID/exe 是唯一可信的真实可执行路径来源，因其为内核维护的符号链接，不受环境变量、PATH或别名影响；而ps仅显示argv[0]（如python），无法区分/pyenv/3.11.9/bin/python或/opt/node-v20/bin/node，且在pyenv/conda/nvm等环境下完全脱钩；需配合/proc/PID/cmdline和/proc/PID/cwd才能完整还原运行上下文。
/proc/PID/exe 是唯一能拿到真实可执行路径的入口，其他方法全都不靠谱。
为什么 ps 显示的路径不能信
它只存启动时的命令名，比如 python 或 node，根本不管实际跑的是 /home/user/.pyenv/versions/3.11.9/bin/python 还是 /opt/node-v20/bin/node。尤其在用 pyenv、conda、nvm 时，ps 输出和真实二进制完全脱钩。
常见错误现象：
-
ps -p 1234 -o comm,args输出python /app/main.py，但你没法知道这个python到底是哪个 - 进程用绝对路径启动（如
/opt/myapp/bin/runner），ps有时反而只显示runner，丢掉前缀 - 脚本类进程（
bash/sh）更危险：ps显示/bin/bash，但真正逻辑在/etc/init.d/myapp里——得靠/proc/PID/cmdline补全
怎么用 /proc/PID/exe 拿到绝对路径
这是内核维护的符号链接，指向进程加载的原始二进制或解释器，不受环境变量、别名、PATH 干扰。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
实操建议：
- 先用
pgrep -f xxx或ps -ef | grep xxx拿到 PID - 执行
readlink -f /proc/1234/exe，直接输出解析后的绝对路径（推荐，一步到位） - 或用
ls -l /proc/1234/exe，输出形如/proc/1234/exe -> /usr/local/bin/nginx - 如果看到
(deleted)后缀，说明文件已被删但进程还在跑——路径仍有效，只是磁盘上没了
/proc/PID/cmdline 和 /proc/PID/cwd 必须一起查
/proc/PID/exe 告诉你“程序本体在哪”，但运行行为还取决于“它被怎么调用”和“它在哪起家”。这三者缺一不可：
-
cat /proc/1234/cmdline | tr '\0' ' '—— 看完整启动参数，比如java -jar /opt/app.jar --config /etc/app.conf -
pwdx 1234或ls -l /proc/1234/cwd—— 查工作目录，很多程序依赖相对路径加载配置（如./conf/app.yml） - 对 Python/Node.js 类进程：
exe指向解释器，cmdline才暴露真实脚本路径，cwd决定模块导入根目录
哪些方法会误导你，务必避开
which 和 whereis 完全是另一套逻辑，跟正在运行的进程毫无关系。
-
which python查当前 shell 的$PATH，不是进程启动时的PATH；进程可能用了不同 shell、不同用户、甚至修改过environ -
whereis python只扫系统数据库（/usr/bin、/usr/share/man等），漏掉/opt、~/.local/bin、容器内路径 -
lsof -p 1234可能列出txt类型的可执行文件，但结果不稳定：有些进程不保持txtfd，或者被ptrace暂停后就读不到 -
ps的-o pid,comm,args字段在某些内核版本或容器环境下会被截断，参数不全
/proc/PID/exe 是唯一可信源，但必须搭配 cmdline 和 cwd 才能还原完整上下文——少了任何一个，都可能把调试引向错误方向。 
