应修改 ~/.bashrc 添加 export path=/home/username/gcc-12.3.0/bin:$path 并 source 生效，验证需用 g++ -v 编译并运行 hello.cpp，而非仅看 gcc --version。
只给当前用户用，就改 ~/.bashrc
绝大多数场景下，你装的 GCC 是自己下载编译的（比如从源码装了 gcc-12.3.0），路径在 /home/username/gcc-12.3.0/bin 这类个人目录里。这时候改系统级变量毫无必要，反而可能干扰其他用户或系统工具链。
直接编辑自己的 ~/.bashrc，末尾加一行：
export PATH=/home/username/gcc-12.3.0/bin:$PATH
然后运行 source ~/.bashrc 生效。验证：执行 which gcc 应该输出你刚加的路径，gcc --version 显示对应版本。
常见错误：
-
export PATH = /path:$PATH—— 等号前后有空格，bash 会报command not found - 改完没
source，新终端也不生效 ——~/.bashrc只在登录 shell 或显式加载时读取 - 路径写成
/home/username/gcc-12.3.0而不是/home/username/gcc-12.3.0/bin——gcc可执行文件在bin/下，不是根目录
要让所有用户都用新 GCC，才动 /etc/profile.d/
比如你是系统管理员，给服务器统一部署了新版 GCC，并希望普通用户开终端就能用 gcc-12 而不用额外配置。这时不该去改 /etc/profile（它会被很多脚本 source，容易引发连锁副作用），而是走标准做法：在 /etc/profile.d/ 下建一个专属脚本。
例如：
sudo tee /etc/profile.d/gcc12.sh <p>注意：<code>/etc/profile.d/*.sh</code> 文件默认被 <code>/etc/profile</code> 自动 source，所以普通用户下次登录或新开 bash 就能生效。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2639" title="GCC 14.1"><img src="https://img.php.cn/upload/manual/001/431/639/6a7b07a70daf0141.png" alt="GCC 14.1" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/gongju/2639" title="GCC 14.1" class="overflowclass">GCC 14.1</a> <p class="overflowclass">GCC 14.1 官方历史源码包下载入口，适合旧项目兼容、编译环境回退、工具链验证、警告参数差异比对和 C/C++ 构建问题复现等场景使用。</p> </div> <a rel="nofollow" href="/xiazai/gongju/2639" title="GCC 14.1" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div> <p>关键约束：</p>
- 必须是
.sh后缀，且有可执行权限（chmod +x非必需，但建议） - 路径必须真实存在且包含
gcc、g++可执行文件，否则所有用户都会遇到command not found - 不要覆盖
PATH（如写成PATH=/opt/...），必须用$PATH拼接，否则系统命令如ls、cp全挂
C_INCLUDE_PATH 和 LD_LIBRARY_PATH 别乱设全局
头文件和动态库路径不是 PATH，它们只在编译或运行时起作用，且影响范围更隐蔽。比如你把 /opt/mylib/include 加进 CPLUS_INCLUDE_PATH 并全局生效，结果某个用户编译时意外包含了你这个路径下的旧版 vector，导致模板实例化失败 —— 这种问题极难排查。
建议原则：
- 头文件路径（
C_INCLUDE_PATH、CPLUS_INCLUDE_PATH）按项目设，在Makefile或cmake中用-I更安全 - 动态库路径（
LD_LIBRARY_PATH）只在运行特定程序时临时加，比如LD_LIBRARY_PATH=/opt/gcc-12.3.0/lib64 ./myapp - 真要系统级注册库路径，用
/etc/ld.so.conf.d/gcc12.conf+sudo ldconfig，而不是环境变量
验证时别只信 gcc --version
很多人改完 PATH 就跑 gcc --version，看到版本对了就以为万事大吉。但实际编译时可能报错：
-
fatal error: bits/c++config.h: No such file or directory——CPLUS_INCLUDE_PATH或 GCC 自带 include 路径没对上 -
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file—— 新版 GCC 的libstdc++.so.6没被 runtime 找到，LD_LIBRARY_PATH或/etc/ld.so.cache缺失
真正可靠的验证方式是：写个最小 hello.cpp，用 g++ -v hello.cpp -o hello（加 -v 看完整搜索路径），再 ./hello 运行成功。
最容易被忽略的一点：GCC 的 include 和 lib 路径，是由它编译时的 --prefix 决定的，和你放 bin 的位置无关。所以即使 PATH 对了，如果 libstdc++.so.6 在 /opt/gcc-12.3.0/lib64，而 ldconfig 没扫到那里，运行时照样崩。
