系统使用PATH中第一个找到的gcc可执行文件；例如PATH=/usr/bin:/opt/gcc-12/bin:/opt/gcc-11/bin时，实际运行的是/usr/bin/gcc，严格按顺序匹配而非随机或按版本选择。
PATH里混着多个gcc可执行文件，哪个会被用？
系统只认PATH里**第一个找到的gcc**。比如PATH=/usr/bin:/opt/gcc-12/bin:/opt/gcc-11/bin，即使后两个目录里都有gcc，实际运行的永远是/usr/bin/gcc——因为它是路径列表里最先被扫描到的。
这不是“随机选”，而是严格按PATH顺序匹配。很多人误以为which gcc返回的是“最新版”或“安装时间最近的”，其实它只是告诉你当前PATH顺序下第一个命中项的位置。
- 用
echo $PATH确认顺序，别靠猜 - 用
type -a gcc列出所有可访问的gcc（含别名、函数），看清全貌 - 如果
/usr/bin/gcc是软链接（如指向gcc-11），type -p gcc和readlink -f $(which gcc)才能看到真实路径
CC/CXX环境变量比PATH优先级高吗？
不直接比较优先级，而是看谁被构建系统读取。对make、cmake、autotools这类工具来说，CC和CXX是**显式覆盖信号**，它们会直接忽略PATH里的gcc，改用你指定的路径或命令。
但注意：这个覆盖只在当前构建过程生效，不影响终端里敲gcc --version的结果。
-
CC=gcc-12 CXX=g++-12 make：临时生效，仅本次make -
export CC=/opt/gcc-12/bin/gcc：当前shell及其子进程都生效 -
cmake -DCMAKE_C_COMPILER=/opt/gcc-12/bin/gcc ..：CMake明确绑定，比环境变量更可靠 - 如果
CC设成gcc-12但PATH里没有该命令，构建会直接失败——它不会回退到PATH找gcc
update-alternatives和PATH冲突怎么处理？
update-alternatives本质是管理/usr/bin/gcc这个符号链接的指向，它本身不修改PATH。所以当你运行gcc时，系统先查PATH，发现/usr/bin在前，再进去找gcc这个文件——而它恰好是个软链接，最终跳转到/usr/bin/gcc-12之类的真实路径。
真正冲突的点在于：如果你同时把/opt/gcc-12/bin加进PATH且排在/usr/bin前面，那update-alternatives就完全失效了。
- 想用
update-alternatives统一管理？确保/usr/bin在PATH中位置靠前，别手动前置其他编译器目录 - 想项目级隔离？干脆不碰
update-alternatives，用CC或CMake参数指定绝对路径 - 检查是否被绕过：
ls -l /usr/bin/gcc看是不是软链接；which gcc输出是否等于/usr/bin/gcc
Mac上Homebrew装的gcc-14为什么不能直接用gcc？
Homebrew默认不创建/usr/local/bin/gcc软链接，而是安装为gcc-14、g++-14等带版本号的独立命令。这是刻意为之的设计：避免和Xcode自带的clang（它也响应gcc命令）打架，也防止覆盖系统行为。
如果你硬要gcc指向Homebrew版本，得自己加软链接，但必须清楚后果：
-
sudo ln -sf /opt/homebrew/bin/gcc-14 /usr/local/bin/gcc（Intel Mac用/usr/local） -
sudo ln -sf /opt/homebrew/bin/gcc-14 /opt/homebrew/bin/gcc（M1/M2 Mac推荐，不越权） - 加完立刻验证：
gcc --version和which gcc，别信记忆 - 一旦出问题，删掉软链接即可恢复，但别用
brew unlink gcc——它可能连带删掉gcc-14
最稳的方式其实是放弃全局gcc别名，直接在项目里用CC=gcc-14或CMake配置。多打几个字，换来的是确定性。
