go语言混淆 goto混淆

go和golang是一种语言吗

是的，go语言的全称是：go programming language。go 这个词太通用了，搜索引擎不能很好辨认，所以习惯叫golang.

创新互联从2013年开始，先为向阳等服务建站，向阳等地企业，进行企业商务咨询服务。为向阳企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

Golang 中更好的错误处理：理论和实践技巧

云和安全管理服务专家新钛云服 张春翻译

这种方法有几个缺点。首先，它可以对程序员隐藏错误处理路径，特别是在捕获异常不是强制性的情况下，例如在 Python 中。即使在具有必须处理的 Java 风格的检查异常的语言中，如果在与原始调用不同的级别上处理错误，也并不总是很明显错误是从哪里引发的。

我们都见过长长的代码块包装在一个 try-catch 块中。在这种情况下，catch 块实际上充当 goto 语句，这通常被认为是有害的（奇怪的是，C 中的关键字被认为可以接受的少数用例之一是错误后清理，因为该语言没有 Golang- 样式延迟语句）。

如果你确实从源头捕获异常，你会得到一个不太优雅的 Go 错误模式版本。这可能会解决混淆代码的问题，但会遇到另一个问题：性能。在诸如 Java 之类的语言中，抛出异常可能比函数的常规返回慢数百倍。

Java 中最大的性能成本是由打印异常的堆栈跟踪造成的，这是昂贵的，因为运行的程序必须检查编译它的源代码 。仅仅进入一个 try 块也不是空闲的，因为需要保存 CPU 内存寄存器的先前状态，因为它们可能需要在抛出异常的情况下恢复。

如果您将异常视为通常不会发生的异常情况，那么异常的缺点并不重要。这可能是传统的单体应用程序的情况，其中大部分代码库不必进行网络调用——一个操作格式良好的数据的函数不太可能遇到错误（除了错误的情况）。一旦您在代码中添加 I/O，无错误代码的梦想就会破灭：您可以忽略错误，但不能假装它们不存在！

try {

doSometing()

} catch (IOException e) {

// ignore it

}

与大多数其他编程语言不同，Golang 接受错误是不可避免的。 如果在单体架构时代还不是这样，那么在今天的模块化后端服务中，服务通常和外部 API 调用、数据库读取和写入以及与其他服务通信 。

以上所有方法都可能失败，解析或验证从它们接收到的数据（通常在无模式 JSON 中）也可能失败。Golang 使可以从这些调用返回的错误显式化，与普通返回值的等级相同。从函数调用返回多个值的能力支持这一点，这在大多数语言中通常是不可能的。Golang 的错误处理系统不仅仅是一种语言怪癖，它是一种将错误视为替代返回值的完全不同的方式！

重复 if err != nil

对 Go 错误处理的一个常见批评是被迫重复以下代码块：

res, err := doSomething()

if err != nil {

// Handle error

}

对于新用户来说，这可能会觉得没用而且浪费行数：在其他语言中需要 3 行的函数很可能会增长到 12 行 ：

这么多行代码！这么低效！如果您认为上述内容不优雅或浪费代码，您可能忽略了我们检查代码中的错误的全部原因：我们需要能够以不同的方式处理它们！对 API 或数据库的调用可能会被重试。

有时事件的顺序很重要：调用外部 API 之前发生的错误可能不是什么大问题（因为数据从未通过发送），而 API 调用和写入本地数据库之间的错误可能需要立即注意，因为 这可能意味着系统最终处于不一致的状态。即使我们只想将错误传播给调用者，我们也可能希望用失败的解释来包装它们，或者为每个错误返回一个自定义错误类型。

并非所有错误都是相同的，并且向调用者返回适当的错误是 API 设计的重要部分，无论是对于内部包还是 REST API 。

不必担心在你的代码中重复 if err != nil ——这就是 Go 中的代码应该看起来的样子。

自定义错误类型和错误包装

