目前无法直接将 go 代码编译为标准 c 兼容的共享库供 c 程序调用；go 运行时依赖和 abi 不兼容限制了纯 go 代码作为 c 动态库被链接使用，仅可通过 `gccgo`（已弃用）或实验性导出机制间接实现。
Go 语言官方设计上以自身为主运行环境，其运行时（runtime）、垃圾回收器（GC）、goroutine 调度器等核心组件深度耦合，导致 Go 编译生成的二进制无法满足 C 程序对“无运行时依赖、C ABI 兼容、可静态/动态链接”的基本要求。因此，直接将 Go 函数导出为 .so 或 .dll 并在 C 中 dlopen() + dlsym() 调用，是当前（Go 1.23 及之前）不被支持的标准行为。
不过，存在若干受限但可行的技术路径：
✅ 方案一：使用 //export + buildmode=c-shared（有限支持）
该模式可生成带 C 兼容头文件的共享库（.so / .dylib / .dll），但有严格前提：
- 主包必须为空 main 包（即 package main），且需含 func main() {}（即使为空）；
- 所有导出函数必须使用 //export MyFunc 注释声明，且签名仅限 C 基本类型（int, char*, void* 等），不可含 Go 特有类型（如 string, slice, struct）；
- Go 运行时仍会被打包进共享库，C 程序需确保 Go 运行时初始化（通常通过调用生成的 GoInitialize() 或隐式触发）；
- 关键限制：C 程序必须先调用 Go 初始化函数（如 MyLibInit()），且不能在 Go 运行时未就绪时调用导出函数。
示例（lib.go）：
package main
import "C"
import "fmt"
//export Add
func Add(a, b int) int {
return a + b
}
//export SayHello
func SayHello(s *C.char) *C.char {
goStr := C.GoString(s)
result := fmt.Sprintf("Hello, %s!", goStr)
return C.CString(result)
}
//export FreeCString
func FreeCString(ptr *C.char) {
C.free(unsafe.Pointer(ptr))
}
func main() {} // 必须存在，但可为空构建命令：
go build -buildmode=c-shared -o libmylib.so lib.go
生成 libmylib.h 和 libmylib.so，C 端可包含头文件并链接调用。
⚠️ 注意事项：
- SayHello 返回的 C 字符串需由 C 端调用 FreeCString 释放（Go 的 C.CString 分配在 C 堆）；
- 所有跨语言字符串交互必须显式转换（C.CString / C.GoString）；
- 不支持回调函数、goroutine 跨语言调度、panic 传播到 C 层（会导致进程终止）；
- c-shared 模式在 Windows 上支持不稳定，macOS 需注意 SIP 和符号可见性。
❌ 方案二：gccgo（已弃用）
gccgo 曾支持将 Go 编译为符合 GCC ABI 的对象文件，但自 Go 1.18 起官方已停止维护，不推荐用于新项目。
? 未来展望
Go 团队已提出 Go Shared Libraries Proposal，旨在支持更安全、更轻量的 Go 库导出机制（如无 GC 依赖的纯函数导出、WASI 兼容接口等），但截至 2024 年尚未进入正式开发阶段。
? 总结建议：
若必须实现 C 与 Go 协同，优先考虑：
- 将 Go 封装为独立服务（HTTP/gRPC），C 程序通过网络调用；
- 使用 c-shared 模式处理简单计算逻辑，并严格遵守类型与内存管理约束；
- 对性能敏感场景，改用 C/C++ 实现核心算法，Go 仅作胶水层。
Go 的设计哲学强调“让接口清晰、边界明确”，跨语言调用应以进程隔离或标准化协议为首选，而非强行打破运行时边界。
