【Golang】defer的这些坑，你遇到过吗？
前言
之前的文章中分享了关于defer的一些用法和实现原理，但是在实际使用过程中，总会踩不少坑（在上一篇最后的总结中也有一些关于特性的总结），这篇文章中将结合代码的方式展现，希望能帮到你少走弯路。
1：延迟函数传递的参数是值
func deferTest() {var a = 1defer fmt.Println(a)a = 2return}
结论：延迟函数 fmt.Println(a) 的参数在 defer 语句出现的时候就已经确定下来了，所以不管后面如何修改 a 变量，都不会影响延迟函数
2：延迟函数传递的参数是地址
func deferTest() {var arr = [3]int{1, 2, 3}defer printTest(&arr)arr[0] = 4return}func printTest(array *[3]int) {for i := range array {fmt.Println(array[i])}}
结论：延迟函数 printTest() 的参数在 defer 语句出现的时候就已经确定下来了，即为数组的地址，延迟函数执行的时机是在 return 语句之前，所以对数组的最终修改的值会被打印出来。
3：延迟函数可能会影响函数的返回值
fmt.Println(deferTest)func deferTest() (result int) {i := 1defer func() {result = 2}()return i}
结论：函数的 return 语句并不是原子级的，实际的执行过程为为设置返回值—>ret，defer 语句是在返回前执行，所以返回过程是：「设置返回值—>执行defer—>ret」。所以 return 语句先把 result 设置成 i 的值（1），defer 语句中又把 result设置为 2 ，所以最终返回值为 2
4：defer需要定义在panic前
func panicBeforeDefer() {panic("a")defer func() {fmt.Println("b")}()}func panicAfterDefer() {defer func() {fmt.Println("b")}()panic("a")}
结论：代码执行到了painc之后再执行的defer，然后按照defer的先进后出的顺序执行defer,最后才执行panic。那为什么panic时会执行defer，可以看下这段代码就很清楚了。
func gopanic(e interface{}) {gp := getg()...var p _panicp.arg = ep.link = gp._panicgp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))for {d := gp._deferif d == nil {break}...}}
5：先判断err，再defer释放资源
func openFile() {file, err := os.Open("txt")if err != nil {return}defer file.Close()}
结论：获取文件资源的时候会返回err，如果我们在后续需要进行defer释放文件资源时，这里需要对err进行判断。因为如果获取文件资源失败的时候不需要进行释放，也避免了没获取到资源可能导致的释放函数执行错误。
6：os.Exit时defer不会被执行
func deferExit() {defer func() {fmt.Println("exit")}()os.Exit(1)}
结论:上面代码中的defer不会得到执行，因为os.Exit()用于立即中止程序，不可能恢复或运行延迟清理语句，不像panic会去找goroutine的defer链表。
微信扫码关注该文公众号作者
戳这里提交新闻线索和高质量文章给我们。
来源: qq
点击查看作者最近其他文章