/proc/pid/exe 是唯一能获取进程真实可执行路径的方法；它由内核维护，指向实际加载的二进制文件，不受 argv[0] 篡改、软链接或假名影响，readlink -f 可解析出绝对路径，若含 (deleted) 表示文件已被删除但进程仍在运行。
直接读 /proc/PID/exe 是唯一能拿到真实可执行路径的方法
ps、top 显示的 COMMAND 列只是进程启动时 argv[0] 的值，可能被篡改、软链接未展开、或根本就是假名（比如攻击者放个 /tmp/sshd 冒充系统服务）。/proc/PID/exe 是内核维护的符号链接，指向进程实际加载的二进制文件，不受环境变量、别名、PATH 或当前 shell 状态影响。
操作步骤：
- 先用
pgrep -f nginx或ps -ef | grep python拿到 PID - 执行
readlink -f /proc/12345/exe—— 这比ls -l /proc/12345/exe更干净，直接输出解析后的绝对路径 - 如果输出末尾带
(deleted)，说明可执行文件已被 rm，但进程仍在内存中运行；路径仍有效，只是磁盘上没了
/proc/PID/cmdline 里存的是原始启动参数，不是人眼友好的格式
cat /proc/12345/cmdline 输出是一整串用 \0（空字符）分隔的字符串，直接 cat 会显示成乱码或只看到第一个词。必须用 tr 或 strings 处理才能还原成可读命令行。
常见做法：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
tr '\0' ' ' ：把 \0 换成空格，最常用-
strings /proc/12345/cmdline：对某些含控制字符的 cmdline 更鲁棒 - 注意：僵尸进程的
cmdline是空的，读出来什么都没有
/proc/PID/cwd 和 pwdx 都能看工作目录，但权限和兼容性不同
进程当前工作目录（cwd）决定相对路径解析行为，比如配置文件加载、日志写入位置。它和可执行路径是两回事，但缺一不可。
两种方式对比：
-
ls -l /proc/12345/cwd：直接看符号链接目标，但部分特权进程（如 systemd、init）会拒绝访问，返回Permission denied -
pwdx 12345：封装好的工具，自动处理权限失败并给出提示，非 root 用户也能在多数普通进程上用 - 二者都可能因进程已退出或权限不足而失败，不能当作兜底方案
别碰 which、whereis、ps aux 查路径，它们全都不反映真实运行态
这些命令查的是“当前 shell 环境下可能找到什么”，不是“这个 PID 正在跑什么”：
-
which python只搜 $PATH，完全忽略 pyenv、conda、绝对路径启动、容器内 PATH -
whereis python只扫标准系统路径（/usr/bin、/usr/lib 等），不查 /opt、/home、/app -
ps aux的 COMMAND 列可能被程序自己修改（prctl(PR_SET_NAME)），也可能只是脚本名而非解释器路径
真正要确认一个进程是否可疑，必须三者对照：readlink -f /proc/PID/exe（它到底是谁）、tr '\0' ' ' （它带什么参数启动）、<code>pwdx PID（它在哪干活）。少一个，就可能漏掉关键线索。
