Go和C内存对齐必须显式同步，否则字段偏移错位导致读写越界或静默损坏；需用unsafe.Offsetof与offsetof对比验证，int类型尺寸差异（C为4字节、Go为8字节）是重灾区，必须使用C.int等确切类型并按对齐值降序排字段。
Go 和 C 的内存边界不是“能传过去就行”，而是“谁分配、谁释放、谁持有引用”三件事必须对齐，否则不是崩溃就是泄漏。
struct 传给 C 前必须显式对齐，不能只靠字段顺序
Go 结构体默认按自身规则填充，C 编译器（GCC/Clang）按平台 ABI 规则填充，两者不一致时字段偏移错位，读写越界或静默损坏。
- 用
unsafe.Offsetof实测每个字段在 Go struct 中的偏移，再和 C 头文件里offsetof(struct, field)对比——不等就一定出问题 -
int是重灾区：C 里int几乎总是 4 字节，Go 里int在 amd64 是 8 字节；必须改用C.int或C.int32_t - 字段顺序按对齐值降序排（
int64→int32→byte），但仅排序不够，仍需显式控制填充 - 推荐做法：C 头文件加
#pragma pack(1)，Go 文件// #include "xxx.h"前也加同一行，再用unsafe.Sizeof和sizeof双向验证
C.CString / C.CBytes 不是“转一下就完事”，是 malloc + copy
C.CString 和 C.CBytes 每次都分配新 C 堆内存并拷贝数据，高频调用会直接拉高 GC 压力，且容易漏 C.free。
-
C.CString("")也会分配 1 字节，空字符串不是零开销 -
defer C.free(unsafe.Pointer(p))只能保证函数退出时释放，若 C 层异步使用该指针，就变成悬空指针 - 循环中写
for _, s := range strs { cs := C.CString(s); defer C.free(...) }→ 实际只 free 最后一次地址，前面全泄漏 - 替代方案：
C.CBytes([]byte(s))返回unsafe.Pointer，转成(*C.char)后显式传长度；接收用C.GoStringN(cstr, n)避开strlen扫描
Go 分配的 struct 指针传给 C 后，GC 可能随时回收
只要 Go 侧没有强引用持有该 struct 实例，GC 就可能在 C 还没用完时把它回收掉，C 拿到的是悬空指针，访问即 SIGSEGV。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
func newHandler() *C.vde_event_handler { var h C.vde_event_handler; return &h }—— 错！局部变量地址返回后无引用，GC 可立即回收 - 正确做法：用
C.malloc分配整块内存，或把 struct 实例存在全局变量 / map / channel 中长期持有 - 如果 C 层负责生命周期（如
xxx_new()/xxx_free()成对 API），Go 必须用defer C.free(unsafe.Pointer(p))包裹整个使用块 - 结构体里含指针字段（如
char*）时，该指针必须指向 C 分配的内存（C.CString、C.malloc），不能指向 Go 字符串底层或局部 slice
CGO 调用不是“函数调用”，是栈切换 + 信号重置 + GC 协调
每次 C.some_func() 背后是 entersyscall → 切换到 C 栈 → 执行 → exitsyscall，单次开销实测 50–200ns，高频调用会吃掉可观 CPU 时间。
- ARM64 上更敏感：传参类型不匹配（比如 C 声明
int却传C.int64）会导致直接 panic，连函数入口都进不去 - 别迷信“优化单次调用”，复用 C 内存（预分配
C.malloc缓冲区）比减少调用次数重要十倍 - 交叉编译时
CGO_ENABLED=0默认生效，C 代码全失效；必须显式设CGO_ENABLED=1并指定对应平台工具链 -
import "C"前若有空行，// #include就不生效；自定义 C 函数必须同目录.c文件或显式链接
最常被忽略的点：内存边界从来不是单边的事。你改了 Go struct 对齐，C 头文件没同步；你用了 C.CString，却忘了 C.free 的时机；你把 Go 分配的 struct 地址传给了 C，却没在 Go 侧维持引用——这些都不是“差不多能跑”，而是“迟早崩”。