从导出的方法返回错误时，请考虑指定自定义错误类型，而不是单独使用错误字符串。字符串在意外代码中是可以的，但在导出的函数中，它们成为函数公共 API 的一部分。更改错误字符串将是一项重大更改——如果没有明确的错误类型，需要检查返回错误类型的单元测试将不得不依赖原始字符串值！事实上，基于字符串的错误也使得在私有方法中测试不同的错误案例变得困难，因此您也应该考虑在包中使用它们。回到错误与异常的争论，返回错误也使代码比抛出异常更容易测试，因为错误只是要检查的返回值。不需要测试框架或在测试中捕获异常 。

可以在 database/sql 包中找到简单自定义错误类型的一个很好的示例。它定义了一个导出常量列表，表示包可以返回的错误类型，最著名的是 sql.ErrNoRows。虽然从 API 设计的角度来看，这种特定的错误类型有点问题（您可能会争辩说 API 应该返回一个空结构而不是错误），但任何需要检查空行的应用程序都可以导入该常量并在代码中使用它不必担心错误消息本身会改变和破坏代码。

对于更复杂的错误处理，您可以通过实现返回错误字符串的 Error() 方法来定义自定义错误类型。自定义错误可以包括元数据，例如错误代码或原始请求参数。如果您想表示错误类别，它们很有用。DigitalOcean 的本教程展示了如何使用自定义错误类型来表示可以重试的一类临时错误。

通常，错误会通过将低级错误与更高级别的解释包装起来，从而在程序的调用堆栈中传播。例如，数据库错误可能会以下列格式记录在 API 调用处理程序中：调用 CreateUser 端点时出错：查询数据库时出错：pq：检测到死锁。这很有用，因为它可以帮助我们跟踪错误在系统中传播的过程，向我们展示根本原因（数据库事务引擎中的死锁）以及它对更广泛系统的影响（调用者无法创建新用户）。

自 Go 1.13 以来，此模式具有特殊的语言支持，并带有错误包装。通过在创建字符串错误时使用 %w 动词，可以使用 Unwrap() 方法访问底层错误。除了比较错误相等性的函数 errors.Is() 和 errors.As() 外，程序还可以获取包装错误的原始类型或标识。这在某些情况下可能很有用，尽管我认为在确定如何处理所述错误时最好使用顶级错误的类型。

Panics

不要 panic()！长时间运行的应用程序应该优雅地处理错误而不是panic。即使在无法恢复的情况下（例如在启动时验证配置），最好记录一个错误并优雅地退出。panic比错误消息更难诊断，并且可能会跳过被推迟的重要关闭代码。

Logging

我还想简要介绍一下日志记录，因为它是处理错误的关键部分。通常你能做的最好的事情就是记录收到的错误并继续下一个请求。

除非您正在构建简单的命令行工具或个人项目，否则您的应用程序应该使用结构化的日志库，该库可以为日志添加时间戳，并提供对日志级别的控制。最后一部分特别重要，因为它将允许您突出显示应用程序记录的所有错误和警告。通过帮助将它们与信息级日志分开，这将为您节省无数时间。

微服务架构还应该在日志行中包含服务的名称以及机器实例的名称。默认情况下记录这些时，程序代码不必担心包含它们。您也可以在日志的结构化部分中记录其他字段，例如收到的错误（如果您不想将其嵌入日志消息本身）或有问题的请求或响应。只需确保您的日志没有泄露任何敏感数据，例如密码、API 密钥或用户的个人数据！

对于日志库，我过去使用过 logrus 和 zerolog，但您也可以选择其他结构化日志库。如果您想了解更多信息，互联网上有许多关于如何使用这些的指南。如果您将应用程序部署到云中，您可能需要日志库上的适配器来根据您的云平台的日志 API 格式化日志 - 没有它，云平台可能无法检测到日志级别等某些功能。

如果您在应用程序中使用调试级别日志（默认情况下通常不记录），请确保您的应用程序可以轻松更改日志级别，而无需更改代码。更改日志级别还可以暂时使信息级别甚至警告级别的日志静音，以防它们突然变得过于嘈杂并开始淹没错误。您可以使用在启动时检查以设置日志级别的环境变量来实现这一点。

原文：

为什么 Go 语言把类型放在后面

不是为了与众不同。而是为了更加清晰易懂。

