我们已经知道当前执行的goroutine中有一个defer链表的头指针，其实它也有一个panic链表头指针。panic链表连起来的，是一个一个_panic结构体，和defer链表一样，发送新的panic时，也是在链表头上插入新的_panic结构体。所以链表头上的panic，就是当前正在执行的那一个。
来看个例子，这里函数A注册了两个defer函数A1和A2后发生panic， 执行到panic后，panic后面的代码就不会执行了，而是进入panic处理逻辑，首先在panic链表中增加一项，记为panicA，它就是当前正在执行的panic，然后就该执行defer链表了。
从头开始执行，不过与函数正常执行defer有些不同，panic执行defer时，会先把它的started置为true，标记它已经开始执行，并且会把_panic字段指向当前执行的panic。表示这个defer是由这个panic触发的。
回到例子中，A2执行前也要先标记，如果函数A2能正常结束，这一项defer就会被移除，继续执行下个defer。之所有这样设计，是为了应对defer函数没有正常结束的情况。
例如接下来要执行的defer函数A1中，会再次发生panic，执行前同样标记它的started和_panic字段，当A1执行到这里时再次发生panic，这后面的代码也不会执行了，然后在panic链表头插入一个新的panic，
现在它成为当前执行的panic了。然后同样去执行defer链表，但是发现A1已经执行，并且触发它执行的并不是当前的panicA1。所以要根据这里记录的panic指针，找到对应的panic，并把它标记为已终止。
是时候把_panic结构体展开了，第一个字段存储panic当前执行的defer的函数参数地址，下面这个字段就是panic函数自己的参数了，link链到之前发生的panic，recovered表示panic是否被恢复，aborted表示panic是否被终止。所以回到例子中，panicA被终止。
这里不仅要把panicA标识为已终止，还要把deferA1这一项移除
接下来就该打印panic信息了，注意panic打印异常信息时，会从链表尾开始，也就是按照panic发生的顺序逐个输出，所以这里会先输出panicA，然后是panicA1，没有发生recover时panic的处理逻辑就是这样。
关键点有两个：
- 第一个是panic执行defer函数的方式，先标记后释放，目的是为了终止之前发生的panic。
- 第二个是异常信息的输出方式，所有还在panic链表上的项都会被输出，顺序与panic发生的顺序一致
接下来增加recover看看， recover本身的逻辑很简单，它只做一件事，就是把当前执行的panic置为已恢复，也就是把它的recovered字段置为true，其他的都不管。
函数A里有两个defer函数，并且会发生panic，而defer函数A2中会执行recover，panic发生时，当前goroutine中defer链表只有A1和A2，panic链表有一项，标记为panicA。panicA触发defer执行，先执行函数A2，执行到第一行发生recover，把当前执行的panicA置为已恢复，然后recover函数的任务就完成了。程序继续往下走，直到A2结束。
其实在每个defer执行完之后，panic处理流程都会检查当前panic是否被它恢复了。此时发现panicA已经被恢复，就会把它从链表中移除，A2这一项也会从defer链表中移除 。不过在移除前，要保存_defer.sp和_defer.pc这两个字段的值，接下来要做的就是利用保存的sp和pc跳出panicA的处理流程。
但是要怎么跳出来呢？又恢复到哪里去呢？我们知道，sp和pc是注册defer函数时保存的，这里sp就是函数A的栈指针，而pc字段，就是调用deferproc函数的返回地址（下一条指令的地址） ，这就是这段伪指令中判断返回值是否大于零的这部分逻辑。
通过sp可以恢复到函数A的栈帧，通过pc可以恢复到这里的指令地址，但是r就不能是0了，否则函数A就会重复执行，我们之前提过，这个返回值被编译器保存在一个寄存器中，所以只要把它置为1，就可以执行goto ret，跳转到deferreturn这里，继续执行defer链表了 。
不过要注意的是，deferreturn只负责执行当前函数A注册的defer函数，它是通过栈指针来判断的，defer链表中接下来要执行的A1 ，也是函数A注册的，所以函数A1执行，A1结束后defer链表为空，函数A结束。
这就是recover的基本处理流程。虽然recover函数只设置了当前panic的一个属性，但是会引发panic处理流程，移除被恢复的panic并跳出当前panic的处理流程。但是要注意，在发生recover的函数正常返回以后，才会进入到检测panic是否被恢复的流程，然后才能删除被恢复的panic。
如果发生recover的defer函数在返回之前又发生了panic，情况就又不一样了了。我们先恢复到recover发生时defer链表和panic链表的状态。执行到这里再次panic时，panic链表增加一项。记为panicA2，它成为当前panic，并且执行defer链表，发现A2已经由之前的panicA执行了，所以把panicA终止，并把A2从defer链表中移除，继续执行下一个，A1就是由panicA2触发执行的了。
A1结束后被移除，defer链表为空，接下来就要输出异常现象了，注意，对于panic链表中已经被恢复的panic，打印它的信息时，会加上recovered标记。panic链表每一项都输出后，程序退出。这个例子主要是帮助我们理解，被恢复的panic在什么情况下不会被移除。
下面我们再看一个例子，这一次我们结合函数调用关系来弄清楚recover发生后，程序究竟会恢复到哪里，这里函数A注册了两个defer函数后发生panic，defer函数A1可以正常执行，但是defer函数A2注册了defer函数B1后再次panic，而defer函数B1会发生recover。
首先注册两个defer函数A1和A2，发生panic时，实际上会调用runtime.gopanic函数，它负责添加panic链表项，并执行defer链表。panicA首先会执行defer函数A2，A2会注册一个defer函数B1，然后再次发生panic，所以函数A2也会调用gopanic函数。panicA2也去执行defer链表。
首先是B1，B1执行时调用recover函数，把panicA2置为已恢复。
B1正常结束后，返回到panicA2的处理流程，检测到panicA2已恢复，把它从链表中移除 ，因为defer函数B1是函数A2注册的，所以跳出panicA2的处理逻辑后，程序会恢复到函数A2的栈帧。
通过之前介绍的方式，最终会跳转到A2这里，调用deferreturn函数的地方继续执行，因为函数A2注册的defer函数B1已经执行完了，所以deferreturn函数返回，然后函数A2返回。返回到哪里呢，因为函数A2是由panicA触发调用的，所以函数A2结束后，程序再次回到panicA的处理流程，继续执行defer链表。
简单回顾一下，B1中recover发生后，会跳出当前执行的panicA2处理流程，恢复到注册函数B1的函数栈帧。A2结束后会返回到触发它执行的panicA的处理流程，现在你知道recover发生后，究竟会恢复到哪里了吧。
Go1.14版本以前，panic和recover的基本处理流程就是这样，由于Go1.14中使用了open coded defer，导致panic执行defer链表时，不能如同之前这般轻松，需要通过扫描栈来找到未注册到defer链表的defer函数。但是panic和recover的总体设计思想，在这些版本中都是一致的
总结- 有defer有panic, defer中没有recover且没有panic
此种情况panic没有嵌套，defer可以正常结束，唯一的一个panic执行完defer链表，就会打印panic信息。 - 有defer有panic, defer中有panic，但是没有recover
出现panic嵌套，defer无法正常结束，此时，后面的panic会把前面的panic标记为aborted - 有defer有panic, defer中有recover，但是没有panic
已标记为recover的panic会被从panic链表中移除。不会在打印panic信息时输出该panic信息 - 有defer有panic, defer中同时有recover, panic
此时，recover中会被标记，后面的panic会将该panic标记为aborted。由于defer不能正常结束，所以被标记为recovered的panic仍然不能被移除。