Go项目报iconv.h或stdlib.h缺失，根本原因是CGO未找到目标平台头文件：需确保CGO_ENABLED=1启用，交叉编译时统一通过--sysroot指定工具链根目录，并用xgo的--deps传libiconv源码URL而非宿主机路径。
Go 项目里报 iconv.h: No such file or directory 或 stdlib.h: No such file or directory，不是你本地没装库，而是 CGO 根本没找到目标平台该用的头文件——路径、工具链、启用状态三者只要一个错，就直接跪。
CGO_ENABLED=1 没开，#include 就是无效注释
Go 默认禁用 CGO，import "C" 前的 #include 行会被忽略或报语法错误。这不是路径问题，是编译器压根不走 C 预处理器流程。
- 临时启用：
CGO_ENABLED=1 go build（Linux/macOS）或set CGO_ENABLED=1 && go build（Windows） - 全局启用（慎用）：
go env -w CGO_ENABLED=1，但交叉编译时可能因目标平台无对应 C 工具链而失败 - 验证是否生效：
go env CGO_ENABLED输出必须为1
交叉编译时头文件缺失，本质是 sysroot 没对齐
从 macOS 编译 Linux ARM64，或 x86_64 构建 ARM 嵌入式，错误如 stdlib.h 找不到，根本原因是 GCC 仍按宿主机逻辑搜索 /usr/include，而目标平台的头文件其实在工具链的 sysroot 里。
- 必须同时在
CGO_CFLAGS和CGO_LDFLAGS中指定--sysroot，例如：export CGO_CFLAGS="--sysroot=/path/to/arm-toolchain"和export CGO_LDFLAGS="--sysroot=/path/to/arm-toolchain -lpthread" -
--sysroot会自动把$SYSROOT/usr/include和$SYSROOT/usr/lib加入搜索路径，额外加-I可能引发冲突，建议精简写法 - 验证是否生效：
go build -x 2>&1 | grep "gcc\|ld"，日志中应出现带--sysroot的完整命令行
xgo 交叉编译 libiconv/iconv.h 缺失，别碰宿主机路径
用 xgo 编译含 gokogiri 的项目时，iconv.h 报错，常见错误操作是传 --deps /usr/local/Cellar/libiconv/1.14/ ——这完全无效：xgo 在 Docker 容器内运行，宿主机路径不可见，且 macOS 的 dylib 头文件不兼容 Linux 目标。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：用官方源码 tarball，让 xgo 在容器内自动 configure/make/install，例如：
--deps https://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.17.tar.gz - URL 必须是
.tar.gz或.tar.bz2，xgo 不支持本地路径或预编译二进制 - 推荐用
libiconv-1.17.tar.gz或更高版本，旧版对现代交叉工具链兼容性差
CFLAGS 和 CGO_CFLAGS 别混用，环境变量才透传
CFLAGS 是 Makefile 用的，Go 的 cgo 完全不读；只有 CGO_CFLAGS、CGO_CPPFLAGS、CGO_LDFLAGS 才会被透传给底层 C 编译器。
- 加头文件路径：
CGO_CFLAGS="-I/path/to/include" - 定义宏：
CGO_CFLAGS="-DUSE_OPENSSL_V3" - 设语言标准：
CGO_CFLAGS="-std=gnu99"（GNU 扩展需显式启用） - 链接库路径与名：
CGO_LDFLAGS="-L/path/to/lib -lxxx"，注意-L必须在-l前面
最易被忽略的一点：交叉编译时，--sysroot 必须同时出现在 CFLAGS 和 LDFLAGS 里——漏掉任一端，都会导致编译通过但链接失败，或头文件找到但 crt1.o 找不到。这不是配置遗漏，是工具链语义断裂。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