Rob Pike 曾经在 Go 官方博客解释过这个问题（原文地址：），简略翻译如下（水平有限翻译的不对的地方见谅）：

引言

Go语言新人常常会很疑惑为什么这门语言的声明语法（declaration syntax）会和传统的C家族语言不同。在这篇博文里，我们会进行一个比较，并做出解答。

C 的语法

首先，先看看 C 的语法。C 采用了一种聪明而不同寻常的声明语法。声明变量时，只需写出一个带有目标变量名的表达式，然后在表达式里指明该表达式本身的类型即可。比如：

int x;

上面的代码声明了 x 变量，并且其类型为 int——即，表达式 x 为 int 类型。一般而言，为了指明新变量的类型，我们得写出一个表达式，其中含有我们要声明的变量，这个表达式运算的结果值属于某种基本类型，我们把这种基本类型写到表达式的左边。所以，下述声明：

int *p;

int a[3];

指明了 p 是一个int类型的指针，因为 *p 的类型为 int。而 a 是一个 int 数组，因为 a[3] 的类型为 int（别管这里出现的索引值，它只是用于指明数组的长度）。

我们接下来看看函数声明的情况。C 的函数声明中关于参数的类型是写在括号外的，像下面这样：

int main(argc, argv)

int argc;

char *argv[];

{ /* ... */ }

如前所述，我们可以看到 main 之所以是函数，是因为表达式 main(argc, argv) 返回 int。在现代记法中我们是这么写的：

int main(int argc, char *argv[]) { /* ... */ }

尽管看起来有些不同，但是基本的结构是一样的。

总的来看，当类型比较简单时，C的语法显得很聪明。但是遗憾的是一旦类型开始复杂，C的这套语法很快就能让人迷糊了。著名的例子如函数指针，我们得按下面这样来写：

int (*fp)(int a, int b);

在这儿，fp 之所以是一个指针是因为如果你写出 (*fp)(a, b) 这样的表达式将会调用一个函数，其返回 int 类型的值。如果当 fp 的某个参数本身又是一个函数，情况会怎样呢？

int (*fp)(int (*ff)(int x, int y), int b)

这读起来可就点难了。

当然了，我们声明函数时是可以不写明参数的名称的，因此 main 函数可以声明为：

int main(int, char *[])

回想一下，之前 argv 是下面这样的

char *argv[]

你有没有发现你是从声明的「中间」去掉变量名而后构造出其变量类型的？尽管这不是很明显，但你声明某个 char *[] 类型的变量的时候，竟然需要把名字插入到变量类型的中间。

我们再来看看，如果我们不命名 fp 的参数会怎样：

int (*fp)(int (*)(int, int), int)

这东西难懂的地方可不仅仅是要记得参数名原本是放这中间的

int (*)(int, int)

它更让人混淆的地方还在于甚至可能都搞不清这竟然是个函数指针声明。我们接着看看，如果返回值也是个函数指针类型又会怎么样

int (*(*fp)(int (*)(int, int), int))(int, int)

这已经很难看出是关于 fp 的声明了。

你自己还可以构建出比这更复杂的例子，但这已经足以解释 C 的声明语法引入的某些复杂性了。

还有一点需要指出，由于类型语法和声明语法是一样的，要解析中间带有类型的表达式可能会有些难度。这也就是为什么，C 在做类型转换的时候总是要把类型用括号括起来的原因，像这样

(int)M_PI

Go 的语法

非C家族的语言通常在声明时使用一种不同的类型语法。一般是名字先出现，然后常常跟着一个冒号。按照这样来写，我们上面所举的例子就会变成下面这样：

x: int

p: pointer to int

a: array[3] of int

这样的声明即便有些冗长，当至少是清晰的——你只需从左向右读就行。Go 语言所采用的方案就是以此为基础的，但为了追求简洁性，Go 语言丢掉了冒号并去掉了部分关键词，成了下面这样：

x int

p *int

a [3]int

在 [3]int 和表达式中 a 的用法没有直接的对应关系（我们在下一节会回过头来探讨指针的问题）。至此，你获得了代码清晰性方面的提升，但付出的代价是语法上需要区别对待。

