目前 go 官方标准工具链（gc 编译器）不支持将 go 代码直接编译为可供 c 程序链接使用的标准共享库（如 .so 或 .dll），go 程序必须作为主入口运行，且依赖其运行时；gccgo 曾提供有限支持，但已逐步弃用。
尽管社区常有“用 Go 写库供 C 调用”的需求，但截至 Go 1.23，标准 Go 工具链（即 go build 使用的 gc 编译器）仍无法生成符合 C ABI 的、可被 ld 直接链接的动态或静态库。根本原因在于：
- Go 运行时（goroutine 调度、GC、栈管理等）与 C 运行时模型不兼容；
- Go 函数默认不遵循 C 调用约定（如参数传递、栈清理、符号可见性）；
- //export 仅在 cgo 上下文中生效（即 Go 主程序调用 C），不能反向生成 C 可见的导出符号。
✅ 唯一历史例外：gccgo
gccgo 编译器曾支持 -shared -fPIC 生成 .so，并导出带 extern "C" 语义的函数。例如：
// hello.go
package main
import "C"
import "fmt"
//export SayHello
func SayHello(name *C.char) *C.char {
goStr := fmt.Sprintf("Hello, %s!", C.GoString(name))
return C.CString(goStr)
}
func main() {} // 必须存在，但实际不执行使用 gccgo 编译：
gccgo -shared -fPIC -o libhello.so hello.go
⚠️ 然而，gccgo 自 Go 1.18 起已被官方标记为“deprecated”，不再维护，且不支持新版 Go 语言特性（如泛型、模糊测试等），生产环境强烈不推荐。
? 当前可行的替代路径
若需 C 程序集成 Go 逻辑，推荐以下工程化方案：
进程间通信（IPC）
将 Go 编写为独立服务（HTTP/gRPC/Unix socket），C 程序通过网络或本地套接字调用。稳定、安全、语言无关，适合复杂逻辑或长生命周期任务。嵌入 Go 运行时（高级场景）
使用 libgo（gccgo 运行时）或实验性项目如 golang.org/x/mobile/cmd/gomobile（面向移动端），但均非标准路径，维护成本高。C 为主 + Go 为辅的混合构建（cgo 反向封装）
在 C 项目中引入一个轻量级 Go 主程序（含 main），通过 dlopen + dlsym 加载其导出的 C 兼容接口——但这要求 Go 程序自身以 shared library 形式启动，本质上仍是“C 启动 Go”，而非“C 链接 Go 库”。
? 未来展望
Go 团队已在提案 “Go Shared Libraries” (GOOS=linux, GOARCH=amd64/arm64) 中明确规划该能力，目标是支持 go build -buildmode=c-shared 生成真正 ABI 兼容的 .so/.dll。但该功能尚未进入开发路线图，短期内不可依赖。
✅ 总结建议：
- ✖️ 不要尝试用 go build -buildmode=c-shared（它仅用于生成供 C 调用的 Go 代码桩，仍需 Go 运行时初始化，且仅支持从 Go 主程序启动）；
- ✅ 优先采用 IPC 方案（如 HTTP API + JSON）实现松耦合；
- ✅ 若性能敏感且控制权充分，可评估将核心算法用 C/C++ 重写，Go 仅作胶水层；
- ? 关注 Go 官方提案进展，但勿将其纳入当前生产架构设计。
