命令找不到先别急着重装：用 which、type 和 PATH 把命令解析讲清楚

终端里输入一个命令，系统回一句“command not found”，很多人第一反应是软件没装好，于是重新安装一遍。重装有时候确实能好，但更多时候问题根本不在安装：软件明明已经装了，只是 Shell 找不到它；或者找到了一个同名的旧版本，跑出来的行为和预期完全不一样。先把“命令是怎么被找到的”讲清楚，再决定是装、是改路径还是改别名，顺序不能反。which、type 和 PATH，就是干这件事最顺手的三个工具。

第一步是先用 type 看 Shell 到底会执行什么。type 命令名会告诉你它是一个外部程序、一个 Shell 内置命令、一个别名，还是一段函数定义。这一点很关键：同一个名字可能对应好几种东西，而 Shell 有自己的优先级——别名和函数往往排在外部程序前面。你以为在跑系统自带的工具，实际上跑的可能是自己多年前写的一个别名，参数和行为早就变了。先看 type 的结果，再谈后面的排查，否则很容易在错误的层面上折腾。

第二步是用 which 确认外部程序的真实位置。which 会沿着 PATH 里的目录一个一个找，告诉你第一个匹配的可执行文件在哪里。如果 which 什么都找不到，说明这个程序确实不在 PATH 覆盖的范围内；如果找到的位置和你以为的安装位置不一样，说明 PATH 里排在前面的目录里有一个同名程序，系统优先用了它。很多“明明装了新版，跑起来还是旧版”的问题，根源都在这里：旧版本的可执行文件还躺在某个靠前的目录里，新版本装到了后面，永远轮不到它。

第三步是把 PATH 本身读出来。echo $PATH 会得到一串用冒号隔开的目录，Shell 就是按这个顺序找命令的。排查时要看三件事：一是程序所在的目录在不在这串目录里；二是有没有拼错目录、写了相对路径，或者目录本身已经被删掉了；三是顺序有没有问题，测试用的目录是不是排在了正式目录前面。临时验证可以用 PATH=$PATH:/新目录 的方式追加，确认有效后再写进 Shell 的启动文件，而不是每次都手动敲一遍。

第四步是区分“这次找不到”和“每次都找不到”。只在当前终端里找不到，换个终端就好了，多半是当前 Shell 的环境变量被改过，或者启动文件没有加载；每次打开终端都找不到，就要看启动文件里有没有正确设置 PATH，设置是写在了登录 Shell 才会读的文件里，还是写在了交互 Shell 才会读的文件里。把这两种情况分开，改的地方才不会错。

最后提醒一个常见误区：不要一上来就把系统目录的程序复制到别处，或者用绝对路径绕过去凑合用。复制出来的程序时间一长就和原版脱节，升级之后还在跑旧副本；绝对路径虽然能跑，却掩盖了 PATH 配置本身的问题。先把 type、which 和 PATH 的结果摆出来，命令找不到的原因往往一眼就能看出来，修起来也只需要改一行配置，而不是重装整个软件。