import "C" 是 CGO 的硬性锚点，触发完整 C 编译流程，要求 CGO_ENABLED=1、GCC/Clang 可用、C 标准库头文件存在、路径与链接参数正确，四者缺一不可。
CGO 默认已启用，但只要代码里出现 import "C"，就必须确保 C 工具链可用、头文件路径正确、链接参数匹配，否则编译或运行时必然失败。
为什么 import "C" 一写就报错？
这不是 Go 语法导入，而是 CGO 的硬性锚点：它触发整个 C 编译流程。一旦存在，CGO_ENABLED 必须为 1，且系统必须装有 GCC（或 Clang）和对应平台的 C 标准库头文件。
-
CGO_ENABLED=0时，import "C"直接导致编译失败，错误类似undefined: C - Linux 上缺失
glibc-devel或musl-dev（Alpine），会报stdio.h: No such file or directory - macOS 上 Xcode Command Line Tools 未安装，
clang: error: no such file or directory: 'crt1.o'是典型表现 - Windows 上需 MinGW-w64 或 MSVC，且
CC环境变量要指向有效编译器，否则exec: "gcc": executable file not found
// #cgo 指令怎么写才不被忽略？
所有 // #cgo 行必须紧挨着 import "C" 前面的注释块，且不能有空行隔开；位置错或格式松散，参数就完全失效。
- 正确顺序：
<pre class="brush:php;toolbar:false;">/* #cgo CFLAGS: -I./include -DPNG_DEBUG #cgo LDFLAGS: -L/usr/local/lib -lpng #include "png.h" */
import "C" -
CFLAGS控制预处理和编译阶段：加宏、指定头文件路径（-I）、启用 C 标准（如-std=c99） -
LDFLAGS控制链接阶段：指定库搜索路径（-L）、实际链接的库名（-lfoo对应libfoo.so或libfoo.a） - 跨平台时，
// #cgo darwin LDFLAGS:和// #cgo linux LDFLAGS:可分别指定，避免混用
调用 C 函数时最常踩的内存坑
Go 和 C 的内存生命周期完全独立，C.CString、C.CBytes、C.malloc 分配的内存，Go 的 GC 一概不管，漏 C.free 就是稳 Leak；早 free 就是 Segfault。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
C.CString(s)返回*C.char，必须配对C.free(unsafe.Pointer(p))，哪怕s == ""也要 free - 传
[]byte给 C 函数时，优先用C.CBytes(data)+ 显式长度，避免C.GoBytes的无谓拷贝 - C 函数返回的
*C.char，立刻用C.GoString或C.GoStringN拷出内容，别长期持有指针 - 结构体字段含指针（如
name *C.char），该指针必须由 C 分配（C.CString），不能指向 Go 字符串底层或栈变量地址
交叉编译时 CGO 为什么突然失效？
Go 默认在交叉编译时关闭 CGO——因为宿主机的 GCC 无法生成目标平台的 C 二进制。这不是 bug，是设计行为。
-
GOOS=linux GOARCH=arm64 go build会自动设CGO_ENABLED=0，此时所有import "C"报错 - 强制启用需手动设
CGO_ENABLED=1，并配置对应目标平台的CC（如CC_arm64=~/x-tools/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc） - 静态链接更可靠：
// #cgo LDFLAGS: -static -lpng，避免目标机缺动态库 - 若目标平台无 C 运行时（如某些嵌入式环境），根本不能依赖 CGO，得改用纯 Go 实现或 syscall
真正麻烦的从来不是“怎么写”，而是“谁负责释放”和“在哪能找着库”。每次加 import "C"，都要同步确认：C 工具链、头文件路径、链接库存在性、内存所有权归属——四个条件缺一不可。
