which找不到命令时，先确认PATH是否包含对应目录；它只搜索PATH中首个可执行文件，不识别alias、builtin等，查不到应优先用type -a或command -v诊断。
which 命令找不到命令时，先确认 PATH 是否包含对应目录
执行 which ls 却返回空，不代表命令不存在，而是当前 PATH 没有包含它所在的目录。比如你装了 python3.12 到 /opt/python/bin，但该路径没加进 PATH，which python3.12 就查不到。
这时应该先运行 echo $PATH，检查输出里有没有目标目录；再用 ls /opt/python/bin/python3.12 确认文件真实存在。常见漏掉的路径包括：/usr/local/bin、~/bin、/snap/bin（尤其 Ubuntu 的 snap 应用）。
whereis 和 type 的结果为什么不一样
whereis 查的是二进制、源码和 man 手册三类文件的默认安装位置，不依赖 PATH，也不检查可执行权限；而 type 严格按 PATH 顺序查找，并能区分 alias、function、builtin 和外部命令。
-
whereis git可能返回/usr/bin/git /usr/share/man/man1/git.1.gz—— 它只是“知道”这些路径存在 -
type -a git会列出所有匹配项，比如git is /usr/bin/git和git is aliased to git --no-pager -
type git（不带-a）只显示最终被调用的那个，也就是实际执行的路径
命令在 PATH 里却 still not found？检查这几个点
即使 echo $PATH 显示路径已存在，仍可能报 command not found，原因常是：
- 路径拼写错误：比如写成
export PATH=$PATH:~/mytools，但实际目录是~/bin/mytools，波浪号~在双引号外才展开，写进配置文件时建议用$HOME - 权限问题：目标文件没有
x（执行）权限，运行ls -l /path/to/cmd看是否含x - 架构不匹配：比如在 x86_64 系统上放了个 aarch64 编译的二进制，
file /path/to/cmd可验证 - 动态链接缺失：
ldd /path/to/cmd报not found的库，会导致即使路径对也执行失败
想查某个命令到底从哪来，优先用 type -p
type -p 是最轻量、最可靠的方式，它只输出可执行文件的绝对路径，不带多余信息，适合脚本中使用。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
例如：
type -p curl # 输出：/usr/bin/curl <p>type -p node</p><h1>如果是 nvm 管理的版本，可能输出：/home/user/.nvm/versions/node/v20.15.0/bin/node</h1><p>
注意：type -p 不会返回 alias 或 function，只关心实际可执行路径；如果什么都没输出，说明该命令不在 PATH 中，或根本未安装。
PATH 的搜索逻辑本身很简单，但真实环境中常被 shell 初始化顺序、子 shell 继承、权限和二进制兼容性层层叠加。最容易被忽略的是：修改 ~/.bashrc 后忘了 source ~/.bashrc，或者在非登录 shell（如 VS Code 内置终端）里 PATH 并未加载完整配置。
