cgo_enabled必须为1，否则cgo代码被静默忽略导致panic或零值；常见原因是环境变量被设为0，需用go env cgo_enabled检查并设为1，windows还需确保gcc在path中。
CGO_ENABLED 必须为 1，否则所有 cgo 相关代码会被静默忽略，编译通过但函数调用直接 panic 或返回零值。
为什么 go build 突然不认 C 函数了？
最常见原因是环境变量 CGO_ENABLED 被设为 0 —— 比如你在交叉编译时手动关闭过，或某些 CI/CD 脚本里默认禁用了它。
- 检查命令：
go env CGO_ENABLED，输出不是1就得立刻修复 - 临时启用：
CGO_ENABLED=1 go build（Linux/macOS）或set CGO_ENABLED=1 && go build（Windows cmd） - 永久写入：
go env -w CGO_ENABLED=1，但要注意：禁用后生成的是纯 Go 二进制，无法链接任何 C 符号 - Windows 下即使开了
CGO_ENABLED，若gcc不在%PATH%中，仍会报错cgo: C compiler "gcc" not found
import "C" 前的注释块到底要怎么写？
这不是普通注释，是 cgo 的 DSL —— 空行、顺序、拼写全影响解析结果。
- 必须紧挨着
import "C"，中间不能有空行，也不能有其他 Go 代码 -
// #cgo指令必须放在注释块顶部（在#include之前），否则会被忽略 -
#include行不能缩进，且路径要用双引号而非尖括号（除非是系统头文件）；自定义头文件如"mylib.h"需配合// #cgo CFLAGS: -I./include - 嵌入 C 函数时，函数体必须完整（含
{}），且不能有 Go 风格的分号结尾；/* */和//混用容易出错，建议统一用/* */
字符串传参为什么有时崩溃，有时内容乱码？
本质是生命周期错配：C.CString 分配的内存归 C 管理，但 Go 侧没显式释放，或释放太早，或重复释放。
- 每次
C.CString都会 malloc 一块新内存，必须配对C.free(unsafe.Pointer(...)) - 不能对同一
*C.char多次C.free，否则触发 double-free（尤其在 defer 链里易重复） - 若 C 函数内部保存了该指针（比如注册回调），就不能在 Go 返回前
free，得等 C 侧明确不再使用后再释放 - 从 C 返回的
*C.char（如C.get_message()），要用C.GoString转成 Go 字符串，而不是直接转string()—— 后者不处理 NULL 终止符，可能读越界
性能敏感场景下，哪些操作真不能做？
cgo 调用本身有固定开销（约 30–60 ns），但更危险的是隐式同步和 GC 干预。
- 避免在 hot loop 里频繁调 C 函数 —— 即使函数本身很快，跨 runtime 切换成本也扛不住
- 不要在 C 函数里调
runtime.GC()或触发 goroutine 调度，cgo 默认运行在g0栈上，此时调度器不可用 - 传递
[]byte时，若 C 侧需长期持有，必须用C.CBytes+unsafe.Slice手动管理，不能直接传&data[0]—— Go GC 可能移动底层数组 - 结构体传参优先用指针（
*C.struct_foo），值传递会触发深拷贝且字段对齐可能不一致
真正卡住人的从来不是语法，而是 C 内存谁负责、Go 对象何时能被回收、C 函数是否重入、ABI 调用约定是否隐式变更 —— 这些细节不会报错，但会在某个高负载时刻突然崩掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
