Go 使用 -buildmode=c-shared 编译共享库时，导出函数不能直接接收 Go 原生 string 类型；必须使用 *C.char 并通过 C.GoString() 转换，否则会因内存布局不匹配触发 runtime out-of-memory panic。
go 使用 `-buildmode=c-shared` 编译共享库时，导出函数不能直接接收 go 原生 `string` 类型；必须使用 `*c.char` 并通过 `c.gostring()` 转换，否则会因内存布局不匹配触发 runtime out-of-memory panic。
在 Go 中构建可被 C、Java（JNA）或 Python（ctypes）调用的共享库时，一个常见却极易被忽视的关键约束是：所有导出函数（//export）的参数和返回值必须是 C 兼容类型。Go 的原生 string 是一个包含指针和长度字段的结构体（struct { data *byte; len int }），而 C 语言中字符串仅是一个以 \0 结尾的 char*。当 Java 或 Python 传入一个标准 C 字符串指针（如 "World" 的地址）时，Go 运行时会错误地将其解释为 string 结构体首地址——把指针值当作 len 字段读取（例如日志中出现的 0x7f5e4d27dc8d 十六进制数被解析为超大整数），进而尝试分配 TB 级别内存，最终触发 fatal error: out of memory。
✅ 正确做法：使用 *C.char + C.GoString()
需将导出函数签名改为接收 *C.char，再显式转换为 Go 字符串：
package main
import "C"
import "fmt"
//export Hello
func Hello(s *C.char) {
// 安全地将 C 字符串转为 Go 字符串（自动处理 \0 截断）
goStr := C.GoString(s)
fmt.Println("Hello " + goStr + "!")
}
// 注意：main 函数必须存在，但可为空（c-shared 模式下不执行）
func main() {}
编译命令保持不变：
go build -o libsample.so -buildmode=c-shared .
? 调用端无需修改（兼容性保障）
-
Python（ctypes）：仍可直接传入 Python 字符串（ctypes 自动转为 const char*）：
import ctypes lib = ctypes.CDLL("./libsample.so") lib.Hello(b"World") # 注意：传 bytes，非 str（Python 3 中 str 是 Unicode） -
Java（JNA）：接口定义也无需改动，JNA 会自动将 String 映射为 const char*：
public interface GoSO extends Library { GoSO INSTANCE = Native.loadLibrary("sample", GoSO.class); void Hello(String s); // ✅ 正确：JNA 自动处理编码与生命周期 }
⚠️ 重要注意事项
- 字符串所有权与生命周期：C.GoString(s) 会复制 C 字符串内容，因此调用者（Java/Python）无需关心内存释放；但若需高性能或处理超长字符串，可考虑 C.GoStringN(s, n) 指定最大长度以防无 \0 终止导致越界。
- 避免在导出函数中返回 Go 字符串：//export 函数不能返回 Go string（C 无法理解其结构）。如需返回字符串，应返回 *C.char 并由调用方负责 C.free()（需额外导出清理函数）或使用 C.CString() + 明确文档说明。
- main() 函数不可省略：即使为空，c-shared 模式要求 main 包含 main() 函数，否则构建失败。
- 跨语言编码一致性：确保 Java/Python 传入的字符串编码为 UTF-8（Go 默认），避免中文等字符乱码。
✅ 总结
根本原因在于 Go 与 C 对“字符串”的抽象层级不同。解决该 panic 的核心原则是：*所有 //export 函数的形参和返回值，必须严格限定为 C 基本类型（int, float64, `C.char等）或 C 结构体**。字符串交互必须通过C.CString()（Go → C）和C.GoString()`（C → Go）桥接，并始终尊重内存所有权边界。遵循此规范，即可安全、稳定地实现 Go 与主流语言的高效互操作。
