Go FFI 的新范式：purego 与 libffi 如何让我们无痛拥抱 C 生态
内容提要
本文探讨了Go语言与C生态的交互，介绍了三种主要的FFI范式：原生CGO、LLGO/TinyGo和PureGo/JupiterRider/FFI。PureGo通过动态加载C库，简化了CGO的复杂性，提供了轻量解决方案。JupiterRider/FFI则增强了PureGo在处理复杂C结构体时的能力。
关键要点
-
本文探讨Go语言与C生态的交互，介绍三种主要的FFI范式：原生CGO、LLGO/TinyGo和PureGo/JupiterRider/FFI。
-
CGO是Go语言内建的FFI机制，但存在编译期不便、运行时开销和复杂性等问题。
-
Go社区倾向于尽量避免使用CGO，寻求其他解决方案。
-
PureGo通过动态加载C库，简化了CGO的复杂性，提供轻量解决方案。
-
JupiterRider/FFI增强了PureGo在处理复杂C结构体时的能力。
-
原生CGO是Go语言官方的编译期绑定方案，支持复杂C宏和内联函数，但构建复杂性高。
-
LLGO/TinyGo是基于LLVM的替代编译器，提供更高效的互操作性，但生态系统相对小众。
-
PureGo是新兴的社区驱动方案，完全放弃编译期C依赖，支持运行时动态加载C库。
-
PureGo的优点包括跨平台编译、快速构建和轻量灵活，但只支持共享库，功能受限。
-
JupiterRider/FFI是对PureGo的补充，能够处理复杂C结构体和按值传递。
-
libffi是一个C库，支持动态构建函数调用，JupiterRider/FFI利用其处理ABI细节。
-
PureGo和JupiterRider/FFI的组合为Go与C的交互提供了更轻量、更快速的解决方案。
-
对于需要链接C静态库或处理复杂C宏的场景，仍需使用原生CGO。
-
在性能敏感的环境中，LLGO/TinyGo是合适的选择。
-
当需要调用共享库形式的C API时，PureGo是首选，涉及复杂结构体时则需结合JupiterRider/FFI。
延伸解读
Go与C生态的交互挑战
Go语言与C生态的交互一直面临着编译期复杂性和运行时开销的问题。CGO虽然是官方支持的解决方案，但其构建复杂性和性能开销使得开发者在使用时感到困扰。PureGo和JupiterRider/FFI的出现，提供了新的思路，帮助开发者在不牺牲性能的情况下，简化与C库的交互。
PureGo的优势与局限
PureGo通过动态加载C库，提供了轻量级的解决方案，适合需要快速构建和跨平台编译的场景。然而，它的局限性在于只支持共享库，且对复杂C结构体的支持不足。开发者在选择使用PureGo时，需要权衡其灵活性与功能限制。
JupiterRider/FFI的补充作用
JupiterRider/FFI作为对PureGo的补充，能够处理复杂的C结构体和按值传递，弥补了PureGo在类型系统上的不足。对于需要频繁与C交互的项目，结合使用PureGo和JupiterRider/FFI可以实现更高效的开发体验。
延伸问答
Go语言如何与C生态进行交互？
Go语言与C生态的交互主要通过三种FFI范式：原生CGO、LLGO/TinyGo和PureGo/JupiterRider/FFI。
PureGo的主要优势是什么？
PureGo的主要优势包括跨平台编译、快速构建和轻量灵活，能够动态加载C库而无需CGO。
JupiterRider/FFI如何增强PureGo的能力？
JupiterRider/FFI增强了PureGo在处理复杂C结构体时的能力，能够支持按值传递和更复杂的C函数调用。
LLGO/TinyGo与原生CGO相比有什么不同？
LLGO/TinyGo是基于LLVM的替代编译器，提供更高效的互操作性，而原生CGO是官方的编译期绑定方案，构建复杂性高。
使用PureGo时有哪些局限性？
PureGo的局限性包括只支持共享库、对C类型的支持不如CGO完备，以及在处理复杂结构体时的限制。
在什么情况下应该使用原生CGO？
当需要链接C静态库或处理复杂C宏时，原生CGO几乎是唯一的选择。
