which和whereis仅返回二进制路径，无法反映真实部署结构；应优先用包管理命令（如dpkg -L、rpm -ql）或进程信息（/proc/PID/cmdline、readlink -f /proc/PID/exe）定位配置与安装路径。
直接看 which 返回的路径，只是可执行文件位置，不是整个程序的安装路径——它不告诉你配置在哪、模块在哪、数据目录在哪，甚至可能根本不是你正在运行的那个版本。
which 和 whereis 只能查二进制，别当真
它们返回的是 PATH 搜索结果或预设目录扫描结果，不代表真实部署结构：
-
which nginx可能返回/usr/sbin/nginx，但实际配置在/etc/nginx、日志在/var/log/nginx、模块在/usr/lib/nginx -
whereis nginx输出里带/etc/nginx和/usr/share/nginx，但线上环境这些路径常被软链接覆盖（比如/etc/nginx → /data/conf/nginx） - 源码编译安装的程序（如
/opt/myapp/bin/app）通常不在 PATH 里，which找不到；whereis也大概率不收录
包管理器命令才是可信来源（仅限包安装）
如果你确认是用 apt/yum/dnf/rpm 装的，就别猜了，直接查包记录：
- Debian/Ubuntu：
dpkg -L nginx列出所有安装文件路径；dpkg -S $(which nginx)确认该二进制属于哪个包 - RHEL/CentOS/Fedora：
rpm -ql nginx查完整路径列表；rpm -qf $(which nginx)反查包名 - 注意：这些命令对
make install、./install.sh、AppImage、Snap 安装的软件完全无效
进程运行时路径才是真相
程序正在跑，它的实际路径和配置来源就藏在进程信息里：
- 先找 PID：
pgrep -f 'nginx: master'或pidof nginx - 看启动命令：
cat /proc/<pid>/cmdline | tr '\0' ' '</pid>，重点找-c、--config、--prefix这类参数 - 看真实二进制路径：
readlink -f /proc/<pid>/exe</pid>，比which更准，能绕过 alias 或 wrapper 脚本
全盘搜索是最后手段，但得会过滤
当以上都失效（比如你接手一台老服务器，没人知道软件怎么装的），就只能扫：
-
sudo find / -path '/proc' -prune -o -name 'nginx*' -type d 2>/dev/null—— 扫目录名，避开/proc避免卡死 -
sudo locate nginx.conf 2>/dev/null—— 快，但依赖updatedb，可能滞后 - 慎用
find / -name 'nginx' 2>/dev/null，容易刷屏；加-type f -executable或-type d明确目标类型
最常被忽略的一点：同一个名字的程序，可能有多个副本共存——PATH 里的、/usr/local 下自己编译的、容器里挂载的、甚至当前 shell 的 alias。不结合进程上下文看，光查路径等于盲人摸象。
