唯一可靠获取进程绝对路径的方式是读取 /proc//exe 符号链接；需先用 pgrep 或 ps 获取 pid，再执行 readlink -f /proc//exe；若失败说明进程已退出；同时应结合 /proc//cwd、/proc//cmdline 和 systemd execstart= 综合判断真实启动上下文。
直接看 /proc/<pid>/exe</pid> 是唯一靠谱的方式
ps 输出的 COMMAND 列（比如只显示 python 或 node）根本不是启动路径，只是进程名；which 和 whereis 查的是当前 shell 的环境，跟正在跑的进程完全无关——尤其在 pyenv、conda、容器或自定义安装路径下，十次有九次错。
真正能拿到绝对路径的，只有 /proc/<pid>/exe</pid> 这个符号链接。它由内核维护，只要进程活着，链接就有效，哪怕二进制文件已被删除（这时会显示 (deleted)，但路径仍可解析）。
- 先用
pgrep -f your_app或ps -ef | grep your_app拿到 PID - 执行
readlink -f /proc/<pid>/exe</pid>—— 直接输出解析后的绝对路径，不用手动看ls -l的箭头 - 如果返回空或报错
No such file or directory，说明进程已退出，或 PID 不存在
/proc/<pid>/cwd</pid> 和 /proc/<pid>/cmdline</pid> 必须一起看
只看 exe 只知道“程序本体在哪”，但实际行为还取决于它从哪启动、带了什么参数。比如同一个 /usr/bin/python3，在 /home/user/project 下运行和在 /tmp 下运行，导入模块、读取配置的行为可能完全不同。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
readlink -f /proc/<pid>/cwd</pid>给出当前工作目录，等价于进程内部的getcwd() -
cat /proc/<pid>/cmdline | tr '\0' ' '</pid>显示原始启动命令（注意：参数之间用 \0 分隔，必须用tr转义才可读） - 特别注意：如果 cmdline 里第一个参数是绝对路径（如
/opt/myapp/bin/start.sh），那它才是真正的“启动路径”，exe可能只是解释器（如/bin/bash）
别信 ps -o args 或 ps -f 的“完整命令”
ps -p <pid> -o args</pid> 看起来方便，但它展示的是内核保存的 argv[0] 和后续参数的快照，可能被程序自己篡改过（比如 Python 的 sys.argv[0] 可被赋值），也可能被截断（尤其是长命令行 + 小内核缓冲区）。
- 某些守护进程（如 nginx、redis）启动后会主动重写
argv[0]，ps显示的是重写后的名字，不是原始路径 -
ps -eww能缓解截断，但不解决篡改问题；ps e -p <pid></pid>可看环境变量，但和路径无关 - 真正可靠的启动命令，只在
/proc/<pid>/cmdline</pid>里，且未被用户态修改
systemd 服务要额外查 ExecStart=
如果是 systemd 管理的进程，/proc/<pid>/exe</pid> 只告诉你最终执行的是哪个二进制，但不知道它是怎么被拉起来的——比如 /usr/bin/dockerd 是由 docker.service 启动的，而该 unit 文件里可能用了环境变量、~ 展开或 EnvironmentFile。
- 先用
systemctl status <service_name></service_name>找到 Loaded 行，例如Loaded: loaded (/etc/systemd/system/myapp.service; enabled) - 然后
cat /etc/systemd/system/myapp.service，重点看ExecStart=行，它才是“启动路径”的源头 - 注意：如果用了
%i、%f等模板变量，或Environment=定义了路径，得手动展开才能还原真实调用
exe 指向解释器、cmdline 里藏着 shell wrapper、cwd 是临时挂载点、systemd 配置又套了三层变量——这时候得把四个来源交叉比对，缺一不可。
