根本原因是clang未显式指定--sysroot和--target，导致默认搜索宿主机/usr/include；需用clang -v -e -x c /dev/null验证include路径，确保sysroot/usr/include在搜索列表中，并在vs code中同步配置includepath与真实构建环境一致。
根本原因是Clang没被告知目标平台的SYSROOT路径，它默认只查宿主机的/usr/include，而交叉编译必须显式指定头文件和库的真实位置。
用clang -v -E -x c /dev/null确认实际include路径
这个命令能暴露Clang当前搜索头文件的完整路径列表，关键看输出里#include <...> search starts here:</...>下面有哪些目录，以及有没有ignoring nonexistent directory警告。
- 如果
sysroot/usr/include不在其中，说明--sysroot没传进去或路径写错了 - 如果看到
/usr/include但没报错，那是你在宿主机上编译；一旦出现stdio.h: file not found，基本可断定Clang压根没扫到目标头文件目录 - 别依赖
C_INCLUDE_PATH——Clang交叉模式下通常忽略它，且它不参与链接阶段
--sysroot必须和--target同时使用
单独加--sysroot不够，Clang需要--target来判断ABI、默认调用约定和内置宏，否则仍会按宿主机逻辑解析头文件。
- 正确写法：
clang --target=aarch64-linux-ohos --sysroot=/path/to/ohos-sdk/native/sysroot hello.c - 鸿蒙场景下，SYSROOT通常是
${OHOS_SDK}/native/sysroot，里面要有usr/include/stdio.h和usr/lib/crti.o - libtool等旧构建系统会丢弃
--target参数，导致后续链接器回退到宿主机glibc路径，报crti.o not found——这时得手动改Makefile或换CMake+toolchain.cmake
VS Code里c_cpp_properties.json的includePath要对齐真实构建环境
编辑器提示“找不到stdio.h”，往往只是C/C++插件没读到你命令行里用的那些路径，不是编译器真缺文件。
-
includePath必须包含${OHOS_SDK}/native/sysroot/usr/include这类真实路径，不能只写**或留空 - 不要用
${env:HOME}这种变量——Windows上可能无效，Linux/macOS也可能因终端启动方式不同而未加载 - 验证方法：在系统终端（非VS Code内置终端）跑一遍相同命令，确认能编译成功；再检查VS Code里
compilerPath是否指向你实际用的clang二进制
最容易被忽略的是：musl libc和glibc的启动文件不兼容。即使stdio.h找到了，链接时若-lc指向宿主机/usr/lib/x86_64-linux-gnu/libc.so，就会失败。必须用-nostdlib --sysroot=... -lcrt1.o -lcrti.o -lc或直接静态链接${SYSROOT}/usr/lib/libc.a。
