结论：stdio.h 找不到，90% 是因系统级开发包（如 ubuntu 的 libc6-dev 或 build-essential、centos 的 glibc-devel）未安装或损坏，而非环境变量配置问题；gcc 对 #include 无视 c_include_path，仅依赖内置路径，须通过 gcc -v 验证真实搜索路径并确保标准头文件包已正确安装。
直接说结论：stdio.h 找不到，90% 不是环境变量配置的问题，而是系统级开发包根本没装全。强行改 C_INCLUDE_PATH 或反复调 -I 通常白忙活。
为什么改了 C_INCLUDE_PATH 还是报错
因为 GCC 在预处理阶段查找标准头文件（如 stdio.h）时，**优先走内置路径和系统默认路径**，C_INCLUDE_PATH 只影响 #include "xxx.h"（双引号形式），对 #include <stdio.h></stdio.h>（尖括号）基本无效。很多用户误以为设了环境变量就能覆盖一切，其实 GCC 根本不看它——除非你显式加了 -v 并确认它出现在搜索路径里。
-
gcc -v -E -x c /dev/null 2>&1 | grep "search starts here"才是真实路径来源，不是echo $C_INCLUDE_PATH - 如果输出里压根没出现
/usr/include或/usr/lib/gcc/.../include，说明 GCC 自身构建时就缺基础头文件支持 -
C_INCLUDE_PATH被忽略的典型表现：改完变量后gcc -v输出路径完全不变
build-essential 或 libc6-dev 没装全
Ubuntu/Debian 下 stdio.h 属于 glibc 开发头文件，由 libc6-dev 提供；而 build-essential 是元包，依赖它。CentOS/RHEL 则对应 glibc-devel。只装了 gcc 二进制本身，不等于装了头文件。
- Ubuntu/Debian：运行
dpkg -L libc6-dev | grep stdio.h，若无输出，说明没装或装损毁 - CentOS/RHEL：用
rpm -ql glibc-devel | grep stdio.h验证 - 装完后必须重启终端或运行
source /etc/profile（仅影响 shell 环境变量，不影响 GCC 内置路径） - 遇到
apt install build-essential报依赖冲突？换sudo aptitude install build-essential，它能降级解决版本卡点
交叉编译或非标安装导致路径偏移
比如你用的是 arm-linux-gcc 或自编译 GCC，它的默认头文件路径可能指向 /opt/gcc-arm/include 而非 /usr/include。此时 stdio.h 实际存在，但不在 GCC 认的“标准位置”。
- 用
arm-linux-gcc -print-sysroot查目标 sysroot；再检查$SYSROOT/usr/include/stdio.h是否存在 - 若存在但报错，加
--sysroot=$SYSROOT强制指定，比一堆-I更可靠 - MinGW-w64 用户注意：
stdio.h在mingw64/x86_64-w64-mingw32/include，不是mingw64/include——少一层目录就找不到
VS Code IntelliSense 警告但实际能编译通过
这是最常被混淆的场景：gcc 命令行能编译成功，但 VS Code 编辑器里标红 stdio.h。问题出在 C/C++ 扩展的 includePath 没同步 GCC 的真实路径，跟编译能力无关。
- 打开命令面板
Ctrl+Shift+P→C/C++: Edit Configurations (UI) - 在
Include Path里填入 GCC 实际搜索路径（从gcc -v输出中复制），例如：C:/msys64/mingw64/x86_64-w64-mingw32/include - 别填
C:/msys64/mingw64/include——那是 C++ 头文件路径，stdio.h不在这儿 - 改完保存，重启 VS Code 窗口，否则缓存不刷新
真正卡住的点往往藏在“GCC 能不能找到自己的标准库”这个前提里。先验证 libc6-dev 或 glibc-devel 是否完整，再查 gcc -v 输出的真实路径，最后才动环境变量或编辑器配置。顺序错了，越调越乱。
