如果用下面的方式，执行到第一个panic就会跳出for循环
只能输出第一个匹配项，然后退出for循环。
那么如何保证在for循环处理完panic不退出循环，直到打印完所有满足条件的数值？
golang的panic被恢复后,能继续执行比recover更早的defer，或者返回到recover函数的调用方，然后继续执行下去。
所以，我们可以把panic和recover放到单独的函数中，然后在for循环里调用这个函数，这个函数panic并恢复后，能返回到调用方for循环并继续循环下去。
执行结果是所有0到100的所有符合panic条件的都能正确处理，for循环没有异常退出：
golang的panic属于非常严重的错误，一旦panic没有recover的话，程序就退出了。一般避免主动panic，影响程序稳定性。
recover函数要放在defer里面，并且只能恢复同一个goroutine的并且是直接调用链函数发生的panic。recover不能恢复上一层函数的panic。
一、go中为什么不允许循环依赖二、如何解决循环依赖
循环依赖就是A引用B，B又引用A，形成了一个包引用的闭环。要解决循环引用，就是打破这个闭环，让A引用B，B不能引用A。看下面的例子：
包结构如下：
执行main函数报错：
报错的原因是 我们在执行bagA.PrintA()的时候，引用了A包，A包又引用了B包，B包又引用了A包，形成了循环依赖。那我们打破依赖就可以了。
那么该怎么打破呢？
我们发现A包引用B包，是因为A包需要调用B包的bagB.GetName()方法；同样的，B包引用A包，是因为B包需要调用A包的bagA.GetName()方法。那么，我们有没有不需要引包就能使B包可以调用A包的方法呢？
当然是有的。看下面：
我们在B包里定义了一个方法变量AHandler，并且提供了为这个方法变量赋值的方法Register()，然后在A包里的init()方法里，调用B包的Register()方法，将A包的GetName方法复赋值给了AHandler变量。 这样，在B包执行方法AHandler是不是就相当于调用了A包的GetName方法呢？看执行结果：
总结：
上述解决办法的核心逻辑就是，B包使用一个方法变量来替代A中的方法（来完成B不引用A），A来为该变量赋值（因为A引用B，A可以调用B的方法来完成赋值）。 解决循环依赖问题，思想就是打破包的循环依赖，以不导包的方式调用其他包的方法。所以，采用接口的形式也可以解决循环依赖（B定义一个接口，A中你想要调用的方法实现了该接口，A中完成接口变量赋值，B来调用接口方法，有时间再补充例子吧）
队列的概念在 顺序队列 中，而使用循环队列的目的主要是规避假溢出造成的空间浪费，在使用循环队列处理假溢出时，主要有三种解决方案
本文提供后两种解决方案。
顺序队和循环队列是一种特殊的线性表，与顺序栈类似，都是使用一组地址连续的存储单元依次存放自队头到队尾的数据元素，同时附设队头(front)和队尾(rear)两个指针，但我们要明白一点，这个指针并不是指针变量，而是用来表示数组当中元素下标的位置。
本文使用切片来完成的循环队列，由于一开始使用三个参数的make关键字创建切片，在输出的结果中不包含nil值(看起来很舒服)，而且在验证的过程中发现使用append()函数时切片内置的cap会发生变化，在消除了种种障碍后得到了一个四不像的循环队列，即设置的指针是顺序队列的指针，但实际上进行的操作是顺序队列的操作。最后是对make()函数和append()函数的一些使用体验和小结，队列的应用放在链队好了。
官方描述(片段)
即切片是一个抽象层，底层是对数组的引用。
当我们使用
构建出来的切片的每个位置的值都被赋为interface类型的初始值nil，但是nil值也是有大小的。
而使用
来进行初始化时，虽然生成的切片中不包含nil值，但是无法通过设置的指针变量来完成入队和出队的操作，只能使用append()函数来进行操作
在go语言中，切片是一片连续的内存空间加上长度与容量的标识，比数组更为常用。使用 append 关键字向切片中追加元素也是常见的切片操作
正是基于此，在使用go语言完成循环队列时，首先想到的就是使用make(type, len, cap)关键字方式完成切片初始化，然后使用append()函数来操作该切片，但这一方式出现了很多问题。在使用append()函数时，切片的cap可能会发生变化，用不好就会发生扩容或收缩。最终造成的结果是一个四不像的结果，入队和出队操作变得与指针变量无关，失去了作为循环队列的意义，用在顺序队列还算合适。
参考博客：
Go语言中的Nil
Golang之nil
Go 语言设计与实现
