golang都有哪些包（原来是这么回事）

回想起来使用Go已三年有余，有很多踩过的坑。Go是门活力四射的语言，语法简单但表述能力强大且足够高效，但是也有很多细微的点，这些点就是一些基本细节实现，如果能注意这些细节，我相信我们能够对Go的理解能更深一些，写的bug会少一些。

作为一名初学者我们时常写对一些固定的写法，不知道为什么要这么写；我们时常写了一些bug，不知道为什么bug；我们时常知道可以这么写，但是不知道那样写是否可以；有时候我们很懒，懒得去测试是否可以，有时候我们很勤快，测试了并且知道答案，但是不求甚解；

再深一点？很多时候我们不求甚解，这天杀的产品经理又在催好像是个不错的借口。慢慢地又觉得自己理解不够深刻，所以总是闲暇的时候思考这些问题。我相信在二进制的世界里，nothing is magic, 一定是有Why的，因为这是我们所创造的世界 ( AI算法除外 ) 。

希望这篇文章能够帮到你，哪怕只是一点点。

go中其他的类型都是没有{}的， 只有interface{}有。

理解

go中其他的类型都是没有{} 的 比如 map[int]int, 但是interface{}都是带{}的，据说是为了让你瞅瞅里边什么也没有。

2. 函数参数是值传递的(Passed by value)现象

函数的参数是值传递，且在调用的时立即执行值拷贝的。

理解

首先，函数调用是值传递的。

所以无论传递什么参数都会被copy到函数的参数变量的内存地址中，堆或者栈上，具体是堆还是栈上涉及到逃逸问题，这里不做过多分析。但是毫无疑问的是，在调用时立即对变量进行了Copy，以下例子中通过打印变量地址佐证。

funcmain(){ variint fmt.Printf("main:%p\n",&i) foo(i) } funcfoo(iint){ fmt.Printf("foo:%p\n",&i) } //输出的变量地址不一样 main:0xc0000a0008 foo:0xc0000a0018

所以对于复杂结构我们应该尽量的传递指针减少copy时的开销。对于这里有看到不同的观点，主要是考虑到空指针问题，但是我仍然觉得应该使用指针。理由主要有以下几点

• 值传递会Copy对象，对于小内容对象，性能相差不大，但是在大结构下存在明显的性能损耗
• return 的时候可以直接 return nil, err，代码精简更加优雅
• nil pointer panic 应该通过error handling来解决，不然即使没有发生panic，也会执行错误的逻辑，引入更多的问题。

但是指针传递的同时也带来变量逃逸，和GC压力，也是一把双刃剑，好在大部分情况下不需要特别的对GC进行调优。所以，在make it simple的理念下，在需要时再针对性调优是个不错的选择。

所以什么时候我们应该传递值，什么时候应该传递指针，这主要取决于copy开销和是否需要在函数内部对变量值进行更改。我们可以用一个简单的例子测试下两者的性能差距：

funcpassedByValue(fooValue){ foo.C="1" } funcpassedByPointer(bar*Value){ bar.C="1" } //值传递 funcBenchmark_PassedByValue(b*testing.B){ varvalValue str:=bytes.Buffer{} //这里为了构建一个大值进行传递，小值因为copy代价太小性能差距不明显。 fori:=0;i<10000000;i { str.Write([]byte("=====")) } val.C=str.String() fori:=0;i<b.N;i { passedByValue(val) } } //指针传递 funcBenchmark_PassedByPointer(b*testing.B){ varval=new(Value) str:=bytes.Buffer{} fori:=0;i<10000000;i { str.Write([]byte("=====")) } val.C=str.String() fori:=0;i<b.N;i { passedByPointer(val) } } // Benchmark结果差距也很明显，但是一般值的copy代价都比较小，差距不明显。 goos:darwin goarch:amd64 pkg:demo/go Benchmark_PassedByValue-410000000000.676ns/op Benchmark_PassedByPointer-410000000000.383ns/op PASS

一般来说，基本类型我们都应该传值，自定义类型中一般内容不可控，所以养成良好的习惯很关键。特别注意的是slice、map、ctx是引用值类型，所以copy时并没有copy其中数据，所以一般也进行值传递，除非你要对其中更改其中的元素。但如果你需要更改其中的内容，还是建议更改完尽量返回回来一个新的，像内置的append函数一样，通过返回新的地址来实现。这样会更加清晰一些，写代码时自己尽量不要和自己过不去。

举个栗子，以下代码可能是一个bug：

funcmain(){ varids[]int appendSlice(ids) fmt.Println("main",len(ids)) } funcappendSlice(ids[]int){ fori:=0;i<4;i { ids=append(ids,i) } fmt.Println("appendSlice",len(ids)) } //输出，因为appendSlice中的ids并不是main中的ids. appendSlice4 main0

其次，Copy发生在函数调用的时候。比如利用这个原理就可以使用以下代码打印函数耗时。

