最直接可靠的方式是用ls -l /proc/pid/exe查看符号链接指向的绝对路径，如/proc/10837/exe -> /usr/local/nginx/sbin/nginx；若显示(deleted)说明文件已被删但进程仍在运行；需配合cat /proc/pid/cmdline | tr '\0' ' '和pwdx pid分别获取启动参数和工作目录，三者结合才能完整还原进程上下文。
怎么用 /proc/<pid>/exe</pid> 看真实可执行文件路径
这是最直接、最可靠的方式，/proc/<pid>/exe</pid> 是一个符号链接，指向进程启动时实际加载的二进制文件（不是软链接目标，而是最终解析后的绝对路径）。
- 先用
ps aux | grep xxx或pgrep -f xxx拿到 PID，比如 nginx 主进程 PID 是10837 - 执行
ls -l /proc/10837/exe，输出类似lrwxrwxrwx 1 root root 0 Jul 9 01:20 /proc/10837/exe -> /usr/local/nginx/sbin/nginx - 注意：如果看到
(deleted)后缀，说明可执行文件已被删除但进程仍在运行——这本身就是一个异常信号 - 普通用户对其他用户的
/proc/<pid>/exe</pid>可能无读权限，Permission denied不代表路径不存在，而是权限受限
/proc/<pid>/cmdline</pid> 里藏着启动参数，但得先“解码”
/proc/<pid>/cmdline</pid> 存的是原始 argv 数组，用 <p><code>/proc/<pid>/cmdline</pid> 存的是原始 argv 数组，用 \0 分隔，直接 cat 出来是乱码或空行。必须转换才能看清真实命令行。
cat 出来是乱码或空行。必须转换才能看清真实命令行。
- 正确做法是：
tr '\0' ' ' —— 把每个 <code>\0换成空格，参数就可读了 - 常见陷阱：如果进程是用 shell 脚本包装启动的（比如
java -jar app.jar），这里显示的是完整命令，包括 JVM 参数和 jar 路径 - 僵尸进程（
Z状态）的cmdline为空，别白费力气读 - 某些容器内进程或特权进程（如
init、systemd）可能因内核限制返回空内容
/proc/<pid>/cwd</pid> 和 pwdx 告诉你它从哪开始跑
工作目录（cwd）不是可执行路径，但它决定了配置文件、日志、相对路径资源的加载位置，调试时经常比 exe 更关键。
-
ls -l /proc/10837/cwd显示符号链接目标，比如-> /var/www/app - 更省事用
pwdx 10837，直接输出10837: /var/www/app - 对 setuid 进程（如
sudo启动的子进程），cwd可能被内核隐藏，pwdx会报Permission denied - 如果 cwd 指向
/或/tmp，要警惕非标准部署或临时拉起的可疑进程
为什么不用 ps 或 top 查路径
ps aux 的 COMMAND 列只显示 basename（如 node、java），不带路径；top 同理。它们本质是读取 /proc/<pid>/comm</pid>（进程名）和部分 cmdline，做了截断和简化。
-
ps -o pid,comm,args -p 10837中的args字段确实来自 cmdline，但默认会截断超长参数，且仍需手动处理 \0 -
lsof -p 10837 -F n | grep '^n'能列出打开的文件，但 exe 不一定在其中 —— 它只列“已打开”的文件，而可执行文件在 mmap 后可能已关闭 fd - 真正要确认“这个 java 进程到底跑的是哪个 jar”，光看
ps输出的java没用，必须结合cmdline解码后的内容
exe、cmdline、cwd 三者得一起看：exe 告诉你用了哪个二进制，cmdline 告诉你带什么参数启动，cwd 告诉你它认为自己在哪。少一个，结论就可能偏差。
