本文详解 cgo 中导出 Go 函数（//export）供 C 代码调用时的关键要点：必须在 C 文件中声明函数原型，且 Go 中返回的 *C.char 必须由 C 侧显式释放，否则将导致内存泄漏或运行时 panic。
本文详解 cgo 中导出 go 函数（`//export`）供 c 代码调用时的关键要点：必须在 c 文件中声明函数原型，且 go 中返回的 `*c.char` 必须由 c 侧显式释放，否则将导致内存泄漏或运行时 panic。
在 cgo 项目中，当 Go 函数通过 //export 标记暴露给 C 代码调用时，看似简单的集成往往因两个关键疏漏引发致命 panic —— 尤其表现为 unexpected signal during runtime execution（如 SIGSEGV），且堆栈停在 runtime.cgocall 或 _Cfunc_cc。你遇到的崩溃正源于此。
? 根本原因分析
-
C 端缺少函数声明
你在 p.c 中调用了 c_ccB(str)，但未提供其函数签名声明。C 编译器会按默认规则（隐式声明为 int c_ccB()）进行调用，导致参数传递错位、栈破坏，最终触发非法内存访问。
✅ 正确做法：在 p.c 顶部添加extern char* c_ccB(char*);
-
Go 返回的 C 字符串未被 C 侧释放
c_ccB 中调用 C.CString(...) 分配了 C 堆内存，但该指针被直接返回给 C 函数 cc 使用后，从未被 free()。多次循环调用后，内存持续泄漏；更严重的是，若后续 C 代码误用已失效指针（如被覆盖或回收），就会引发段错误。⚠️ 注意：C.CString 的内存必须由 C 代码调用 free() 释放，Go 的 runtime 不管理它；反之，C.GoString 是安全的（返回 Go 字符串，不涉及 C 内存）。
✅ 修正后的完整代码
p.h（保持不变）：
void output(char* str, int s); void cc(char *str);
p.c（关键修改：添加声明 + 安全释放）：
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
// ✅ 必须声明：告知编译器 c_ccB 的签名
extern char* c_ccB(char*);
void output(char* str, int s) {
fflush(stdout);
sleep(s);
printf("%s", str);
}
void cc(char *str) {
char* result = c_ccB(str); // 调用 Go 导出函数
printf("%s", result);
free(result); // ✅ 关键：释放 Go 分配的 C 字符串内存
}</unistd.h></stdlib.h></stdio.h>
p.go（关键修改：移除 C.free(cstr) 对 cstr 的重复释放，因 cc 已处理其返回值）：
package main
/*
#include <stdlib.h>
#include "p.h"
*/
import "C"
import (
"unsafe"
"fmt"
)
//export c_ccB
func c_ccB(cs *C.char) *C.char {
gs := C.GoString(cs)
// ✅ 返回新分配的 C 字符串（调用方 C 有责任 free）
return C.CString(gs + "wwww")
}
func main() {
ch := make(chan int)
task("A", ch, 5)
task("B", ch, 1)
fmt.Printf("begin\n")
<h3>? 重要注意事项</h3>
<ul>
<li>
<strong>C 函数声明不可省略</strong>：所有被 C 代码直接调用的 Go 导出函数，都必须在 .c 文件中用 extern 显式声明，否则属于未定义行为（UB）。</li>
<li>
<strong>内存所有权清晰划分</strong>：<ul>
<li>C.CString → 内存归 C 所有，<strong>必须由 C 代码 free()</strong>；</li>
<li>C.GoString → 返回 Go 字符串，完全由 Go runtime 管理；</li>
<li>//export 函数的参数/返回值若含 *C.char，需严格约定谁分配、谁释放。</li>
</ul>
</li>
<li>
<strong>goroutine 安全性</strong>：c_ccB 在 C 线程中被调用，而 Go 运行时要求所有 //export 函数必须在 CGO_CFLAGS=-DGOOS_linux -DGOARCH_amd64 等标准环境下可重入。本例无锁操作，符合要求；但若涉及 Go 全局状态（如 map、channel），需加锁或使用 runtime.LockOSThread()。</li>
</ul>
<p>遵循以上原则，你的 cgo 交互即可稳定运行，彻底规避因声明缺失和内存管理错位导致的 panic。</p></stdlib.h>