下面我们来考虑函数的问题。虽然在 Go 语言里，main 函数实际上没有参数，但是我们先誊抄一下之前的 main 函数的声明：

func main(argc int, argv *[]byte) int

粗略一看和 C 没什么不同，不过自左向右读的话还不错。

main 函数接受一个 int 和一个指针并返回一个 int。

如果此时把参数名去掉，它还是很清楚——因为参数名总在类型的前面，所以不会引起混淆。

func main(int, *[]byte) int

这种自左向右风格的声明的一个价值在于，当类型变得更复杂时，它依然相对简单。下面是一个函数变量的声明（相当于 C 语言里的函数指针）

f func(func(int,int) int, int) int

或者当它返回一个函数时：

f func(func(int,int) int, int) func(int, int) int

上面的声明读起来还是很清晰，自左向右，而且究竟哪一个变量名是当前被声明的也容易看懂——因为变量名永远在首位。

类型语法和表达式语法带来的差别使得在 Go 语言里调用闭包也变得更简单：

sum := func(a, b int) int { return a+b } (3, 4)

指针

指针有些例外。注意在数组 (array )和切片 (slice) 中，Go 的类型语法把方括号放在了类型的左边，但是在表达式语法中却又把方括号放到了右边：

var a []int

x = a[1]

类似的，Go 的指针沿用了 C 的 * 记法，但是我们写的时候也是声明时 * 在变量名右边，但在表达式中却又得把 * 放到左左边：

var p *int

x = *p

不能写成下面这样

var p *int

x = p*

因为后缀的 * 可能会和乘法运算混淆，也许我们可以改用 Pascal 的 ^ 标记，像这样

var p ^int

x = p^

我们也许还真的应该把 * 像上面这样改成 ^ （当然这么一改 xor 运算的符号也得改），因为在类型和表达式中的 * 前缀确实把好些事儿都搞得有点复杂，举个例子来说，虽然我们可以像下面这样写

[]int("hi")

但在转换时，如果类型是以 * 开头的，就得加上括号：

(*int)(nil)

如果有一天我们愿意放弃用 * 作为指针语法的话，那么上面的括号就可以省略了。

可见，Go 的指针语法是和 C 相似的。但这种相似也意味着我们无法彻底避免在文法中有时为了避免类型和表达式的歧义需要补充括号的情况。

总而言之，尽管存在不足，但我们相信 Go 的类型语法要比 C 的容易懂。特别是当类型比较复杂时。

为什么Go语言不支持重载？

上图是Golang官网FAQ的部分截图，看来关于Go不支持重载的这个问题困扰了很多从面向对象语言转到Go的开发者。官方在这里做出了解答。

在上面的回答中有这样一句话：

其意思是： 使用其他语言的经验告诉我们，使用具有相同名称但签名不同的多种方法有时会很有用，但在实践中也可能会造成混淆和脆弱。

接下来又说： 在Go的类型系统中，仅按名称进行匹配并要求类型一致是一个简化的主要决定。

最后一句话： 关于操作员重载，似乎比绝对要求更方便。 同样，没有它，事情会变得更简单。

整个的解答非常漂亮、简洁。我们看完之后就会理解，Go语言的设计者之所以没有在Go中实现方法的重载，并没有复杂的理由，核心原则就是： 让Go保持足够的简单。 这也能看出来Go语言的设计者有着极大的选择和克制。

其实，笔者认为重载在本质上并没有很大的实际意义。只是表现力和表现形式上有一定的差别。明确某个上下文中的函数调用的关键就是函数签名，支持重载的语言中一般是函数名加函数参数构成函数签名。而Go中可以认为函数名就是签名。逻辑上没有太大的区别，就是把工作做在了台前 还是幕后的区别。

当然如果非要较真的话，我们或许可以在Go中声明方法的时候将参数写成 interface{} 或者 ... 切片的方式。在传进来参数的时候做一步校验，判断参数的类型和个数，然后分别处理之。

仁者见仁智者见智，大家有什么不同的理解欢迎一起沟通。