核心思想
在defer出现的地方插入了指令CALL runtime.deferproc，在函数返回的地方插入了CALL runtime.deferreturn。goroutine的控制结构中，有一张表记录defer，调用runtime.deferproc时会将需要defer的表达式记录在表中，而在调用runtime.deferreturn的时候，则会依次从defer表中“出栈”并执行
如果有多个defer，调用顺序类似栈，越后面的defer表达式越先被调用
defer链
defer信息会注册到链表，当前执行的 goroutine 持有这个链表的头指针，每个 goroutine 都有一个对应的结构体struct G，其中有一个字段指向这个defer链表头
新注册的defer会添加到链表头，所以感觉像是栈那样先进后出的调用：
源码分析
deferproc一共有两个参数，第一个是参数和返回值的大小，第二个是指向funcval的指针
defer将参数注册的时候拷贝到堆上，执行时再（将参数和返回值）拷贝回栈上
go会分配不同规格的_defer pool，执行时从空闲_defer中取一个出来用，没有合适的再进行堆分配。用完以后再放回空闲_defer pool。以避免频繁的堆分配和回收
优化
go1.12中defer存在的问题：
- defer信息主要存储在堆上，要在堆和栈上来回拷贝返回值和参数很慢
- defer结构体通过链表链起来，而链表的操作也很慢
go1.13中defer的优化：
- 减少了defer信息的堆分配。再通过deferprocStack将整个defer注册到defer链表中
- 将一般情况的defer信息存储在函数栈帧的局部变量区域
- 显示循环或者是隐式循环的defer还是需要用到go1.12中defer信息的堆分配
- 官方给出的性能提升是30%
go1.14中defer的优化：
- 在编译阶段插入代码，把defer函数的执行逻辑展开在所属函数内，避免创建defer结构体，而且不需要注册到defer链表。称为 open coded defer
- 与1.13一样不适用于循环中的defer
- 性能几乎提升了一个数量级
- open coded defer 中发生panic 或 调用runtime.Goexit()，后面未注册到的defer函数无法执行到，需要栈扫描。defer结构体中就多添加了一些字段，借助这些字段可以找到未注册到链表中的defer函数
结果就是defer变快了，但是panic变慢了
defer添加了局部变量去判断是否需要执行，需要执行的话就将标识df对应的位上或一下，如果是有条件的defer，需要根据具体条件去或df
deferprocStack