which gcc返回空但rpm -qa显示已安装，说明gcc二进制存在但未被PATH包含；需先用rpm -ql gcc | grep bin/确认安装路径（应含/usr/bin/gcc），再检查$PATH是否包含该目录，若缺失则手动添加export PATH="/usr/bin:$PATH"并重载配置。
which gcc 返回空，但 rpm -qa 确实装了 gcc 包
说明 gcc 二进制文件已存在，只是没放进 $PATH 可见路径里。RHEL/CentOS/Fedora 的 gcc rpm 包默认把可执行文件放在 /usr/bin/gcc，但某些最小化安装或容器镜像会禁用该路径的自动加载。
先确认文件是否存在：ls -l /usr/bin/gcc
如果返回“没有那个文件”，再查包实际安装位置：rpm -ql gcc | grep bin/
- 若输出是
/usr/libexec/gcc/...这类路径：那是内部驱动程序，不是用户命令，需装完整gcc主包（不是gcc-toolset-xx或gcc-runtime） - 若输出含
/usr/bin/gcc但文件确实不存在：说明包安装异常，尝试rpm -V gcc校验完整性 - 若
/usr/bin不在$PATH中（比如只含/bin:/usr/local/bin）：手动补上，export PATH="/usr/bin:$PATH"
Windows 下 where gcc 找不到，但 C:\msys64\mingw64\bin\gcc.exe 确实存在
这是 PATH 注入失败的典型表现——路径加了，但没生效，或者被覆盖。
关键检查点：
- 确认添加的是「系统变量」PATH，不是「用户变量」；后者优先级低于前者，且 VSCode 启动时可能不继承
- 路径末尾不要加反斜杠：
C:\msys64\mingw64\bin\❌，应为C:\msys64\mingw64\bin✅ - 路径含空格或中文时，CMD 无法解析（PowerShell 可能侥幸通过，但不可靠），必须重装到纯英文无空格路径，如
C:\mingw64 - 改完 PATH 后，**必须重启所有已打开的终端和 VSCode 实例**；旧进程不会自动 reload 环境变量
Linux/macOS 中 echo $PATH 显示路径正确，gcc 仍报 command not found
问题往往出在 Shell 初始化机制上：你改了 ~/.bashrc，但当前终端跑的是 zsh，或者用了 su 切换用户后没加载配置。
快速定位方式：
- 运行
ps -p $$看当前 shell 类型（bash/zsh/dash） - 对应检查配置文件：
~/.bashrc、~/.zshrc、/etc/profile，确认export PATH=...行已存在且未被注释 - 临时测试：在当前终端直接运行
source ~/.zshrc（或对应文件），再试gcc --version - 注意：SSH 登录或
sudo -i会读取/root/.bash_profile而非.bashrc，容易漏配
arm-none-eabi-gcc 或 xtensa-esp32-elf-gcc 找不到，但工具链目录分明有 bin 子目录
交叉编译器几乎从不自动加入 PATH，且路径常带版本号，极易手误。
常见疏漏：
- 只加了
/opt/gcc-arm-none-eabi，漏掉/bin后缀；正确路径是/opt/gcc-arm-none-eabi/bin - ESP-IDF 工具链默认装在
~/.espressif/tools/xtensa-esp32-elf/esp-2023r1-8.4.0/xtensa-esp32-elf/bin这类嵌套很深的路径，不能只加到tools层 - 脚本中用
$(pwd)/bin动态拼路径，但当前工作目录变了，导致失效；应使用绝对路径 - 某些 IDE（如 PlatformIO）会覆盖 PATH，需在项目设置里单独指定工具链路径，不能只依赖系统环境变量
