应根据实际安装路径重建path：windows需添加mingw/msys2等的bin目录（如c:\msys64\mingw64\bin），linux需确保/usr/bin或/usr/local/bin在path中，修改后须新开终端验证gcc --version。
PATH 里删错了，怎么找回系统默认的 GCC 路径
Windows 和 Linux 的默认 GCC 路径完全不同，不能靠“还原”操作，得靠查证和重建。关键不是恢复旧值，而是让 shell 正确定位到系统自带或你实际安装的 gcc 可执行文件。
- Windows 下，
gcc从来不是系统自带的——它来自 MinGW、TDM-GCC、MSYS2 或 Dev-C++ 等第三方工具链。所谓“默认”，其实是你当初安装时 bin 目录的路径，比如C:\TDM-GCC-64\bin或C:\msys64\mingw64\bin - Linux（如 CentOS/Ubuntu）中，系统包管理器安装的 GCC 默认在
/usr/bin/gcc；源码编译安装的通常在/usr/local/bin/gcc或自定义前缀下的bin/子目录 - 先用
which gcc或command -v gcc查当前是否存在可执行文件；如果返回空，说明二进制本身可能被删了，光修 PATH 没用
Windows PATH 被清空或覆盖后怎么补
别直接复制网上“通用路径”，必须按你实际安装位置来。常见错误是把整个 MinGW 目录加进 PATH，但真正起作用的只有 bin 子目录。
- 打开资源管理器，手动找到你安装 TDM-GCC / MSYS2 / Code::Blocks / Dev-C++ 的根目录，确认里面存在
bin\gcc.exe - 右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 编辑
Path→ 新建 → 粘贴完整路径，例如：C:\msys64\mingw64\bin（注意：不含gcc.exe，只到bin） - 切勿在 PATH 中添加
include或lib目录——这些对运行gcc命令完全无效，只会污染 PATH 导致查找变慢甚至冲突 - 改完后必须新开一个 cmd 或 PowerShell 窗口，旧窗口不会自动继承新 PATH
Linux 上误删 PATH 导致 gcc 找不到怎么办
临时救急很简单，永久修复要看你改的是哪个配置文件。bash 和 zsh 的加载顺序不同，别只改 ~/.bashrc 却忘了 ~/.zshrc。
- 先临时运行：
/usr/bin/gcc --version或/usr/local/bin/gcc --version，确认二进制还在。如果报 “No such file or directory”，说明不是 PATH 问题，是 GCC 本身被卸载了 - 检查你改过的文件：
~/.bashrc、~/.bash_profile、/etc/profile、/etc/profile.d/*.sh，找所有含export PATH=或export PATH=$PATH:的行 - 重点看有没有整行覆盖写法，比如
export PATH="/my/path"（会清空原有 PATH），正确写法必须保留原值：export PATH="$PATH:/usr/bin" - 改完记得
source ~/.bashrc（或对应 shell 的配置文件），再验证echo $PATH | grep bin是否含/usr/bin
C_INCLUDE_PATH 和 CPLUS_INCLUDE_PATH 不是 PATH，别混
很多人以为头文件路径也该加进 PATH，这是典型误解。这两个变量控制 #include <xxx.h></xxx.h> 的搜索顺序，和命令执行无关。
- 它们只影响编译阶段，不影响
gcc --version是否能运行 - 设错会导致编译时报
fatal error: xxx.h: No such file or directory，但gcc命令本身仍可用 - 若真要设，建议用
export CPLUS_INCLUDE_PATH="/opt/mylib/include:$CPLUS_INCLUDE_PATH"，避免覆盖系统默认路径 - 绝大多数项目不需要手动设这些——用
-I参数或 CMake 的include_directories()更清晰可控
最常被忽略的一点：PATH 修改后，shell 不会自动 reload，也不检查路径是否真实存在。哪怕你加了个根本不存在的 C:\fake\gcc\bin，PATH 依然“生效”，只是 gcc 启动失败。验证永远要靠新开终端 + gcc --version，而不是只看 PATH 内容。
