大家好，我是煎鱼。
今天给大家分享的是 Go 谚语中的 Cgo is not Go[1]，原文章同名，略有修改，原文作者是 @Dave Cheney。以下的 “我” 均指代原作者。
借用 JWZ 的一句话：有些人在面对一个问题时，认为 "我知道，我会使用 cgo（来解决这个问题）"。
类似的引言
在使用 cgo 后，他们就会遇到两个新问题。
Cgo 是什么
Cgo 是一项了不起的技术，它允许 Go 程序与 C 语言库相互操作，这是一个非常有用的功能。
没有它，Go 就不会有今天的地位。cgo 是在 Android 和 iOS 上运行 Go 程序的关键。
注：甚至许多内部用到其他底层语言的同学，会使用它来做胶水。
被过度使用
我个人认为 cgo 在 Go 项目中被过度使用了，当面临在 Go 中重新实现一大段 C 语言代码时，程序员会选择使用 cgo 来包装库，认为这是个更容易解决的问题。但我认为这是一种错误的选择行为。
显然，在某些情况下，cgo 是不可避免的，最明显的是你必须与图形驱动或窗口系统进行互操作，而后者只能以二进制 blob 的形式提供。在这些场景下，cgo 的使用证明了它的权衡是合理的，比许多人准备承认的要少得多。
以下是一份不完整的权衡清单，当你把 Go 项目建立在 cgo 库上时，你可能没有意识到这些权衡。
你需要对此进行思考。
构建时间变长
当你在 Go 包中导入 "C" 时，go build 需要做更多的工作来构建你的代码。
构建你的包不再是简单地将范围内的所有 .go 文件的列表传递给 go 工具编译的一次调用，而是包含以下工作项：
- 需要调用 cgo 工具来生成 C 到 Go 和 Go 到 C 的相关代码。
- 系统中的 C 编译器会为软件包中的每个 C 文件进行调用处理。
- 各个编译单元被合并到一个 .o 文件中。
- 生成的 .o 文件会通过系统的链接器，对其引用的共享对象进行修正。
所有这些工作在你每次编译或测试你的软件包时都会发生，如果你在该软件包中积极工作的话，这种情况是经常发生的。
Go 工具会在可能的情况下将这些工作并行化（包括对所有的 C 代码进行全面重建），软件包的编译时间将会增加，并会随之增大而增大。
你还需要在各大平台上调试你的 C 语言代码，以避免由于兼容性导致的编译失败。
复杂的构建
Go 的目标之一是产生一种语言，它的构建过程是自我描述的；你的程序的源代码包含了足够的信息，可以让一个工具来构建这个项目。这并不是说使用 Makefile 来自动构建工作流程是不好的，但是在 cgo 被引入项目之前，除了 go 工具之外，你可能不需要任何东西来构建和测试。
在引入了 cgo 之后，你需要设置所有的环境变量，跟踪可能安装在奇怪地方的共享对象和头文件。
另外需要注意，Go 支持许多的平台，而 cgo 并不是。所以你必须花一些时间来为你的 Windows 用户想出一个解决方案。
现在你的用户必须安装 C 编译器，而不仅仅是 Go 编译器。他们还必须安装你的项目所依赖的 C 语言库，你也要承担这个技术支持的成本。
交叉汇编被抛在窗外
Go 对交叉编译的支持是同类中最好的。从 Go 1.5 开始，你可以通过 Go 项目网站上的官方安装程序支持从任何平台交叉编译到任何其他平台。
在默认情况下，交叉编译时 cgo 被禁用。通常情况下，如果你的项目是纯粹的 Go，这不是一个问题。
当你混入对 C 库的依赖时，你要么放弃交叉编译你的因那个也，要么你必须投入时间为所有目标寻找和维护交叉编译的 C 工具链，才能实现交叉编译。
Go 支持的平台数量在不断增加。Go 1.5 增加了对 64 位 ARM 和 PowerPC 的支持。Go 1.6 增加了对 64 位 MIPS 的支持，而 IBM 的 s390 架构被吹捧为 Go 1.7。RISC-V 正在开发中。
如果你的产品依赖于 C 语言库，你不仅有上述交叉编译的所有问题，你还必须确保你所依赖的 C 语言代码在 Go 支持的新平台上可靠地工作 -- 而且你必须在 C/Go 混合语言为你提供的有限调试能力的情况下做到这一点。
你失去了对所有工具的访问权
Go 有很好的工具；我们有 race detector、用于分析代码的 pprof、覆盖率、模糊测试和源代码分析工具。但这些工具都不能在 cgo 中起到作用（也就是没法排查）。
相反，像 valgrind 这样优秀的工具并不了解 Go 的调用约定或堆栈布局。在这一点上，Ian Lance Taylor 的工作是整合 clang 的内存净化器来调试 C 端的悬空指针，这对 Go 1.6 中的 cgo 用户有好处。
将 Go 代码和 C 代码结合起来的结果是两个世界的交叉点，而不是结合点；C 的内存安全和 Go 程序的调试性。但失去了许多核心工具的使用空间。
性能将始终是一个问题
C 代码和 Go 代码生活在两个不同的世界里，cgo 穿越了它们之间的边界，这种转换不是免费的。而且取决于它在你的代码中存在的位置，其成本可能是无关紧要的，也可能是巨大的。
C 对 Go 的调用惯例或可增长的堆栈一无所知，所以对 C 代码的调用必须记录 goroutine 堆栈的所有细节，切换到 C 堆栈，并运行 C 代码，而 C 代码对它是如何被调用的，或负责程序的更大的 Go 运行时一无所知。
公平地说，Go 对 C 的世界也一无所知。这就是为什么随着时间的推移，两者之间的数据传递规则变得越来越繁琐，因为编译器越来越善于发现不再被认为是有效的堆栈数据，而垃圾回收器也越来越善于对堆进行同样的处理。
如果在 C 语言世界中出现故障，Go 代码必须恢复足够的状态，至少要打印出堆栈跟踪并干净地退出程序，而不是把核心文件的信息都暴露出来。
管理这种跨调用堆栈的过渡，尤其是涉及到信号、线程和回调的情况下，是不容易的（Ian Lance Taylor 在 Go 1.6 中也做了大量的工作来改善信号处理与 C 的互操作性）。
归根结底，C 语言和 Go 语言之间的转换是不容易的，互相对对方都一户无知，会有明显的性能开销。
C 语言发号施令，而不是你的代码
你用哪种语言编写绑定或包装 C 代码并不重要；Python、使用 JNI 的 Java、使用 libFFI 的一些语言，或者通过 cgo 的 Go；这是 C 的世界，你只是生活在其中。
Go 代码和 C 代码必须就如何共享地址空间、信号处理程序和线程 TLS 槽等资源达成一致 -- 我说的一致，实际上是指 Go 必须围绕 C 代码的假设开展工作。C 代码可以假设它总是在一个线程上运行，或者根本没有准备好在多线程环境下工作。
你不是在写一个使用 C 库的逻辑的 Go 程序，是在写一个必须与互不可控的 C 代码共存的 Go 程序，这个 C 代码很难被取代，在谈判中占上风，而且不关心你的问题。
部署变得更加复杂
任何对普通观众的 Go 演讲都会包含至少一张带有这些文字的幻灯片：Single, static binary（单一的、静态的二进制）。
这是 Go 的一张王牌，使其成为远离虚拟机和运行时管理的典型代表。使用 cgo，你就放弃了这一点，放弃了 Go 的优势区域。
根据你的环境，你可能会把你的 Go 项目编译成 deb 或 rpm，并且假设你的其他依赖项也被打包了，把它们作为安装依赖项加入，把问题推给操作系统的软件包管理器。但这对以前像 go build && scp 那样直接的构建和部署过程来说，是有几个重大的变化。
完全静态地编译 Go 程序是可能的，但这绝不是简单的，这表明在项目中加入 cgo 的影响会波及整个构建和部署的生命周期。
明智的选择
说白了，我并不是说你不应该使用 cgo。但是在你做这个设计前，请仔细考虑你将会放弃的 Go 的许多品质。
需要考虑清楚得失，再思考是否值得你这么去做。
参考资料
[1]Cgo is not Go: https://dave.cheney.net/2016/01/18/cgo-is-not-go
