which只查path中首个可执行文件，whereis还搜源码和手册但数据库可能过期；真实路径需通过/proc/pid/exe和cmdline确认，再结合dpkg/rpm溯源，最后用find/locate兜底。
直接看 which 和 whereis 不够准，尤其对源码编译、容器化或改过启动参数的程序——得结合进程实际加载路径交叉验证。
查可执行文件路径：which vs whereis 的真实差异
which 只搜 $PATH 里第一个匹配的可执行文件，不关心配置、手册页或库；whereis 则会列出二进制、源码、man 手册三类路径（如果存在），但它的数据库可能过期或不全。
-
which nginx返回/usr/sbin/nginx—— 这只是你敲命令时调用的那个文件，未必是服务真正跑的二进制 -
whereis nginx可能返回nginx: /usr/sbin/nginx /etc/nginx /usr/share/nginx—— 其中/etc/nginx是包安装时的默认配置目录，上线后大概率被覆盖或软链到别处 - 两者都可能漏掉非 PATH 安装的程序，比如
/opt/myapp/bin/app或用户自己编译装在/usr/local/下但没加进 PATH 的二进制
确认运行时真实路径：从进程反推
程序一旦运行起来，它的实际二进制路径和配置路径就固化在进程信息里，比静态命令更可靠。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 先找主进程 PID：
pgrep -f 'nginx: master'（注意加-f防止只匹配到 worker） - 查它加载的二进制：
ls -l /proc/<pid>/exe</pid>，输出类似/usr/local/nginx/sbin/nginx -> /usr/local/nginx/sbin/nginx，这才是真路径 - 查它用的配置文件：
sudo cat /proc/<pid>/cmdline | tr '\0' '\n' | grep -E '^-[cC]'</pid>，若输出-c参数，后面跟的就是生效配置路径 - 若没加
-c，运行nginx -t（注意用服务同用户执行），看输出里的using configuration file行
按包管理器溯源：避免误判安装方式
很多问题出在“以为是 apt 装的，其实是自己编译的”，结果去查 dpkg -L 白忙活。必须先验明正身。
- Debian/Ubuntu：
dpkg -S $(which nginx) 2>/dev/null，有输出说明走包管理器；没输出但which nginx有结果，大概率是手动安装 - RHEL/CentOS：
rpm -qf $(which nginx) 2>/dev/null，同理判断 - 如果
which找不到，但command -v nginx能返回路径（如/usr/local/nginx/sbin/nginx），基本可断定是源码或脚本安装 - 查包管理器记录的全部文件：
dpkg -L nginx或rpm -ql nginx，仅作参考——这些路径是安装时写的，不是运行时用的
绕不开的硬核兜底：用 find 或 locate 全盘扫
当以上方法全失效（比如程序刚解压还没运行、PATH 没设、包名记错），就得上暴力搜索。
-
sudo find / -type f -name "nginx" -executable 2>/dev/null—— 加-executable筛选有执行权限的文件，比单纯-name更准 -
locate nginx | grep -E '(bin|sbin|local|opt)'——locate快但依赖数据库，记得先sudo updatedb - 慎用
find / -name "*mysql*"这种模糊搜，容易命中日志、备份、临时文件，加-type f和-executable能大幅减少干扰 - 搜索结果里优先看
/usr/local/、/opt/、/home/xxx/这些非标准路径，包管理器一般不会往这儿写
最常被忽略的一点：同一个程序名可能对应多个二进制（比如系统自带的 /usr/bin/python3 和用户装的 /usr/local/bin/python3），which 只返回第一个，type -a python3 才能看到全部。别急着下结论，先 type -a 看清全貌。
