前言回想起来使用Go已三年有余，有很多踩过的坑。Go是门活力四射的语言，语法简单但表述能力强大且足够高效，但是也有很多细微的点，这些点就是一些基本细节实现，如果能注意这些细节，我相信我们能够对Go的理解能更深一些，写的bug会少一些。
作为一名初学者我们时常写对一些固定的写法，不知道为什么要这么写；我们时常写了一些bug，不知道为什么bug；我们时常知道可以这么写，但是不知道那样写是否可以；有时候我们很懒，懒得去测试是否可以，有时候我们很勤快，测试了并且知道答案，但是不求甚解；
再深一点？很多时候我们不求甚解，这天杀的产品经理又在催好像是个不错的借口。慢慢地又觉得自己理解不够深刻，所以总是闲暇的时候思考这些问题。我相信在二进制的世界里，nothing is magic, 一定是有Why的，因为这是我们所创造的世界 ( AI算法除外 ) 。
希望这篇文章能够帮到你，哪怕只是一点点。
Common Sense in Go1. interface{} 后面是有{}的现象go中其他的类型都是没有{}的， 只有interface{}有。
理解go中其他的类型都是没有{} 的 比如 map[int]int, 但是interface{}都是带{}的，据说是为了让你瞅瞅里边什么也没有。
2. 函数参数是值传递的(Passed by value)现象函数的参数是值传递，且在调用的时立即执行值拷贝的。
理解首先，函数调用是值传递的。
所以无论传递什么参数都会被copy到函数的参数变量的内存地址中，堆或者栈上，具体是堆还是栈上涉及到逃逸问题，这里不做过多分析。但是毫无疑问的是，在调用时立即对变量进行了Copy，以下例子中通过打印变量地址佐证。
func main() { var i int fmt.Printf("main: %p\n", &i) foo(i)}func foo(i int) { fmt.Printf("foo : %p\n", &i)}// 输出的变量地址不一样main: 0xc0000a0008foo : 0xc0000a0018所以对于复杂结构我们应该尽量的传递指针减少copy时的开销。对于这里有看到不同的观点，主要是考虑到空指针问题，但是我仍然觉得应该使用指针。理由主要有以下几点
值传递会Copy对象，对于小内容对象，性能相差不大，但是在大结构下存在明显的性能损耗return 的时候可以直接 return nil, err，代码精简更加优雅nil pointer panic 应该通过error handling来解决，不然即使没有发生panic，也会执行错误的逻辑，引入更多的问题。但是指针传递的同时也带来变量逃逸，和GC压力，也是一把双刃剑，好在大部分情况下不需要特别的对GC进行调优。所以，在make it simple的理念下，在需要时再针对性调优是个不错的选择。
所以什么时候我们应该传递值，什么时候应该传递指针，这主要取决于copy开销和是否需要在函数内部对变量值进行更改。我们可以用一个简单的例子测试下两者的性能差距：
func passedByValue(foo Value) { foo.C = "1"}func passedByPointer(bar *Value) { bar.C = "1"}// 值传递func Benchmark_PassedByValue(b *testing.B) { var val Value str := bytes.Buffer{} // 这里为了构建一个大值进行传递，小值因为copy代价太小性能差距不明显。 for i:=0; i < 10000000; i ++ { str.Write([]byte("=====")) } val.C = str.String() for i := 0; i < b.N; i++ { passedByValue(val) }}// 指针传递func Benchmark_PassedByPointer(b *testing.B) { var val = new(Value) str := bytes.Buffer{} for i:=0; i < 10000000; i ++ { str.Write([]byte("=====")) } val.C = str.String() for i := 0; i < b.N; i++ { passedByPointer(val) }}// Benchmark结果差距也很明显，但是一般值的copy代价都比较小，差距不明显。goos: darwingoarch: amd64pkg: demo/goBenchmark_PassedByValue-4 1000000000 0.676 ns/opBenchmark_PassedByPointer-4 1000000000 0.383 ns/opPASS一般来说，基本类型我们都应该传值，自定义类型中一般内容不可控，所以养成良好的习惯很关键。特别注意的是slice、map、ctx是引用值类型，所以copy时并没有copy其中数据，所以一般也进行值传递，除非你要对其中更改其中的元素。但如果你需要更改其中的内容，还是建议更改完尽量返回回来一个新的，像内置的append函数一样，通过返回新的地址来实现。这样会更加清晰一些，写代码时自己尽量不要和自己过不去。
举个栗子，以下代码可能是一个bug：
func main() { var ids []int appendSlice(ids) fmt.Println("main", len(ids))}func appendSlice(ids []int) { for i := 0; i < 4; i++ { ids = append(ids, i) } fmt.Println("appendSlice", len(ids))}// 输出， 因为appendSlice中的ids并不是main中的ids.appendSlice 4main 0其次，Copy发生在函数调用的时候。比如利用这个原理就可以使用以下代码打印函数耗时。
func do(){ // 因为 defer 语句执行的时候已经将函数参数转储，只是函数体执行时机有所调整 defer func(t time.Time) { fmt.Println("do Cost: "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。
type User struct { Uid int}func main() { users := []User{ {Uid: 1}, {Uid: 2}, } for idx, i := range users { 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=0xc00008c010i=0xc00008c008, user_1=0xc00008c0181 // 原数组中的user id并没有发生改变要更改生效也很简单，主要有两种方案，一种是使用切片指针 []*User，这样对于i的修改会被自动寻址到数字元素上。另一种是使用下标 主动寻址如 users[idx].Uid = 2 。至于[]T还是[]*T 的问题我们接下来再讨论。
这个问题看似简单，如果将其使用go关键字并发将会发生巨大威力，造成血淋淋的事故。
其实用go的公司经常听到这样的事故：
某公司发运营push全部发给了同一个uid某研发发运营消息发短信发给了同一个uid (如果通道商不限制，我相信用户哭了，哄不好的那种)批量发优惠券，给同一个uid发了几百张....闭包问题一点都不新鲜，就是由于在go func里边使用for了循环的变量i了，然后因为函数体并没在go的时候立即执行需要申请资源挂载然后由M进行运行需要一些时间，所以一般for循环执行一段时间之后go func才会执行，这时候 内部函数取到的值就得听天命了。
经典bug复现
func main() { for _, i := range []int{1, 2, 3} { go func() { println(i) }() } time.Sleep(1* time.Millisecond)}// 只会打印 3， 因为等到func执行的时候 i已经变成3了// 所以把 i 当做 匿名函数的参数传进去或者在for中重新定义一个变量是个不错的做法333所以，使用匿名函数的时候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 是两个不同的实现。
解释*张三不吃香菜，不等于张三不吃香菜。
type User interface { Eat(food interface{}) (bool, error)}type ZhangSan struct { Name string}// *ZhangSan 实现了 User 接口// 但是 ZhangSan 没有实现func (*ZhangSan) Eat(food interface{}) (bool, error) { if food == "香菜" { return false, nil } return true, nil}func userEat(u User,food string) (bool, error){ return u.Eat(food)}func main() { someone := ZhangSan{Name: "张三"} // 这里 someone 是不能传递给 userEat 的 // 因为 ZhangSan 这个结构没有实现 User 接口, 只能用 &ZhangSan进行传递。 // userEat(someone, "花生") userEat(&someone, "花生")}所以，实现接口时receiver类型要统一。
10. Reveiver 在函数调用时其实是作为函数第一参数传递给函数的现象receiver 是可以为 nil 的
解释如果你细心看过panic的日志就会发现，打印日志的时候 receiver其实是作为函数第一参数传递的。所以，你可以在method中对receiver进行空值判断，来防止panic的发生。
func main() { var someone *ZhangSan _, _ = someone.Eat("花生")}// 如果在Eat 中没有对 receiver进行空值判断也可能引发 空指针异常goroutine 1 [running]:main.(*ZhangSan).Eat(0x0, 0x10aafc0, 0x10e9680, 0x0, 0x10a9ec0, 0xc0000200b8) /Users/haoliu/demo/go/main.go:16 +0x26main.main() /Users/haoliu/demo/go/main.go:30 +0x42总结以上就Go在日常使用过程中的基本点进行了一下总结，是golang日常使用过程中经常碰到的点。由于水平有限，如果存在某些表述不清楚的地方，可以一起讨论下。
作者：保护我方李元芳，授权发布
链接：
来源：掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
