/proc/pid/exe 是最直接、最可靠的路径来源，它由内核维护，指向进程实际加载的可执行文件，不受重命名、移动或环境变量影响；ps、cmdline、which等均无法替代，需配合/proc/pid/cwd和/proc/pid/cmdline才能完整还原运行上下文。
/proc/<pid>/exe</pid> 是最直接、最可靠的路径来源，它指向进程实际加载的可执行文件。其他方法（如 ps、cmdline）只给命令名或启动参数，不能替代它。
为什么 /proc/<pid>/exe</pid> 是首选
这个符号链接由内核维护，只要进程还在运行，readlink /proc/<pid>/exe</pid> 就能返回真实可执行文件的绝对路径——哪怕它被重命名、移动过，只要没被 execve() 替换，链接仍有效。ps -f -p <pid></pid> 显示的 args 字段可能只是 /usr/bin/python，但真正跑的是 /opt/myapp/venv/bin/python；cmdline 里藏的是脚本路径，不是解释器本身。
-
readlink -f /proc/<pid>/exe</pid>自动解析软链嵌套（比如指向/usr/bin/java，而它又软链到/etc/alternatives/java） - 对僵尸进程无效（
exe不可用），但正常运行的进程基本都支持 - 需有读取权限：普通用户只能查自己启动的进程；查系统进程需 root 或
ptrace权限
pwdx 和 /proc/<pid>/cwd</pid> 查的是工作目录，不是执行路径
很多人误把 pwdx <pid></pid> 或 readlink /proc/<pid>/cwd</pid> 当作“执行路径”，其实它只是进程当前 chdir() 的位置，和可执行文件所在路径无关。比如一个在 /tmp 启动的 nginx，cwd 是 /tmp，但 exe 仍是 /usr/sbin/nginx。
-
pwdx <pid></pid>更简洁，但输出格式固定（<pid>: <path></path></pid>），不适合脚本解析 -
readlink -f /proc/<pid>/cwd</pid>返回绝对路径，可用于调试配置文件加载逻辑（比如读取./config.yml时实际找的是哪一版） - 某些特权进程（如
init、容器 init 进程）的cwd可能不可读，返回Permission denied
lsof -p <pid></pid> 的 txt 类型文件不等于可执行路径
lsof -p <pid></pid> 输出中带 txt 标记的行常被当作“执行文件”，但它只是当前映射为代码段的文件——可能是主二进制，也可能是动态库（如 libc.so.6），甚至是个被 mmap(PROT_EXEC) 加载的 JIT 编译块。
- 真正要找可执行文件，只认
COMMAND列 +txt行里NAME字段路径，且FD是txt、TYPE是REG、SIZE/OFF非零 - Java、Node.js 等运行时进程，
txt行大概率是 JVM 或node二进制，不是你写的.jar或server.js——后者得看cmdline -
lsof需要cap_sys_ptrace或 root 权限，普通用户查不到其他用户的进程
别依赖 ps -o args 或 cmdline 推断执行路径
ps -p <pid> -o args</pid> 和 cat /proc/<pid>/cmdline | tr '\0' ' '</pid> 给出的是启动时传入的 argv[0] 和参数，不是可执行文件路径。argv[0] 可以被任意伪造，比如 execve("/tmp/malware", ["sshd", "-D"], ...)，ps 会显示 sshd -D，但真实路径是 /tmp/malware。
- Shell 脚本启动时，
cmdline显示的是解释器路径 + 脚本路径（如/bin/bash /home/user/deploy.sh），这时exe是/bin/bash，不是脚本本身 - 容器环境里，
cmdline常是/bin/sh -c ...，真实业务程序得靠exe链接再层层追溯 -
cmdline对僵尸进程为空，ps可能显示[defunct]，此时只有exe（如果还存在）能提供线索
/proc/<pid>/exe</pid> 本身不包含启动参数或工作目录，它只是那个被 execve() 加载的文件。真要还原完整上下文，得组合 exe、cwd、cmdline 三者——少一个，就可能把 /usr/local/bin/python 和 /opt/app/main.py 的关系搞错。
