go经典语言错误 go语言异常处理

go语言语法(基础语法篇)

import "workname/packetfolder"

广平网站建设公司成都创新互联,广平网站设计制作，有大型网站制作公司丰富经验。已为广平成百上千提供企业网站建设服务。企业网站搭建\外贸营销网站建设要多少钱，请找那个售后服务好的广平做网站的公司定做！

导入多个包

方法调用 包名.函数//不是函数或结构体所处文件或文件夹名

packagename.Func()

前面加个点表示省略调用，那么调用该模块里面的函数，可以不用写模块名称了:

当导入一个包时，该包下的文件里所有init()函数都会被执行，然而，有些时候我们并不需要把整个包都导入进来，仅仅是是希望它执行init()函数而已。下划线的作用仅仅是为了调用init()函数，所以无法通过包名来调用包中的其他函数

import _ package

变量声明必须要使用否则会报错。

全局变量运行声明但不使用。

func 函数名 (参数1，参数2，...) (返回值a 类型a, 返回值b 类型b，...)

func 函数名 (参数1，参数2，...) (返回值类型1, 返回值类型2，...)

func (this *结构体名) 函数名(参数 string) (返回值类型1, 返回值类型2){}

使用大小来区分函数可见性

大写是public类型

小写是private类型

func prifunc int{}

func pubfunc int{}

声明静态变量

const value int

定义变量

var value int

声明一般类型、接口和结构体

声明函数

func function () int{}

go里面所有的空值对应如下

通道类型

内建函数 new 用来分配内存，它的第一个参数是一个类型，不是一个值，它的返回值是一个指向新分配类型零值的指针

func new(Type) *Type

[这位博主有非常详细的分析]

Go 语言支持并发，我们只需要通过 go 关键字来开启 goroutine 即可。

goroutine 是轻量级线程，goroutine 的调度是由 Golang 运行时进行管理的。

同一个程序中的所有 goroutine 共享同一个地址空间。

语法格式如下:

通道（channel）是用来传递数据的一个数据结构。

通道的声明

通道可用于两个 goroutine 之间通过传递一个指定类型的值来同步运行和通讯。操作符 - 用于指定通道的方向，发送或接收。如果未指定方向，则为双向通道。

[这里有比较详细的用例]

go里面的空接口可以指代任何类型(无论是变量还是函数)

声明空接口

go里面的的强制类型转换语法为:

int(data)

如果是接口类型的强制转成其他类型的语法为:

go里面的强制转换是将值复制过去,所以在数据量的时候有比较高的运行代价

深入剖析：一套在 Go 中传递、返回、暴露错误，便于回查的解决方案

作者：andruzhang，腾讯 IEG 后台开发工程师

在后台开发中，针对错误处理，有三个维度的问题需要解决：

一个面向过程的函数，在不同的处理过程中需要 handle 不同的错误信息；一个面向对象的函数，针对一个操作所返回的不同类型的错误，有可能需要进行不同的处理。此外，在遇到错误时，也可以使用断言的方式，快速中止函数流程，大大提高代码的可读性。

在许多高级语言中都提供了 try ... catch 的语法，函数内部可以通过这种方案，实现一个统一的错误处理逻辑。而即便是 C 这种 “中级语言” 虽然没有，但是程序员也可以使用宏定义的方式，来实现某种程度上的错误断言。

但是，对于 Go 的情况就比较尴尬了。

我们先来看断言，我们的目的是，仅使用一行代码就能够检查错误并终止当前函数。由于没有 throw，没有宏，如果要实现一行断言，有两种方法。

第一种是把 if 的错误判断写在一行内，比如：

第二种方法是借用 panic 函数，结合 recover 来实现:

这两种方法都值得商榷。

首先，将 if 写在同一行内的问题有：

至于第二种方法，我们要分情况看；

不过使用 panic 来断言的方案，虽然在业务逻辑中基本上不用，但在测试场景下则是非常常见的。测试嘛，用牛刀有何不可？稍微大一点的系统开销也没啥问题。对于 Go 来说，非常热门的单元测试框架 goconvey 就是使用 panic 机制来实现单元测试中的断言，用的人都说好。

综上，在 Go 中，对于业务代码，笔者不建议采用断言，遇到错误的时候建议还是老老实实采用这种格式：

而在单测代码中，则完全可以大大方方地采用类似于 goconvey 之类基于 panic 机制的断言。

