修改path会影响所有子进程的命令查找行为，将gcc的bin目录加入path不仅使gcc可用，还会影响make、cmake、python subprocess等调用；路径顺序错误可能导致旧版本gcc被优先使用，引发编译失败或二进制不兼容。
修改PATH会影响所有子进程的命令查找行为
把GCC的bin目录（比如/usr/local/gcc-13.2.0/bin或C:\mingw64\bin）加进PATH，不是只让gcc命令可用，而是让整个shell会话及其启动的所有程序——包括make、cmake、python调用的subprocess.run(['gcc', ...])——都可能用上这个GCC。一旦路径顺序不对，旧版本GCC可能被优先命中，导致编译失败或生成不兼容的二进制。
- Linux/macOS下用
export PATH="/path/to/gcc/bin:$PATH"，$PATH必须保留，否则ls、cd等基础命令会失效 - Windows中添加到系统级
PATH后，所有CMD/PowerShell/IDE（如VS Code终端）都会继承该设置，但重启终端才生效 - 多个GCC版本共存时，
which gcc或where gcc结果不可靠，应始终用gcc --version确认实际执行的是哪个
CPLUS_INCLUDE_PATH和CPATH会覆盖默认头文件搜索顺序
这两个变量不是“补充”，而是插在GCC内置搜索路径之前。例如设置了CPLUS_INCLUDE_PATH="/opt/mylib/include"，那么#include <vector></vector>可能先去/opt/mylib/include找，而不是标准库路径；如果那里恰好有个同名但不兼容的vector，编译会静默使用它，直到链接时报错或运行时崩溃。
-
CPLUS_INCLUDE_PATH只影响C++（g++），C_INCLUDE_PATH只影响C（gcc），CPATH两者都影响 - 它们对
#include "file.h"和#include <file.h></file.h>都生效，但不会替代-I命令行参数的优先级（-I仍最高） - 跨项目共享时容易污染：一个项目依赖的头文件路径被设为全局环境变量，另一个项目编译时可能意外包含不该包含的头
设置LIBRARY_PATH会让ld在链接阶段自动搜静态/动态库
这相当于给gcc隐式加了-L，但不像-L那样有明确作用域。如果LIBRARY_PATH里有多个同名.so或.a，链接器按路径顺序取第一个，而你可能根本不知道它来自哪个目录。
-
LIBRARY_PATH只影响gcc调用ld的阶段，不影响运行时LD_LIBRARY_PATH的加载行为 - 与
pkg-config输出冲突常见：比如pkg-config --libs openssl已给出-L/usr/local/ssl/lib -lssl，再设LIBRARY_PATH=/usr/lib可能导致链接到系统旧版libssl.so - 建议只在临时构建场景用，长期配置应写进
Makefile或cmake的find_library逻辑里
全局配置容易掩盖工具链差异，尤其在CI/CD或容器中
本地export进~/.bashrc的环境变量，在Docker容器、GitHub Actions或Jenkins job里完全不存在。你以为gcc --version是12.3，实际CI跑的是系统默认的11.4，编译报错才暴露问题。
- 不要依赖
CPATH或LIBRARY_PATH来解决头文件/库缺失——它们让错误延迟暴露，且难以复现 - CI脚本中应显式指定
CC=/opt/gcc-13/bin/gcc，而不是改PATH，避免污染其他步骤 - 容器镜像里用
ENV PATH="/opt/gcc-13/bin:$PATH"比RUN export PATH=...更可靠，后者在后续RUN中不继承