funcdo(){ //因为defer语句执行的时候已经将函数参数转储，只是函数体执行时机有所调整 deferfunc(ttime.Time){ fmt.Println("doCost:"time.Slice(t).Second()) }(time.Now()) //balabalabala }

3. for _, i := range ss， ss 中的元素是 copy 到 变量i 的现象

for range 的时候 slice 中的元素是copy给 变量i的，并且下次for循环，变量i会被直接覆盖。并不是把 n号元素的地址给了i，i 是第n 号元素的 copy。

理解

值Copy会产生两个变量，i 是个临时变量，下一次for循环就会被覆写，而且因为是临时值，所以以下代码因为更改也不生效，也是非常常见的bug。

typeUserstruct{ Uidint } funcmain(){ users:=[]User{ {Uid:1},{Uid:2}, } foridx,i:=rangeusers{ i.Uid=2 fmt.Printf("i=%p,user_%d=%p\n",&i,idx,&users[idx]) } fmt.Println(users[0].Uid) } //输出 //i的地址不变，并且不是元素的地址 i=0xc00008c008,user_0=0xc00008c010 i=0xc00008c008,user_1=0xc00008c018 1//原数组中的userid并没有发生改变

要更改生效也很简单，主要有两种方案，一种是使用切片指针 []*User，这样对于i的修改会被自动寻址到数字元素上。另一种是使用下标 主动寻址如 users[idx].Uid = 2 。至于[]T还是[]*T 的问题我们接下来再讨论。

这个问题看似简单，如果将其使用go关键字并发将会发生巨大威力，造成血淋淋的事故。

其实用go的公司经常听到这样的事故：

• 某公司发运营push全部发给了同一个uid
• 某研发发运营消息发短信发给了同一个uid (如果通道商不限制，我相信用户哭了，哄不好的那种)
• 批量发优惠券，给同一个uid发了几百张
• ....

闭包问题一点都不新鲜，就是由于在go func里边使用for了循环的变量i了，然后因为函数体并没在go的时候立即执行需要申请资源挂载然后由M进行运行需要一些时间，所以一般for循环执行一段时间之后go func才会执行，这时候 内部函数取到的值就得听天命了。

经典bug复现

funcmain(){ for_,i:=range[]int{1,2,3}{ gofunc(){ println(i) }() } time.Sleep(1*time.Millisecond) } //只会打印3，因为等到func执行的时候i已经变成3了 //所以把i当做匿名函数的参数传进去或者在for中重新定义一个变量是个不错的做法 3 3 3

所以，使用匿名函数的时候go func的时候要时刻注意循环变量的Scope, 该传参传参，该重新定义重新定义。好在 Goland 最新版本已经会提示i存在Scope问题了。但是好像没几个人会注意IDE警告，所以，习惯很重要，不要写出IDE警告的代码也是一个不错的编程理念。

4. []T 还是 []*T现象

一般来说[]T 会比较高效一些，但是如果T比较大，在For循环时存在Copy开销，个人觉得[]*T也是可以的。

5. []interface{}并不能接收[]T类型现象

很多时候我们都以为interface可以传递任意类型，凡事总有例外，他就不能接收 []T 类型, 如果你需要进行赋值，那你要将T转成interface{}

理解

因为一个[]interface{}的空间是一定的，但是 []T 不是，因为占用空间不一致，编译器觉得有些代价，并没有进行转换.

6. Send on closed chan 会Panic，但是 Receive from closed chan 不会现象

往已经关闭的channel 再send数据会触发runtime panic，但是receive从已经关闭的channel中消费不会触发.

理解

很多人有误区，认为chan关闭了就不能再操作了，但是send进chan的数据总归要消费完的，不然就丢了，你品。

7. Goroutine 之间不能 Recover painc现象

goroutine没有父子关系（创建应该不算父子吧），不能在一个go中 recover 另一个 go 的 panic

理解

GPM模型在go的调度时没有上下级关系, 也没有跨goroutine的异常捕获机制。

8. error 是一个实现了Error()string 方法的任意类型.现象

error 被定义为 interface{ Error()string }，只要实现该方法的类型，其值都可以认为是error

9. 是否实现某个interface的的判断是区别对待 *T 和 T 的现象

一个接口实现必须实现接口定义的全部方法，使用 指针类型的receiver 和 值类型的 receiver 是两个不同的实现。

解释

*张三不吃香菜，不等于张三不吃香菜。

typeUserinterface{ Eat(foodinterface{})(bool,error) } typeZhangSanstruct{ Namestring } //*ZhangSan实现了User接口 //但是ZhangSan没有实现 func(*ZhangSan)Eat(foodinterface{})(bool,error){ iffood=="香菜"{ returnfalse,nil } returntrue,nil } funcuserEat(uUser,foodstring)(bool,error){ returnu.Eat(food) } funcmain(){ someone:=ZhangSan{Name:"张三"} //这里someone是不能传递给userEat的 //因为 ZhangSan 这个结构没有实现 User 接口, 只能用&ZhangSan进行传递。 //userEat(someone,"花生") userEat(&someone,"花生") }

所以，实现接口时receiver类型要统一。

10. Reveiver 在函数调用时其实是作为函数第一参数传递给函数的现象

receiver 是可以为 nil 的

解释

如果你细心看过panic的日志就会发现，打印日志的时候 receiver其实是作为函数第一参数传递的。所以，你可以在method中对receiver进行空值判断，来防止panic的发生。

funcmain(){ varsomeone*ZhangSan _,_=someone.Eat("花生") } //如果在Eat中没有对receiver进行空值判断也可能引发空指针异常 goroutine1[running]: main.(*ZhangSan).Eat(0x0,0x10aafc0,0x10e9680,0x0,0x10a9ec0,0xc0000200b8) /Users/haoliu/demo/go/main.go:16 0x26 main.main() /Users/haoliu/demo/go/main.go:30 0x42

总结

以上就Go在日常使用过程中的基本点进行了一下总结，是golang日常使用过程中经常碰到的点。由于水平有限，如果存在某些表述不清楚的地方，可以一起讨论下。

作者：保护我方李元芳，授权发布

链接：https://juejin.im/post/6881267557346344974

来源：掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

,