nil 接口不是 nil
https://mp.weixin.qq.com/s/i2jA817fXK7TxyA3lLP22A
nil 接口不是 nil
我们强行将一段 Go 程序的变量值赋为 nil，并进行 nil 与 nil 的判断。
代码如下：
func main() {
var v interface{}
v = (*int)(nil)
fmt.Println(v == nil)
}
输出的结果是什么。是 false，还是 true，又或是抛出异常？
输出结果是 fasle，nil 可不 100% 等于 nil。
这与 interface 的内部数据结构有关，是在编程时要注意的一个细节，具体可详见《Go 面试题：Go interface 的一个 “坑” 及原理分析》的解析。
垃圾回收
Go 非常简洁，垃圾回收唯一的可调节的是 GC 频率，可以通过 GOGC 变量设置初始垃圾收集器的目标百分比值。
$ GOGC=100 eddycjy
简单来讲就是，GOGC 的值设置的越大，GC 的频率越低，但每次最终所触发到 GC 的堆内存也会更大。
然后就没别的方式可以优化垃圾回收器本身了，以至于当年我还被人拿 Java 来吐槽过一遍，说 Go 肯定有。
依赖管理
压轴的难受点，莫过于 Go 的依赖管理。先是从 GOPATH 时代，开源后一路水土不服，后面 rsc 直接下场支棱起来硬推。
到 2022 年，目前 Go modules 还是会存在一些让人难受的点。甚至曹大总结了 《Go mod 七宗罪》，不少我在工作中也遇到和替别人解决过，非常的精辟。
引用曹大文章中的 7 点：
- Go 命令的副作用：所有 go build、go list、go test 多多少少都会拉取到墙外的资源，会很慢。
- 形同虚设的 semver 规范：go mod 的设计，就是希望大家在软件库发布时都要遵守标准，例如在小版本时，要保持兼容性。但这非常理想化，现实就是经常有人不遵守。
- 无法应对删库：发布后的软件库，你已经拉取了。但发布者依然可以删除，受伤的还是自己。
- goproxy 的实现并不统一：作者 A、作者 B、作者 C 写的几套 goproxy 内部逻辑是不完全一致的，很折腾人。
- go get 到的 lib 版本在 go build 时被修改。
- 版本信息扩散：导入路径是包含版本号 v1、v2 等信息的，一旦修改，就得大面积替换。
- go.sum 合并冲突：大型项目上的多人维护，导致频繁冲突。
熟悉掌握 Go 的一个表现，那就是精通 Go modules，不然项目都运行的不顺利。
总结
今天我们围绕 Go 的难受场景进行了分析和讲解，本文涉及的分别是：泛型、浅拷贝和泄露、错误处理、nil 接口不是 nil、垃圾回收、依赖管理。
其中不少是常见的，也有的是有意而为之（例如：垃圾回收）。从大家的角度来看，你觉得 Go 比较难受的点还有哪些呢？
欢迎大家在评论区一起留言和交流。
推荐阅读
参考
- golang有什么致命的问题吗？
- Go mod 七宗罪