众所周知 Go 是没有 try ... catch 的，而且从官方的态度来看，短时间内也没有考虑的计划。但程序员有这个需求呀。笔者采用的方法，是将需要返回的 err 变量在函数内部全局化，然后结合 defer 统一处理：

这种方案要特别注意变量作用域问题.比如前面的 if err = DoSomething(); err != nil { 行，如果我们将 err = ... 改为 err := ...，那么这一行中的 err 变量和函数最前面定义的 (err error) 不是同一个变量，因此即便在此处发生了错误，但是在 defer 函数中无法捕获到 err 变量了。

在 try ... catch 方面，笔者其实没有特别好的方法来模拟，即便是上面的方法也有一个很让人头疼的问题：defer 写法导致错误处理前置，而正常逻辑后置了，从可读性的角度来说非常不友好。因此也希望读者能够指教。同时还是希望 Go 官方能够继续迭代，支持这种语法。

这一点在 Go 里面，一开始看起来还是比较统一的，这就是 Go 最开始就定义的 error 类型，以系统标准的方式，统一了进程内函数级的错误返回模式。调用方使用 if err != nil 的统一模式，来判断一个调用是不是成功了。

但是随着 Go 的逐步推广，由于 error 接口的高自由度，程序员们对于 “如何判断该错误是什么错误” 的时候，出现了分歧。

在 Go 1.13 之前，对于 error 类型的传递，有三种常见的模式：

这个流派很简单，就是将各种错误信息直接定义为一个类枚举值的模式，比如：

当遇到相应的错误信息时，直接返回对应的 error 类枚举值就行了。对于调用方也非常方便，可以采用 switch - case 来判断错误类型：

个人觉得这种设计模式本质上还是 C error code 模式。

这种流派则是充分使用了 “error 是一个 interface” 的特性，重新自定义一个 error 类型。一方面是用不同的类型来表示不同的错误分类，另一方面则能够实现对于同一错误类型，能够给调用方提供更佳详尽的信息。举个例子，我们可以定义多个不同的错误类型如下：

对于调用方，则通过以下代码来判断不同的错误：

这种模式，一方面可以透传底层错误，另一方面又可以添加自定义的信息。但对于调用方而言，灾难在于如果要判断某一个错误的具体类型，只能用 strings.Contains() 来实现，而错误的具体描述文字是不可靠的，同一类型的信息可能会有不同的表达；而在 fmt.Errorf 的过程中，各个业务添加的额外信息也可能会有不同的文字，这带来了极大的不可靠性，提高了模块之间的耦合度。

在 go 1.13 版本发布之后，针对 fmt.Errorf 增加了 wraping 功能，并在 errors 包中添加了 Is() 和 As() 函数。关于这个模式的原理和使用已经有很多文章了，本文就不再赘述。

这个功能，合并并改造了前文的所谓 “== 流派” 和 “fmt.Errorf” 流派，统一使用 errors.Is() 函数；此外，也算是官方对类型断言流派的认可（专门用 As() 函数来支持）。

在实际应用中，函数/模块透传错误时，应该采用 Go 的 error wrapping 模式，也就是 fmt.Errorf() 配合 %w 使用，业务方可以放心地添加自己的错误信息，只要调用方统一采用 errors.Is() 和 errors.As() 即可。

服务/系统层面的错误信息返回，大部分协议都可以看成是 code - message 模式或者是其变体：

这种模式的特点是：code 是给程序代码使用的，代码判断这是一个什么类型的错误，进入相应的分支处理；而 message 是给人看的，程序可以以某种形式抛出或者记录这个错误信息，供用户查看。

在这一层面有什么问题呢？code for computer，message for user，好像挺好的。

但有时候，我们可能会收到用户/客户反馈一个问题：“XXX 报错了，帮忙看看什么问题？”。用户看不懂我们的错误提示吗？

在笔者的经验中，我们在使用 code - message 机制的时候，特别是业务初期，难以避免的是前后端的设计文案没能完整地覆盖所有的错误用例，或者是错误极其罕见。因此当出现错误时，提示暧昧不清（甚至是直接提示错误信息），导致用户从错误信息中找到解决方案

在这种情况下，尽量覆盖所有错误路径肯定是最完美的方法。不过在做到这一点之前，码农们往往有下面的解决方案：

既要隐藏信息，又要暴露信息，我可以摔盘子吗……

这里，笔者从日益普及的短信验证码有了个灵感——人的短期记忆对 4 个字符还是比较强的，因此我们可以考虑把错误代码缩短到 4 个字符——不区分大小写，因为如果人在记忆时还要记录大小写的话，难度会增加不少。

怎么用 4 个字符表示尽量多的数据呢？数字+字母总共有 36 个字符，理论上使用 4 位 36 进制可以表示 36x36x36x36 = 1679616 个值。因此我们只要找到一个针对错误信息字符串的哈希算法，把输出值限制在 1679616 范围内就行了。

这里我采用的是 MD5 作为例子。MD5 的输出是 128 位，理论上我可以取 MD5 的输出，模 1679616 就可以得到一个简易的结果。实际上为了减少除法运算，我采用的是取高 20 位（0xFFFFF）的简易方式（20 位二进制的最大值为 1048575），然后将这个数字转成 36 进制的字符串输出。

当出现异常错误时，我们可以将 message 的提示信息如下展示：“未知错误，错误代码 30EV，如需协助，请联系 XXX”。顺带一提，30EV 是 "Access denied for user 'db_user'@'127.0.0.1'" 的计算结果，这样一来，我就对调用方隐藏了敏感信息。

至于后台侧，还是需要实实在在地将这个哈希值和具体的错误信息记录在日志或者其他支持搜索的渠道里。当用户提供该代码时，可以快速定位。

这种方案的优点很明显：

简易的错误码生成代码如下：

当然这种方案也有局限性，笔者能想到的是需要注意以下两点：

此外，笔者需要再强调的是：在开发中，针对各种不同的、正式的错误用例依然需要完整覆盖，尽可能通过已有的 code - message 机制将足够清晰的信息告知主调方。这种 hashcode 的错误代码生成方法，仅适用于错误用例遗漏、或者是快速迭代过程中，用于发现和调试遗漏的错误用例的临时方案。

go语言 一个主package包引入同级目录下go文件包编译出错！！

go语言 一个主package包引入同级目录下go文件包编译出错是设置错误造成的，解决方法为：

1、先使用import "strings"导入strings库。

2、HasPrefix 判断字符串 s 是否以 prefix 开头。

3、HasSuffix 判断字符串 s 是否以 suffix 结尾。

4、可以看看判断的代码。

5、在cmd下运行一下go run test.go，看看如下结果。

6、Contains 判断字符串 s 是否包含 substr，也就是判断一下S是否在strings中。

7、在cmd下运行go run test.go看看结果。

Go 语言的错误处理机制是一个优秀的设计吗

这个问题说来话长，我先表达一下我的观点，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分为两类，区别处理异常

在捕获到异常时，需要尽可能的保留第一现场的关键数据

以上仅为一家之言，抛砖引玉，希望对大家有所帮助。

go语言unresolved type string

这是引入类型失败的错误提示,

import org.wltea ,说明你引入了某个jar 包或者类,但是没有找到 ,就报错了.IK analyzer 中文分词器 开源的项目 ,有源码的.把这个下载好就可以了。

go语言中数组使用的注意事项和细节

1、数组是多个 相同类型 的数据的组合，一个数组一旦声明/定义了，其 长度是固定的，不能动态变化 。

2、var arr []int    这时arr就是一个slice 切片 。

3、数组中的元素可以是任何数据类型，包括值类型和引用类型，但是 不能混用 。

4、数组创建后，如果没有赋值，有默认值如下：

    数值类型数组：    默认值为 0

    字符串数组：       默认值为 ""

    bool数组：           默认值为 false

5、使用数组的步骤：

    (1)声明数组并开辟空间

    (3)给数组各个元素赋值

    (3)使用数组

6、数组的下标是从0开始的。

7、数组下标必须在指定范围内使用，否则报panic:数组越界，比如var arr [5]int的有效下标为0~4.

8、Go的数组属于 值类型 ，在默认情况下是 值传递 ，因此会进行值拷贝。 数组间不会相互影响。

9、如想在其他函数中去修改原来的数组，可以使用 引用传递 (指针方式)。

10、长度是数组类型的一部分，在传递函数参数时，需要考虑数组的长度，看以下案例：

题1：编译错误，因为不能把[3]int类型传递给[]int类型，前者是数组，后者是切片；

题2：编译错误，因为不能把[3]int类型传递给[4]int类型；

题3：编译正确，因为[3]int类型传给[3]int类型合法。