Go结构体传给C时panic是因为内存布局不一致，尤其int尺寸差异导致偏移错乱，必须用C.int等确切类型并实测字段偏移。
Go结构体传给C时为什么一读就panic
因为Go和C对同一结构体的内存布局理解不一致，SIGSEGV不是偶然崩溃，而是必然结果。最常见诱因是int类型尺寸错位：C里int几乎总是4字节，Go里int在64位系统是8字节——光这一项就能让整个结构体偏移全乱。
验证方式只有一条：用unsafe.Offsetof实测每个字段起始位置，别信“看着一样就行”。比如C定义了struct { char a; int b; }，Go里写type S struct{ A byte; B int }，在amd64上B实际偏移是8，而C期望它是4，读取时直接越界。
- 必须用C端确切类型，如
C.int、C.uint32_t，而不是Go原生int - 字段顺序按对齐值降序排：
int64（对齐8）→int32（对齐4）→byte（对齐1） - 小字段前置会引入隐式填充，C端没这些填充，必须显式补
_ [n]byte
CString/CBytes频繁调用导致GC压力大怎么办
C.CString和C.CBytes每次都会分配新内存并拷贝数据，这不是“安全换性能”，是纯冗余开销。尤其在高频回调或循环调用场景，GC标记扫描压力会明显上升。
关键判断点在于：C函数是否修改数据？生命周期由谁管理？
立即学习“go语言免费学习笔记（深入）”；
- 只读且C侧负责释放 → 用
C.CString后立刻C.free，别defer（避免延迟释放） - 只读且C侧不释放 → 改用
unsafe.String（Go 1.20+）配合C.CString返回的指针，跳过拷贝 - 二进制数据反复传入 → 预分配
C.malloc内存，用unsafe.Slice转[]byte写入，复用同一块C内存
Go切片传给C后数据错乱或越界
Go切片传入C函数时，C看到的是Data指针、Len、Cap三个字段。如果C函数内部按固定步长（如int32*）遍历，而Go底层数组未按4字节对齐分配，就会读到垃圾值或触发总线错误。
这不是切片本身的问题，而是底层malloc分配策略与C访问模式不匹配。
- 避免直接传
[]byte，改用C.malloc预分配对齐内存，再用unsafe.Slice构造切片 - 若必须用原生切片，确保其底层数组已对齐：可先分配大块内存，再用
unsafe.AlignOf手动跳过偏移 - C函数声明中明确标注数组长度参数，别依赖
Len字段自动推断
嵌套结构体传参时莫名字段值为0
嵌套结构体的对齐要求是继承式的：外层结构体必须满足内嵌结构体最大字段的对齐值。例如内嵌结构体含float64（对齐8），那它在外层的起始地址必须是8的倍数。Go默认可能把它放在偏移4处，C端读取时直接错位。
最容易被忽略的是：C头文件里用了#pragma pack(1)或__attribute__((packed))，而Go端完全没适配——这种差异不会报错，只会静默损坏数据。
- 用
unsafe.Alignof查内嵌结构体对齐值，外层结构体前加足够_ [n]byte填充 - 在CGO注释里同步C端对齐指令，如
// #pragma pack(4)，并在Go结构体上加对应填充 - 字段顺序不能只看“看起来合理”，必须按
unsafe.Alignof结果重排，哪怕语义上更乱
