asmcgocall是go运行时强制执行栈切换的汇编函数，每次c调用均触发50–200ns开销，涉及p暂停、寄存器保存、信号掩码重置与gc同步，且c.cstring/c.gostring各引发两次完整cgo调用。
Go 调用 C 函数时的栈切换不是“慢一点”，而是每次都要暂停当前 P、切换到系统线程、保存寄存器、重置信号掩码、等待 GC 同步——单次开销实测 50–200ns。高频调用（比如每毫秒几百次）会直接吃掉可观 CPU 时间，比纯 Go 实现还慢一个数量级。
asmcgocall 是谁在切栈？
真正执行栈切换的是 asmcgocall 汇编函数，它由 Go 运行时注入，在每次 C.some_func() 调用前触发。这不是用户代码控制的，而是运行时强制行为：必须让 Goroutine 离开 Go 栈，进入 C 栈上下文，且期间 GC 无法扫描该 Goroutine 的栈内存。
- 切换过程包含栈拷贝（若需传递大结构体）、TLS 更新、FPU/SSE 寄存器保存
-
asmcgocall不是可选优化项，只要用了import "C"并调用了 C 函数，就绕不开 - 即使 C 函数只做
return 0;，开销也稳定在 50ns 以上
C.CString 和 C.GoString 为什么让切换更贵？
这两个函数表面是字符串转换，实际各触发一次完整 cgo 调用：前者调 malloc + memcpy 分配 C 堆内存并加 null terminator，后者再调 malloc + memcpy 拷回 Go 堆并构造 string header。等于一次字符串操作引发两次栈切换 + 两次内存分配。
-
C.CString("")仍会 malloc 1 字节，然后 free —— 零长度不跳过开销 - 循环中写
defer C.free(C.CString(s))是典型错误：defer绑定的是上一轮的指针，导致泄漏或崩溃 - 固定字符串（如
"GET /health"）应提前用const path = C.CString("...")初始化，全局复用*C.char - 传字节数据优先用
C.CBytes([]byte)，它不验证 UTF-8、不加 null、不触发 strlen，比C.CString快 3–5 倍
如何避免被栈切换拖垮性能？
核心思路不是“减少调用次数”，而是“把多次切换压缩成一次”。关键不是 C 函数快不快，是你调它的姿势对不对。
- 把 Go 侧 for 循环下沉到 C 层：不要写
for _, x := range data { C.process_one(&x) }，改用C.process_batch((*C.struct_item)(unsafe.Pointer(&data[0])), C.int(len(data))) - 批量接口必须显式传长度参数，C 层用
for (int i = 0; i 处理，避免依赖 null terminator 或 strlen - 复用 C 堆内存：用
C.malloc分配一次缓冲区，绑定到 Go struct 中，通过Close()统一C.free；绝不能对C.malloc返回指针做unsafe.Slice后丢给 GC - 回调 Go 函数（
//export foo）会额外创建 goroutine 并入调度队列，比普通 cgo 调用更重，非必要不暴露
最易被忽略的一点：栈切换代价和 C 函数本身逻辑无关，哪怕你把 C 函数内联成空函数，开销依然存在。真正决定性能上限的，是调用频次与数据打包方式，而不是算法复杂度。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
