Go与Python互调无唯一解：os/exec最轻量安全，适合命令式调用；CGO内嵌适合高频低延迟共享状态场景；c-shared模式适用于将Go高性能模块暴露给Python；gRPC/HTTP因引入网络栈和序列化开销，仅在已有微服务架构时推荐。
Go 与 Python 互调没有“唯一正确解”，选哪种方案取决于你是否需要实时性、是否接受进程隔离、能否容忍启动开销，以及是否愿意处理 C 类型转换或 GIL 问题。
用 os/exec 启动 Python 子进程并双向通信
这是最轻量、最安全、最易调试的方案，适合命令式调用（比如跑一次脚本、传入参数、拿回结果），也支持流式交互（如 REPL 场景）。
- Python 脚本必须显式
sys.stdout.flush()，否则 Go 会卡在ReadString('\n')或读不到输出 - 子进程 stdin/stdout/stderr 必须用
cmd.StdinPipe()和cmd.StdoutPipe()显式获取，不能依赖默认继承 - 不要用
cmd.Output()或cmd.CombinedOutput()—— 它们是一次性阻塞读取，无法实现“发一条、等一条、再发一条”的交互节奏 - 务必用
cmd.Wait()或cmd.Process.Kill()清理子进程，否则 Python 进程可能残留成僵尸
示例关键片段：
cmd := exec.Command("python3", "add.py")
stdin, _ := cmd.StdinPipe()
stdout, _ := cmd.StdoutPipe()
cmd.Start()
fmt.Fprintln(stdin, "2 + 3")
buf := make([]byte, 128)
n, _ := stdout.Read(buf)
fmt.Printf("got: %s", string(buf[:n]))
cmd.Wait()
用 CGO + Python C API 内嵌解释器
适合高频、低延迟、需共享内存/状态的场景（如 Datadog Agent 那种长期运行的 Go 主程序中动态加载 Python 插件），但复杂度陡增。
立即学习“Python免费学习笔记（深入）”；
- 必须链接系统 Python 的
libpython，且版本要严格匹配（python3.9头文件配libpython3.9.so），否则运行时报undefined symbol: Py_Initialize - 每次调用 Python 函数前需确保 GIL 已获取（
PyGILState_Ensure()），返回前释放（PyGILState_Release()），否则并发 goroutine 会 panic - Go 中传递字符串给 Python，要用
C.CString(s)；Python 返回的char*要用C.GoString()转回 Go 字符串，漏掉任一转换就会内存泄漏或 segfault - 不能在任意 goroutine 中随意调用 Python —— Go runtime scheduler 可能将 M 绑定到不同 OS 线程，而 Python C API 不是线程安全的，除非显式管理线程绑定
用 buildmode=c-shared 编译 Go 为 .so 供 Python 调用
适合把 Go 写的高性能计算模块（如加解密、图像处理）暴露给 Python，不涉及 Python 运行时，纯函数调用。
- Go 函数必须用
//export FuncName注释导出，且函数签名只能含 C 兼容类型：int、float64、*C.char等，不能有string、slice、struct - Python 端必须用
ctypes显式声明.argtypes和.restype，否则传参错位会导致崩溃（例如把 int 当指针用） - Go 中返回的
*C.char必须由 Go 分配（C.CString），且 Python 不负责释放 —— 若需 Python 释放，得额外导出一个free_string函数并由 Python 主动调用 - 编译命令必须带
-buildmode=c-shared，且项目不能有main函数（否则报错：cannot build c-archive or c-shared with main package）
为什么 gRPC/HTTP 不在首选推荐之列
它们不是“互调”而是“服务化通信”，引入了网络栈、序列化（protobuf/json）、服务发现、超时重试等额外层。只有当你已经具备微服务架构、或 Python 逻辑天然就是独立服务时才值得选。
- 本地进程间调用走 TCP loopback，延迟比管道高 1–2 个数量级，对毫秒级敏感场景不友好
- 每调用一次都要打包/解包、建立连接（哪怕复用）、处理上下文取消，开发成本和运行时开销都远高于直接调用
- 调试困难：问题可能出在 proto 定义、生成代码、网络配置、TLS 设置等任意环节，而不是业务逻辑本身
真正容易被忽略的是：子进程方案里 Python 脚本的 EOF 行为、CGO 方案里 GIL 生命周期管理、c-shared 方案里 C 字符串内存归属——这些细节不出问题则一切安静，一出就是 core dump 或静默数据错乱。
