问题在于多个gcc路径共存导致shell优先调用旧版本，而非PATH未生效；需检查alias/函数劫持、update-alternatives符号链接优先级、CC环境变量及cc软链一致性。
你改了PATH，但gcc --version还是旧版本——问题不在环境变量没生效，而在系统有多个gcc路径，shell优先找到了老的那个。
为什么gcc --version和which gcc结果不一致
常见现象：明明把新gcc的/usr/local/bin加到了PATH最前面，gcc --version却仍显示4.8.5；但which gcc却指向/usr/local/bin/gcc。这是因为某些shell（尤其是zsh）会缓存命令路径，或系统存在alias/函数覆盖。
- 运行
type -a gcc，看是否输出多行——如果有gcc is aliased to ...或gcc is a function，说明被别名或函数劫持了 - 检查
~/.bashrc、~/.zshrc里有没有alias gcc=/usr/bin/gcc这类硬编码 -
command -v gcc比which gcc更可靠，它绕过alias和function
update-alternatives配置后重启终端失效
Debian/Ubuntu系用update-alternatives --config gcc设完，新开终端又回退——不是配置失败，而是update-alternatives只改/usr/bin/gcc这个符号链接，而你的shell PATH里可能有更高优先级的路径（比如/usr/local/bin），导致根本没走到/usr/bin/gcc。
- 先执行
ls -l /usr/bin/gcc确认链接是否已更新到目标版本 - 如果PATH含
/usr/local/bin且该目录下有gcc，它永远优先于/usr/bin/gcc - 解决办法二选一：
sudo rm /usr/local/bin/gcc（删冲突项），或把/usr/local/bin从PATH中移除
Windows下MinGW-w64的gcc被系统自带gcc.exe干扰
装完MinGW-w64，gcc -v却报错或显示奇怪版本——极大概率是Windows SDK、TDM-GCC、旧版Code::Blocks甚至Git for Windows自带的gcc.exe混在PATH里，且排位更前。
- 执行
where gcc（Windows命令行），它会列出所有匹配的gcc.exe路径，按顺序取第一个 - 逐个检查每个路径下的
gcc -v输出，找到真正想用的那个 - 把MinGW-w64的
bin目录（如C:\mingw64\bin）移到PATH最顶端，或干脆删掉其他GCC路径 - 特别注意：Git安装时默认勾选“Add Git to PATH”，它带的
usr\bin\gcc.exe常造成干扰
Go/CMake等工具仍调用旧gcc
go build或cmake ..报C compiler not found，或编译失败——这些工具通常不走shell的PATH查找逻辑，而是依赖CC环境变量或硬编码路径。
- Go默认用
cc命令，不是gcc；运行which cc，很可能它还连着旧版gcc。临时修复：CC=gcc-11 go build - CMake默认查
gcc，但若缓存了旧结果，rm -rf build/ && cmake ..才能重检编译器 - 某些项目（如Swoole）的
configure脚本会检测cc而非gcc，务必同步软链：sudo ln -sf /usr/local/bin/gcc /usr/bin/cc
最麻烦的点不是找不到gcc，而是多个gcc共存时，不同工具链各认各的“gcc”——shell、update-alternatives、CC变量、cc软链、cmake缓存，五条线并行，漏一条就崩。动手前先跑一遍which gcc && which cc && type -a gcc && echo $PATH，把实际调用链摸清再说。
