13518219792
是病毒干扰了这个软件的正常运行。
公司主营业务：网站设计、成都网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联公司推出扎兰屯免费做网站回馈大家。
可能是盘不好，我有张盘玩起来一直会死机建议你用360系统急救箱在安全模式下帮你修复一下，修复成功后应该就可以了。
如下的例子，要打印100以内能被5整除的数，以panic的方式选择出来并打印。
如果用下面的方式，执行到第一个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。
golang在1.6.2的时候还没有自己的context，在1.7的版本中就把golang.org/x/net/context包被加入到了官方的库中。中文译作“上下文”，它主要包含了goroutine 的运行状态、环境等信息。
context 主要用来在 goroutine 之间传递上下文信息，包括：同步信号、超时时间、截止时间、请求相关值等。
该接口定义了四个需要实现的方法：
如果有个网络请求Request，然后这个请求又可以开启多个goroutine做一些事情，当这个网络请求出现异常和超时时，这个请求结束了，这时候就可以通过context来跟踪这些goroutine，并且通过Context来取消他们,然后系统才可回收所占用的资源。
为了更方便的创建Context，包里头定义了Background来作为所有Context的根，它是一个emptyCtx的实例。
Background返回一个非空的Context。它永远不会被取消。它通常用来初始化和测试使用，作为一个顶层的context，也就是说一般我们创建的context都是基于Background。
TODO返回一个非空的Context。当不清楚要使用哪个上下文的时候可以使用TODO。
他们两个本质上都是emptyCtx结构体类型，是一个不可取消，没有设置截止时间，没有携带任何值的Context。
有了如上的根Context，那么是如何衍生更多的子Context的呢？这就要靠context包为我们提供的With系列的函数了。
通过这些函数，就创建了一颗Context树，树的每个节点都可以有任意多个子节点，节点层级可以有任意多个。
WithCancel函数，最常用的派生 context 方法。该方法接受一个父 context。父 context 可以是一个 background context 或其他 context。
WithDeadline函数，该方法会创建一个带有 deadline 的 context。当 deadline 到期后，该 context 以及该 context 的可能子 context 会受到 cancel 通知。另外，如果 deadline 前调用 cancelFunc 则会提前发送取消通知。
WithTimeout和WithDeadline基本上一样，这个表示是超时自动取消，是多少时间后自动取消Context的意思。
WithValue函数和取消Context无关，它是为了生成一个绑定了一个键值对数据的Context，这个绑定的数据可以通过Context.Value方法访问到，一般我们想要通过上下文来传递数据时，可以通过这个方法，如我们需要tarce追踪系统调用栈的时候。
使用Context的程序应遵循以下规则，以使各个包之间的接口保持一致：
1.不要将 Context 塞到结构体里。直接将 Context 类型作为函数的第一参数，而且一般都命名为 ctx。
2.不要向函数传入一个 nil 的 context，如果你实在不知道传什么，标准库给你准备好了一个 context：todo。
3.不要把本应该作为函数参数的类型塞到 context 中，context 存储的应该是一些共同的数据。例如：登陆的 session、cookie 等。
4.同一个 context 可能会被传递到多个 goroutine，别担心，context 是并发安全的。
2021-11-10
列表是一种非连续的存储容器，有多个节点组成，节点通过一些变量记录彼此之间的关系
单链表和双链表就是列表的两种方法。
原理：A、B、C三个人，B懂A的电话，C懂B的电话只是单方知道号码，这样就形成了一个单链表结构。
如果C把自己的号码给B，B把自己的号码给A，因为是双方都知道对方的号码，这样就形成了一个双链表结构
如果B换号码了，他需要通知AC，把自己的号码删了，这个过程就是列表的删除操作。
在Go语言中，列表使用 container/list 包来实现，内部的实现原理是双链表，列表能够高效地进行任意位置的元素插入和删除操作。
列表初始化的两种办法
列表没有给出具体的元素类型的限制，所以列表的元素可以是任意类型的，
例如给列表中放入了一个 interface{} 类型的值，取出值后，如果要将 interface{} 转换为其他类型将会发生宕机。
双链表支持从队列前方或后方插入元素，分别对应的方法是 PushFront 和 PushBack。
列表插入函数的返回值会提供一个 *list.Element 结构，这个结构记录着列表元素的值以及与其他节点之间的关系等信息，从列表中删除元素时，需要用到这个结构进行快速删除。
遍历完也能看到最后的结果
学习地址：
我来帮你吧，我有种方法，可以马上关掉go，就是可能会丢失点数据，你可以按你旁边那个电源开关，上下拉5次，记得不要锁掉，就一上一下，重复5次。。。
这个问题说来话长，我先表达一下我的观点，Go语言从语法层面提供区分错误和异常的机制是很好的做法，比自己用单个返回值做值判断要方便很多。
上面看到很多知乎大牛把异常和错误混在一起说，有认为Go没有异常机制的，有认为Go纯粹只有异常机制的，我觉得这些观点都太片面了。
具体对于错误和异常的讨论，我转发一下前阵子写的一篇日志抛砖引玉吧。
============================
最近连续遇到朋友问我项目里错误和异常管理的事情，之前也多次跟团队强调过错误和异常管理的一些概念，所以趁今天有动力就赶紧写一篇Go语言项目错误和异常管理的经验分享。
首先我们要理清：什么是错误、什么是异常、为什么需要管理。然后才是怎样管理。
错误和异常从语言机制上面讲，就是error和panic的区别，放到别的语言也一样，别的语言没有error类型，但是有错误码之类的，没有panic，但是有throw之类的。
在语言层面它们是两种概念，导致的是两种不同的结果。如果程序遇到错误不处理，那么可能进一步的产生业务上的错误，比如给用户多扣钱了，或者进一步产生了异常；如果程序遇到异常不处理，那么结果就是进程异常退出。
在项目里面是不是应该处理所有的错误情况和捕捉所有的异常呢？我只能说，你可以这么做，但是估计效果不会太好。我的理由是：
如果所有东西都处理和记录，那么重要信息可能被淹没在信息的海洋里。
不应该处理的错误被处理了，很容易导出BUG暴露不出来，直到出现更严重错误的时候才暴露出问题，到时候排查就很困难了，因为已经不是错误的第一现场。
所以错误和异常最好能按一定的规则进行分类和管理，在第一时间能暴露错误和还原现场。
对于错误处理，Erlang有一个很好的概念叫速错，就是有错误第一时间暴露它。我们的项目从Erlang到Go一直是沿用这一设计原则。但是应用这个原则的前提是先得区分错误和异常这两个概念。
错误和异常上面已经提到了，从语言机制层面比较容易区分它们，但是语言取决于人为，什么情况下用错误表达，什么情况下用异常表达，就得有一套规则，否则很容易出现全部靠异常来做错误处理的情况，似乎Java项目特别容易出现这样的设计。
这里我先假想有这样一个业务：游戏玩家通过购买按钮，用铜钱购买宝石。
在实现这个业务的时候，程序逻辑会进一步分化成客户端逻辑和服务端逻辑，客户端逻辑又进一步因为设计方式的不同分化成两种结构：胖客户端结构、瘦客户端结构。
胖客户端结构，有更多的本地数据和懂得更多的业务逻辑，所以在胖客户端结构的应用中，以上的业务会实现成这样：客户端检查缓存中的铜钱数量，铜钱数量足够的时候购买按钮为可用的亮起状态，用户点击购买按钮后客户端发送购买请求到服务端；服务端收到请求后校验用户的铜钱数量，如果铜钱数量不足就抛出异常，终止请求过程并断开客户端的连接，如果铜钱数量足够就进一步完成宝石购买过程，这里不继续描述正常过程。
因为正常的客户端是有一步数据校验的过程的，所以当服务端收到不合理的请求（铜钱不足以购买宝石）时，抛出异常比返回错误更为合理，因为这个请求只可能来自两种客户端：外挂或者有BUG的客户端。如果不通过抛出异常来终止业务过程和断开客户端连接，那么程序的错误就很难被第一时间发现，攻击行为也很难被发现。
我们再回头看瘦客户端结构的设计，瘦客户端不会存有太多状态数据和用户数据也不清楚业务逻辑，所以客户端的设计会是这样：用户点击购买按钮，客户端发送购买请求；服务端收到请求后检查铜钱数量，数量不足就返回数量不足的错误码，数量足够就继续完成业务并返回成功信息；客户端收到服务端的处理结果后，在界面上做出反映。
在这种结构下，铜钱不足就变成了业务逻辑范围内的一种失败情况，但不能提升为异常，否则铜钱不足的用户一点购买按钮都会出错掉线。
所以，异常和错误在不同程序结构下是互相转换的，我们没办法一句话的给所有类型所有结构的程序一个统一的异常和错误分类规则。
但是，异常和错误的分类是有迹可循的。比如上面提到的痩客户端结构，铜钱不足是业务逻辑范围内的一种失败情况，它属于业务错误，再比如程序逻辑上尝试请求某个URL，最多三次，重试三次的过程中请求失败是错误，重试到第三次，失败就被提升为异常了。
所以我们可以这样来归类异常和错误：不会终止程序逻辑运行的归类为错误，会终止程序逻辑运行的归类为异常。
因为错误不会终止逻辑运行，所以错误是逻辑的一部分，比如上面提到的瘦客户端结构，铜钱不足的错误就是业务逻辑处理过程中需要考虑和处理的一个逻辑分支。而异常就是那些不应该出现在业务逻辑中的东西，比如上面提到的胖客户端结构，铜钱不足已经不是业务逻辑需要考虑的一部分了，所以它应该是一个异常。
错误和异常的分类需要通过一定的思维训练来强化分类能力，就类似于面向对象的设计方式一样的，技术实现就摆在那边，但是要用好需要不断的思维训练不断的归类和总结，以上提到的归类方式希望可以作为一个参考，期待大家能发现更多更有效的归类方式。
接下来我们讲一下速错和Go语言里面怎么做到速错。
速错我最早接触是在做的时候就体验到的，当然跟Erlang的速错不完全一致，那时候也没有那么高大上的一个名字，但是对待异常的理念是一样的。
在.NET项目开发的时候，有经验的程序员都应该知道，不能随便re-throw，就是catch错误再抛出，原因是异常的第一现场会被破坏，堆栈跟踪信息会丢失，因为外部最后拿到异常的堆栈跟踪信息，是最后那次throw的异常的堆栈跟踪信息；其次，不能随便try catch，随便catch很容易导出异常暴露不出来，升级为更严重的业务漏洞。
到了Erlang时期，大家学到了速错概念，简单来讲就是：让它挂。只有挂了你才会第一时间知道错误，但是Erlang的挂，只是Erlang进程的异常退出，不会导致整个Erlang节点退出，所以它挂的影响层面比较低。
在Go语言项目中，虽然有类似Erlang进程的Goroutine，但是Goroutine如果panic了，并且没有recover，那么整个Go进程就会异常退出。所以我们在Go语言项目中要应用速错的设计理念，就要对Goroutine做一定的管理。
在我们的游戏服务端项目中，我把Goroutine按挂掉后的结果分为两类：1、挂掉后不影响其他业务或功能的；2、挂掉后业务就无法正常进行的。
第一类Goroutine典型的有：处理各个玩家请求的Goroutine，因为每个玩家连接各自有一个Goroutine，所以挂掉了只会影响单个玩家，不会影响整体业务进行。
第二类Goroutine典型的有：数据库同步用的Goroutine，如果它挂了，数据就无法同步到数据库，游戏如果继续运行下去只会导致数据回档，还不如让整个游戏都异常退出。
这样一分类，就可以比较清楚哪些Goroutine该做recover处理，哪些不该做recover处理了。
那么在做recover处理时，要怎样才能尽量保留第一现场来帮组开发者排查问题原因呢？我们项目中通常是会在最外层的recover中把错误和堆栈跟踪信息记进日志，同时把关键的业务信息，比如：用户ID、来源IP、请求数据等也一起记录进去。
为此，我们还特地设计了一个库，用来格式化输出堆栈跟踪信息和对象信息，项目地址：funny/debug · GitHub
通篇写下来发现比我预期的长很多，所以这里我做一下归纳总结，帮组大家理解这篇文章所要表达的：
错误和异常需要分类和管理，不能一概而论
错误和异常的分类可以以是否终止业务过程作为标准
错误是业务过程的一部分，异常不是
不要随便捕获异常，更不要随便捕获再重新抛出异常
Go语言项目需要把Goroutine分为两类，区别处理异常
在捕获到异常时，需要尽可能的保留第一现场的关键数据
以上仅为一家之言，抛砖引玉，希望对大家有所帮助。
