整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
介
在 Go 语言中，如果一个函数或者方法需要返回任何错误，通常会使用 error 接口类型作为返回类型。在标准库中，所有返回了错误信息的函数和方法使用的都是这个接口。例如，下面是 http 包中 Get 方法的声明：
清单 1.1
http://golang.org/pkg/net/http/#Client.Get
在 清单 1.1 的代码中，Get 方法的第二个返回参数是一个 error 接口类型的值。要处理函数或者方法返回的错误值，首先需要检查这个值是否为 nil:
清单 1.2
在 清单 1.2 的代码中，调用了 Get 方法，方法的返回值赋给了两个局部变量，然后用变量 err 和 nil 进行了比较，如果这个值不是 nil，则说明发生了错误。
由于我们处理错误值时用的是接口，所以需要定义一个实现了这个接口的具体类型。标准库已经为我们定义了一个叫做 errorString 的结构，并且实现了 error 接口。在这篇文章里，我们会介绍 error 接口和 errorString 结构的实现以及如何使用。
Error 接口和 errorString 结构
Go 语言为我们直接提供了 error 接口的声明：
清单 1.3
http://golang.org/pkg/builtin/#error
在 清单 1.3 的代码中，我们看到了 error 接口只声明了一个叫做 Error 的方法，这个方法返回一个 string。所以，一个类型只要实现了 Error 方法也就实现了 error 接口，就可以作为 error 接口类型的实例来使用。如果你对 Go 语言中的接口还不太熟悉的话，可以参考我的另一篇文章 接口、方法以及嵌入类型
同时，标准库也声明了一个叫做 errorString 的结构，我们可以在 errors 包中找到它的代码：
清单 1.4
在 清单 1.4 的代码中，我们可以看到 errorString 结构只声明了一个 string 类型的字段 s。这个类型连同它唯一的字段都是非公开的，也就是说我们不能直接访问这个类型或者其中的字段。要了解更多 Go 语言中关于 非公开标识符的内容，可以参考这篇文章 Go 语言中的 公开 / 非公开 标识符。
errorString 结构实现了 error 接口
清单 1.5
http://golang.org/src/pkg/errors/errors.go
在 清单 1.5 的代码中，errorString 是以指针接受者的方式来实现 error 接口的。也就是说，只有 errorString 结构的指针才可以作为 error 接口实例来使用。而且由于 errorString 类型和它的字段都是非公开的，所以我们不能进行类型检测或者类型转化。我们唯一可以做的就是调用它的 Error 方法。
在标准库中，errorString 是作为 error 接口实例来使用的最常用的具体错误类型。现在我们已经知道了这些类型的定义，接下来我们就来学习一下标准库提供了哪些方式，通过 errorString 结构来创建 error 接口的实例。
创建 Error 实例
标准库提供了两种创建 errorString 指针实例，并作为 error 接口实例来使用的方法。如果你需要返回的错误信息只是一个简单的字符串，没有特殊的格式要求，那么 errors 包中的 New 函数就是你需要的：
清单 1.6
清单 1.6 的代码中，展示了 errors 包中的 New 函数的典型使用方式。在这个例子中，通过调用 New 函数，我们声明并且初始化了一个 error 接口的实例。下面我们来看一下 New 函数的声明和实现：
清单 1.7
http://golang.org/src/pkg/errors/errors.go
在 清单 1.7 列出的的 New 函数的声明中，我们可以看到函数接收一个 string 类型的参数，返回一个 error 接口的实例。在函数的实现部分，创建了一个 errorString 结构的指针。然后在返回语句中，编译器创建了一个 error 接口实例并且和这个 errorString 结构的指针进行了绑定来满足函数对返回值的要求。这样 errorString 结构的指针就成了返回的 error 接口实例的具体类型了。
如果你需要返回的错误信息需要格式化，可以使用 fmt 包中的 Errorf 函数
清单 1.8
清单 1.8 的代码中，展示了 Errorf 函数的典型用法。如果你对 fmt 包中的其它格式化函数比较熟悉，那么你会发现这个函数的用法和其它格式化函数的用法是一样的。同样的，我们通过调用 Errorf，声明并且初始化了一个 error 接口的实例。
下面我们来看一下 Errorf 函数的声明和实现：
清单 1.9
http://golang.org/src/pkg/fmt/print.go
在 清单 1.9 列出的 Errorf 函数的声明部分，我们看到了 error 接口类型又一次的被用作返回类型。在函数的实现部分，用 errors 包中的 New 函数为格式化后的错误信息创建了一个 error 接口的实例。所以，不管你用 errors 包还是 fmt 包来创建 error 接口实例，底层都是一个 errorString 结构的指针。
我们已经知道了用 errorString 类型指针来创建 error 接口实例的两种不同的方法，接下来，让我们的来看一下标准库是如何对 API 调用返回的不同错误值进行区分提供支持的。
比较错误值
和其它标准库一样，bufio 包使用 errors 包中的 New 函数创建包级别的 error 接口变量：
清单 1.10
http://golang.org/src/pkg/bufio/bufio.go
清单 1.10 的代码中，bufio 包声明并且初始化了 4 个包级别的 error 接口变量。注意每个变量名都是以 Err 开头的，这是 Go 语言中的命名规范。困为这些变量声明为了 error 接口类型，我们就可以用 这些变量来对从 bufio 包中不同 API 的调用返回的错误值进行识别。
清单 1.11
在 清单 1.11 的代码中，通过 ufio.Reader 指针类型的变量 b, 调用了 Peek 方法。Peek 方法可能返回 ErrNegativeCount 或者 ErrBufferFull 这两个错误变量中的一个。由于这些变量是公开的，所以我们就可以通过这些变量来判断具体返回的是哪个错误。这些变量成了包的错误处理 API 的一部分。
假设 bufio 包没有声明这些 error 类型的变量，我们就不得不通过比较错误信息来判断发生的是什么错误：
清单 1.12
清单 1.12 中的代码中有两个问题，一：对 Error() 的调用 ，会创建一个错误信息的拷贝，然后在 switch 语句中使用，二：如果包的作者作者更改了错误信息，这段代码就不能正常工作了。
io 包是另一个为了可能返回的错误声明 error 类型变量的例子：
清单 1.13
http://golang.org/src/pkg/io/io.go
清单 1.13 的代码显示了 io 包声明了 6 个包级别的 error 类型变量。对包中函数的调用如果返回了第三个 error 类型变量 EOF，则说明没有更多的输入了。调用这个包中的函数后，常常需要把返回的错误值与 EOF 变量进行比较。
下面是 io 包中 ReadAtLeast 方法的实现代码。
清单 1.14
http://golang.org/src/pkg/io/io.go
清单 1.14 列出的 ReadAtLeast 的实现代码中，展示了如何使用这些变量。注意 ErrShortBuffer 和 ErrUnexpectedEOF 是如何作为返回值来使用的。也需要注意函数是如何用变量 err 与 EOF 进行比较的。和我们之前自己写的代码中的做法是一样的。
在实现我们自己的函数库的时候，可以考虑这种为包中函数可能返回的错误创建 error 变量的模式。这样可以提供一个处理包中错误的 API ，并且保持错误处理的一致性。
为什么不用命名类型
大家可能会问，为什么 Go 语言不把 errroString 设计为一个命名类型？
让我们看一下用命名类型来实现和用结构类型实现有什么区别。
清单 1.15
http://play.golang.org/p/uZPi4XKMF9
清单 1.15 中的代码展示了如果把 erroString 作为一个命名类型来使用会遇到的问题。程序的第 9 行声明了一个以 string 为基础类型的命名类型 errorString。然后在第 12 行，为这个命名类型实现了 error 接口。为了模仿 errors 包中的 New 方法，在第 17 行为这个命名类型实现了 New 方法。
接着在第 21 和 22 行，声明并初始化了两个 error 类型变量。变量 ErrNamedType 是用 New 函数初始化的，而变量 ErrStructType 是用 errors.New 函数初始化的。最后在主函数里，我们把这两个变量分别同用同样的方法创建的变量进行了比较。
当你运行程序的时候，输出的结果会比较有趣。
第 25 行的条件语句为真，而第 29 行的条件语句为假。使用命名类型时，我们可以用同样的错误信息创建 error 接口实例，并且它们是相等的。这个问题和我们在 清单 1.12 中遇到的问题一样。我们可以用相同的错误信息创建本地的 error 类型变量，并和包中声明的 error 类型变量进行比较。但是如果包的作者更改了错误信息，我们的代码就不能正常工作了。
当 errorString 是一个结构类型时，也可能出现同样的问题。让我们看一下用值接收者的方式来实现 error 接口会发生什么：
清单 1.16
http://play.golang.org/p/EMWPT-tWp4
清单 1.16 的代码中，我们用值接收者的方式为类型 errorString 实现了 error 接口。这次我们遇到了和 清单 1.15 中使用命名类型时同样的问题。当我们比较接口实例时，实际比较的是底层的具体实例（具体的错误信息）。
由于标准库为 errorString 结构实现 error 接口时用的是指针接收者。所以 errors.New 方法必须返回一个指针实例。这个实例就是与 error 接口实例绑定的那个。并且每次都是不一样的。在这些情况中，比较的是指针而不是底层具体的错误信息。
结论
这篇文章中，我们介绍了 error 接口是什么以及它是如何与 errorString 结构协同工作的。在 Go 语言中，通常用 errors.New 和 fmt.Errorf 来创建 error 接口实例，并且强烈推荐使用它们。通常来说一个简单的错误信息加上一些基本的格式化，就是我们处理错误时需要的一切。
我们也学习了标准库为了让我们区分包中函数调用 返回的不同错误类型，而声明一些 error 类型变量的模式。标准库中的许多包都声明并且公开了这些 error 类型的变量，通过这些变量，足够让我们区分包中函数返回的不同错误类型。
可能我们有时候需要创建自定义错误类型。这是我们会在 第二部分 里介绍的内容。目前，用标准库提供的错误处理机制，按例子中的用法使用就可以了。
后续更新 Go 语言中的错误处理 - 第二部分，请关注
via: https://www.ardanlabs.com/blog/2014/10/error-handling-in-go-part-i.html
作者：William Kennedy 译者：jettyhan 校对：polaris1119
本文由 GCTT 原创编译，Go语言中文网 荣誉推出
介
在 第一部分 中，我们学习了 error 接口以及标准库是如何通过 errors 包来创建 error 接口值的。我们也学习了如何使用 error 接口值，通过这些值来判断是否发生了错误。最后，我们学习了一些标准库是如何通过导出 error 接口变量来帮助我们确定发生错误的具体类型。
在 Go 语言中什么时候应该使用自定义错误类型是比较难把握的。大部分情况下，error 包提供的 error 接口值对于报告和处理错误已经足够了。但有时候，调用者可能希望知道错误发生时一些额外的上下文信息。在我看来，这种情况下就应该使用自定义错误类型。
在这篇文章里，我们将要学习自定义错误类型和标准库中两处使用自定义错误类型的实例。每个实例都提供了一个使用自定义错误类型的有趣的视角。之后我们会学习如何通过返回的 error 接口值确定具体的自定义错误类型以及获取存储在其中的指针信息，通过这些额外的信息怎样能帮助我们做出更加合适的错误处理决定。
net 包
net 包中声明了一个叫做 OpError 的自定义错误类型。指向这个结构的指针一般存储在 error 接口值中返回给调用者。net 包内的许多函数和方法都用到了这个错误类型。
清单 1.1
http://golang.org/src/pkg/net/dial.go
清单 1.1 列出的是 net 包中 Listen 函数的实现代码。我们可以看到，在第 4 行和第 13 行， 创建了 OpError 这个错误类型，并在返回语句中以 error 接口的方式返回给了调用者。由于 OpError 指针实现了 error 接口，所以它可以以 error 接口值返回。需要注意的是，在第 9 行和 11 行，对 ListenTCP 和 ListenUnix 函数的调用 ，同样也可以通过 error 接口返回 OpError 的指针。
接下来，我们看一下 OpError 的声明
清单 1.2
http://golang.org/pkg/net/#OpError
清单 1.2 显示的是 OpError 结构的声明。前三个字段提供了错误发生时相关网络操作的上下文信息。第 17 行声明了一个 error 接口类型。这个字段包含了实际发生的错误，通常情况下，这个值的具体类型是一个 errorString 的指针。
另一个需要注意的是自定义错误类型的命名规范，在 Go 语言中自定义错误类型通常以 Error 结尾。以后我们会在其它包中再次看到这样的命名
接下来，我们看一下 OpError 对 error 接口的实现。
清单 1.3
http://golang.org/src/pkg/net/net.go
清单 1.3 中列出的是 error 接口的实现代码，展示了如何用与错误发生时相关的信息构建建一个更加具体的错误信息。把上下文信息与错误绑定在一起可以提供额外的信息来帮助调用者做出更加合理的错误处理选择。
JSON 包
json 包提供了 JSON 格式与 Go 原生格式的相互转化的功能。所有可能产生的错误都是在内部生成的。维护与错误相关的上下文信息对于这个包是比较难的。json 包中有许多自定义错误类型，这些不同的错误类型可以被同一个函数或者方法返回。
让我们看一下其中的一个自定义错误类型
清单 1.4
http://golang.org/src/pkg/encoding/json/decode.go
清单 1.4 列出了 UnmarshalTypeError 结构的声明和对 error 接口的实现。这个自定义类型是用来说明发生了一个从 JSON 值到具体 Go 原生类型的转化错误。这个结构包含 2 个字段，一个是第 4 行声明的 Value，它包含了用于转换的 JSON 数据，另一个是第 5 行声明的 Type，它包含了将要转化为的 Go 类型。第 8 行对 error 接口的实现中，用相关的上下文信息构建了一个合理的错误信息。
在这个例子里，根据错误类型的名称就可以看出发生了什么错误，这个类型叫做 UnmarshalTypeError，这正是这个自定义错误类型发生时的上下文环境。当发生的错误与转化失败有关时，这个结构的指针就存储在 error 接口中返回。
当调用 unmarshal 时传入了一个非法的参数时，一个指向 InvalidUnmarshalError 的指针会存储在 error 接口中返回。
清单 1.5
http://golang.org/src/pkg/encoding/json/decode.go
清单 1.5 列出了 InvalidUnmarshalError 的声明和对 error 接口的实现。同样的，类型名称就明确了错误发生时的上下文信息。内部维护的状态可以用来构建合适的错误信息，从而帮助调用者做出更加合理的错误处理选择。
具体类型识别
在 net 包 Unmarshal 函数的例子中，随 error 接口返回的错误可能是 UnmarshalTypeError, InvalidUnmarshalError 或者 errorString 中的一个。
清单 1.6
http://golang.org/src/pkg/encoding/json/decode.go
清单 1.6 显示了对 Unmarshal 的调用返回的 error 接口中，是如何包含不同的具体错误类型指针的。在第 27 行中，unmarshal 方法返回了 InvalidUnmarshalError 的指针， 第 34 行，decodeState 变量中的 savedError 被返回，这个字段可能指向好几个不同的具体错误类型。
我们已经知道 JSON 包是用自定义错误类型做为错误发生时的上下文信息的，那我们如何识别包含在 error 接口中的具体错误类型，从而做出更加合理的错误处理选择呢？
让我们从一个使 Unmarshal 函数的调用返回一个包含 UnmarshalTypeError: 自定义类型错误的程序开始。
清单 1.7
http://play.golang.org/p/FVFo8mJLBV
清单 1.7 是一个尝试调用 unmarshal 把一段 JSON 文档转化为 Go 类型的例子，第 15 行的 JSON 文档包含一个 name 字段，其中包含一个 bill 的字符串值。由于 user 类型中的 Name 字段在第 9 行被声明为了 integer, 所以对 Unmarshal 的调用返回一个具体的错误类型 UnmarshalTypeError。
现在我们稍微修改一下 表 1.7 中的代码，使 UNmarshal 的调用通过 error 接口返回不同的错误。
清单 1.8
http://play.golang.org/p/n8dQFeHYVp
清单 1.8 中的代码在 表 1.7 的基础上做了一些改动。在第 15 行，我们把传给 Unmarshal 函数的参数换成了 u ，而不是之前它的地址。这个变化会使对 UNmarshal 函数的调用返回一个包含 InvalidUnmarshalError 具体错误的 error 接口值。
然后是在程序的第 17 行到第 24 行，添加了些有趣的代码：
清单 1.9
第 17 行添加了一个 switch 语句来识别存储在 error 接口中的具体错误类型。注意关键字 type 用在接口变量时的语法。同时我们也可以取得存储在具体错类型的的值，并在每个分支语句中使用这些值。
第 18 行和第 20 行的分支语句检测具体的错误类型，然后执行相应的错误处理逻辑。这是识别存储在 error 接口的具体错误类型的典型方式。
结论
返回的 error 接口值应该包含对调用者有影响的，错误发生时作用域内一些具体信息。它必须包含足够的信息以便让调用者做出合理的选择，通常来说一个简单的字符串信息就够了，不过有时需要的会更多。
我们在 net 包中看到了一个使用实例：它声明了一个自定义错误类型，用来封装原始的 errro 类型和一些相关的上下文信息。在 JSON 包中，我们看到了如何用自定义错误类型在提供上下文信息和相关的状态。在这两个例子中，维护错误发生时的相关上下文信息是一个决定性因素
如果 errors 包中中 error 类型可以提供足够的上下文信息，就用它。整个标准库中到处用到了它， 通常这个就是你需要的。如果需要给调用者提供额外的信息来帮助他们做出更别合理的错误物理选择，从标准库代码中找一些线索，然后创建你自己的自定义错误类型。
via: https://www.ardanlabs.com/blog/2014/11/error-handling-in-go-part-ii.html
作者：William Kennedy 译者：jettyhan 校对：polaris1119
本文由 GCTT 原创编译，Go语言中文网 荣誉推出
者 | 沉默王二
责编 | Carol
头图 | CSDN下载自视觉中国
先说一句哈，自从在 B 站开始刷视频后，我就觉得要学的内容实在是太多了。这篇“服务器软件大扫盲”就是我看了羊哥的一期视频后有感而发的，比如说 Web 服务器、HTTP 服务器、应用服务器这三个概念，我是见过很多次，但如果你非要我说出它们之间的区别的话，我只好哑口无言。
还有，我自己用过的 Tomcat、Nginx、Apache、Jetty、Undertow，它们之间有什么优缺点，嗯......继续哑口无言。可能有很多小伙伴和我一样，用过，但具体的差别还真的说不上来，所以我打算借这个机会来和大家一起学习下。
（我就是课代表，我骄傲）
先来说 Web 服务器，它一般指的是网站服务器，可以向浏览器（PC端或者移动端）等 Web 客户端提供服务，供请求数据或者下载数据。服务器使用 HTTP （超文本传输协议）和客户端浏览器进行通信，因此我们也把 Web 服务器称作为 HTTP 服务器。
再来说应用服务器，它是一种软件框架，提供一个应用程序运行的环境。通常用于为应用程序提供安全、数据、事务支持、负载平衡大型分布式系统管理等服务。
在我看来，Web 服务器和应用服务器之间的界限已经非常模糊，后者更高级一点，就好像公司与企业这两个名词之间的差别。
常见的 Web 服务器软件包括 Nginx、Apache、IIS，常见的应用服务器软件包括 WebLogic、JBoss，前者更轻量级，后者更重量级。
接下来，我们就来唠唠常见的一些服务器软件。
就我的程序生涯来看，Tomcat 用的算是最多了，没有之一。如果 Tomcat 安装成功的话，可以在本地的浏览器中访问 http://127.0.0.1:8080 来展示它的默认首页，见下图。
Tomcat 是由 Apache 软件基金会属下 Jakarta 项目开发的 Servlet 容器，实现了对 Servlet 和 JavaServer Page（JSP）的支持，并提供了作为 Web 服务器的一些特有功能。
JSP 是由 Sun Microsystems 公司主导建立的一种动态网页技术标准。JSP 可以响应客户端发送的请求，并根据请求内容动态地生成 HTML、XML 或其他格式文档的 Web 网页，然后返回给请求者。
JSP 以 Java 语言作为脚本语言，为用户的 HTTP 请求提供服务，并能与服务器上的其它 Java 程序共同处理复杂的业务需求。我是一名三线城市的 Java 程序员，免不了要开发一些小型网站，这也就是为什么我用 Tomcat 最多的原因。
Nginx 是一款轻量级的 Web 服务器、也支持反向代理，由于它的内存占用少，启动极快，高并发能力强，所以在互联网项目中广泛应用。
关于 Nginx，比较令人遗憾的一件事是，它的作者伊戈尔·赛索耶夫进了监狱。
Nginx 在官方测试的结果中，能够支持五万个并行连接，国内比较有名的公司，比如说百度、京东、新浪、网易、腾讯、淘宝等都在使用。
不知道你有没有听过虚拟主机的概念，就是在 Web 服务里有一个独立的网站站点，这个站点对应独立的域名（也可能是IP 或端口），具有独立的程序及资源，可以独立地对外提供服务供用户访问。
虚拟主机有三种类型：基于域名的虚拟主机、基于端口的虚拟主机、基于 IP 的虚拟主机。
Nginx 可以使用一个 server{}标签来标识一个虚拟主机，一个 Web 服务里可以有多个虚拟主机标签对，即可以同时支持多个虚拟主机站点。这一点，非常的实用。
最开始的时候，我以为 Apache 就是 Tomcat，傻傻分不清楚。后来知道它们完全不同，logo 就不同（说什么大实话）。
Apache 一般是指 Apache HTTP Server，是 Apache 软件基金会（和 Tomcat 同属一家基金会，因此容易混淆）下的一个网页服务器软件。由于其跨平台和安全性，被广泛使用，是最流行的 Web 服务器软件之一。它快速、可靠并且可通过简单的 API 扩展。
我是在服务器上安装 WordPress 的时候用到了 Apache，当时并不知道有 LAMP 的存在，所以安装的过程中吃了很多苦，关键是最后没有安装成功，大写的尴尬。
最后还是在青铜群里的一个群友的远程帮助下才完成安装的，他是搞 PHP 的。LAMP 就是他告诉我的，安装起来非常的傻瓜式，非常适合我这种对命令行有抗拒心理的程序员。
LAMP 是指一组运行动态网站或者服务器的自由软件名称首字母缩写：
Linux，操作系统（一般服务器软件都安装在 Linux 上，性能极佳）
Apache，网页服务器（就是 Apache HTTP Server）
MariaDB 或 MySQL，数据库管理系统
PHP、Perl 或 Python，脚本语言
这些软件配合起来使用的时候，极具活力，它的变体还有很多，另外一个比较有名的就是 LNMP，用 Nginx 代替 Apache。
Jetty 和 Tomcat 有很多相似之处，比如说可以为 JSP 和 Servlet 提供运行时环境。Jetty 是 Java 语言编写的，它的 API 以一组 JAR 包的形式发布。
与 Tomcat 相比，Jetty 可以同时处理大量链接并且长时间的保持这些链接，例如，一些 Web 聊天应用非常适合用 Jetty 服务器，比如说淘宝的 Web 版旺旺。
Jetty 的架构比较简单，它有一个基本数据模型，这个数据模型就是 Handler，所有可以被扩展的组件都可以作为一个 Handler，添加到 Server 中，Jetty 就是帮我们管理这些 Handler 的。
Undertow 是一个用 Java 编写的、灵活的、高性能的 Web 服务器，提供基于 NIO 的阻塞和非阻塞 API。
Undertow 可以嵌入到应用程序中或独立运行，只需几行代码，非常容易上手。下面这段代码是官网提供的一个使用 Async IO 的简单 Hello World 服务器示例：
public class HelloWorldServer {
public static void main(final String[] args) {
Undertow server=Undertow.builder
.addHttpListener(8080, "localhost")
.setHandler(new HttpHandler {
@Override
public void handleRequest(final HttpServerExchange exchange) throws Exception {
exchange.getResponseHeaders.put(Headers.CONTENT_TYPE, "text/plain");
exchange.getResponseSender.send("Hello World");
}
}).build;
server.start;
}
}
直接运行后，在浏览器中地址栏中输入 http://localhost:8080就可以访问到了。是不是感觉非常轻巧？
如果有小伙伴使用过 JFinal 开发过小型网站的话，对 Undertow 应该不会陌生，因为 JFinal 的默认容器已经切换到了 Undertow。
JFinal 是基于 Java 语言的极速 WEB + ORM 框架，其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展、Restful。
至于其他的一些企业级服务器软件，我个人没有用过，就不细说了。
JBoss，红帽子收购过，后更名为 WildFly。
WebLogic，甲骨文出品。
WebSphere，IBM 公司出品。
相信小伙伴们看了出品方，就知道这些服务器软件足够的重量级，都是大佬，都是大佬。
声明：本文为作者投稿，版权归其个人所有。
?Flash 已死，Deno 当立？
?OceanBase 十年：一群追梦人的成长史
?2 年 6 个月 11 天，外包到阿里的修仙之路！| 原力计划
?服务器软件大扫盲！
?绝悟之后再超神，腾讯30篇论文入选AI顶会ACL
?中本聪并没有出现，那真相是？
*请认真填写需求信息，我们会在24小时内与您取得联系。
