本文介绍一些Go语言的基础语法。
成都创新互联公司是一家专注于成都网站设计、成都做网站与策划设计,石林网站建设哪家好?成都创新互联公司做网站,专注于网站建设10年,网设计领域的专业建站公司;建站业务涵盖:石林等地区。石林做网站价格咨询:13518219792
先来看一个简单的go语言代码：
go语言的注释方法：
代码执行结果：
下面来进一步介绍go的基础语法。
go语言中格式化输出可以使用 fmt 和 log 这两个标准库，
常用方法：
示例代码：
执行结果：
更多格式化方法可以访问中的fmt包。
log包实现了简单的日志服务，也提供了一些格式化输出的方法。
执行结果：
下面来介绍一下go的数据类型
下表列出了go语言的数据类型：
int、float、bool、string、数组和struct属于值类型，这些类型的变量直接指向存在内存中的值；slice、map、chan、pointer等是引用类型，存储的是一个地址，这个地址存储最终的值。
常量是在程序编译时就确定下来的值，程序运行时无法改变。
执行结果：
执行结果：
Go 语言的运算符主要包括算术运算符、关系运算符、逻辑运算符、位运算符、赋值运算符以及指针相关运算符。
算术运算符：
关系运算符：
逻辑运算符：
位运算符：
赋值运算符：
指针相关运算符：
下面介绍一下go语言中的if语句和switch语句。另外还有一种控制语句叫select语句，通常与通道联用，这里不做介绍。
if语法格式如下：
if ... else ：
else if：
示例代码：
语法格式：
另外，添加 fallthrough 会强制执行后面的 case 语句，不管下一条case语句是否为true。
示例代码：
执行结果：
下面介绍几种循环语句：
执行结果：
执行结果：
也可以通过标记退出循环：
--THE END--
相比较 C 和 Java 等其它语言而言，Go 语言中的 switch 结构使用上更加灵活。它接受任意形式的表达式，例如：
switch var1 {
case val1:
...
case val2:
...
default:
...
}
变量 var1 可以是任何类型，而 val1 和 val2 则可以是同类型的任意值。类型不被局限于常量或整数，但必须是相同的类型；或者最终结果为相同类型的表达式。前花括号{必须和 switch 关键字在同一行。 您可以同时测试多个可能符合条件的值，使用逗号分割它们，例如：case val1, val2, val3。每一个 case 分支都是唯一的，从上至下逐一测试，直到匹配为止。一旦成功地匹配到每个分支，在执行完相应代码后就会退出整个 switch 代码块，也就是说你不需要特别使用 break 语句来表示结束。
Go语言里面switch默认相当于每个case最后带有break，匹配成功后不会自动向下执行其他case，而是跳出整个switch。
为应用程序池 'DefaultAppPool' 提供服务的进程意外终止。进程 ID 是 '3056'。进程退出代码是 '0xffffffff'。
有关更多信息，请参阅在 的帮助和支持中心。
-----------------------------------
解决方法，给NETWORK SERVICE 加上访问iis服务的权限，具体方法如下：
-----------------------------------
点击“开始”-“控制面板”-“管理工具”-“组件服务”-“计算机”-“我的电脑”-“DCOM”选项，
选择其下的“IIS ADMIN SERVICE”，右健选择“属性”，找到“安全”，在“启动和激活权限”中编辑“自定义”，添加帐号“NETWORK SERVICE ”，
给该帐号赋予“本地启动”和“本地激活”的权限，重新启动IIS（点“开始”-“运行”-“CMD”，点确定，然后运行IISRESET），
之后再访问同一站点，则一切正常。
另一解决方案：
事件类型: 警告
事件来源: W3SVC
事件种类: 无
事件 ID: 1009
日期: 2007-8-XX
事件: XX:XX:XX
用户: XX
计算机: XXXX
描述:
为应用程序池 'XXXXX' 提供服务的进程意外终止。进程 ID 是 'XXXX'。进程退出代码是 '0x80'。
有关更多信息，请参阅在 的帮助和支持中心。
原因：
CAUSE
Together with each worker process that IIS creates under a separate identity, the system creates a new desktop object by allocating memory from the configured desktop heap. This issue occurs because, when that heap has been exhausted, IIS cannot create more worker processes. Clients then receive the "service unavailable" error message in their Web browsers when they try to visit Web sites that those application pools host.
独立进程的 内存堆戋消耗完了，IIS不能创建更多的进程工作空间来处理
解决方法：
警告：需要修改服务器的注册表，请修改前备份相关键值
add the UseSharedWPDesktop registry key to your computer that is running IIS. This registry key permits all worker processes to run in one shared desktop, regardless of their worker process identities.
To add the UseSharedWPDesktop registry key:
1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC
2. 在Parameters键下新建一个DWORD项，名字为：UseSharedWPDesktop 值为1 重启IIS
MS关于此键值描述：
UseSharedWPDesktop
注册表路径：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters
数据类型：REG_DWORD
默认值： 0
范围： 0 - 1
如果您正使用唯一标识设置应用程序池，那么根据服务器上的应用程序和内存资源，将会达到大约 60 个应用程序池的上限。某些分配了单个新登录会话的系统资源存在一定的限制。这表明可以有 60 个进程以不同的帐户同时运行。IIS 6.0 支持在单个共享的工作站和桌面中运行这些进程，所需的成本为在所有各方之间共享单个用户会话的单个封装。要扩展到 60 个应用程序池以上并共享单个桌面，可将 UseSharedWPDesktop 更改为 DWORD 值 1。更改此注册表项之后，应当可以扩展到上百个应用程序池已及上百个同时运行的工作进程。
以上为转载，是否恢复正常还需验证！
续：经过上面两个方法后，系统日志还是出错，都是说应用池程序相关的进程(与world wide web通信)致命错误 ，突然在网上看到一句话，说要给system32的user权限(猜想可能要给system32\temp的权限,因为是discuz的NT版)，给了之后，网站可以了,不过错误还是会出现,最终按上述的第一个办法去解决,发现里面的netman的network service权限不见,添加之后,经过几小时的观察,错误没有出来了
云和安全管理服务专家新钛云服 张春翻译
这种方法有几个缺点。首先，它可以对程序员隐藏错误处理路径，特别是在捕获异常不是强制性的情况下，例如在 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 格式化日志 - 没有它，云平台可能无法检测到日志级别等某些功能。
如果您在应用程序中使用调试级别日志（默认情况下通常不记录），请确保您的应用程序可以轻松更改日志级别，而无需更改代码。更改日志级别还可以暂时使信息级别甚至警告级别的日志静音，以防它们突然变得过于嘈杂并开始淹没错误。您可以使用在启动时检查以设置日志级别的环境变量来实现这一点。
原文：
1、goroutine：在go语言中，每一个并发的执行单元叫做goroutine，如果一个程序中包含多个goroutine，对两个函数的调用则可能发生在同一时刻
2、main goroutine：当一个程序启动时，其主函数即在一个单独的goroutine中运行，我们叫他为main gorountine
3、go goroutine：新的goroutine会用go语句来创建，go+函数名，go语句会使其语句中的函数在一新创建的goroutine中运行，而go语句本身会迅速地完成
4、goroutine的退出：主函数返回时，所有的goroutine都会被直接打断，程序退出，除了从主函数退出或者终止程序之外，没有其他方法能够让一个goroutine来打断另一个的执行，但是可以通过另一种方式来实现这个目的，通过goroutine之间的通信来让一个goroutine请求其他的goroutine，并让请求的goroutine自行结束执行
goroutine和channel是Go语言非常棒的特色，它们提供了一种非常轻便易用的并发能力。但是当您的应用进程中有很多goroutine的时候，如何在主流程中等待所有的goroutine 退出呢？
1 通过Channel传递退出信号
Go的一大设计哲学就是：通过Channel共享数据，而不是通过共享内存共享数据。主流程可以通过channel向任何goroutine发送停止信号，就像下面这样：
func run(done chan int) {
for {
select {
case -done:
fmt.Println("exiting...")
done - 1
break
default:
}
time.Sleep(time.Second * 1)
fmt.Println("do something")
}
}
func main() {
c := make(chan int)
go run(c)
fmt.Println("wait")
time.Sleep(time.Second * 5)
c - 1
-c
fmt.Println("main exited")
}
这种方式可以实现优雅地停止goroutine，但是当goroutine特别多的时候，这种方式不管在代码美观上还是管理上都显得笨拙不堪。
2 使用waitgroup
sync包中的Waitgroup结构，是Go语言为我们提供的多个goroutine之间同步的好刀。下面是官方文档对它的描述：
A WaitGroup waits for a collection of goroutines to finish. The main goroutine calls Add to set the number of goroutines to wait for.
Then each of the goroutines runs and calls Done when finished. At the same time, Wait can be used to block until all goroutines have finished.
通常情况下，我们像下面这样使用waitgroup:
创建一个Waitgroup的实例，假设此处我们叫它wg
在每个goroutine启动的时候，调用wg.Add(1)，这个操作可以在goroutine启动之前调用，也可以在goroutine里面调用。当然，也可以在创建n个goroutine前调用wg.Add(n)
当每个goroutine完成任务后，调用wg.Done()
在等待所有goroutine的地方调用wg.Wait()，它在所有执行了wg.Add(1)的goroutine都调用完wg.Done()前阻塞，当所有goroutine都调用完wg.Done()之后它会返回。
那么，如果我们的goroutine是一匹不知疲倦的牛，一直孜孜不倦地工作的话，如何在主流程中告知并等待它退出呢？像下面这样做：
type Service struct {
// Other things
ch chan bool
waitGroup *sync.WaitGroup
}
func NewService() *Service {
s := Service{
// Init Other things
ch: make(chan bool),
waitGroup: sync.WaitGroup{},
}
return s
}
func (s *Service) Stop() {
close(s.ch)
s.waitGroup.Wait()
}
func (s *Service) Serve() {
s.waitGroup.Add(1)
defer s.waitGroup.Done()
for {
select {
case -s.ch:
fmt.Println("stopping...")
return
default:
}
s.waitGroup.Add(1)
go s.anotherServer()
}
}
func (s *Service) anotherServer() {
defer s.waitGroup.Done()
for {
select {
case -s.ch:
fmt.Println("stopping...")
return
default:
}
// Do something
}
}
func main() {
service := NewService()
go service.Serve()
// Handle SIGINT and SIGTERM.
ch := make(chan os.Signal)
signal.Notify(ch, syscall.SIGINT, syscall.SIGTERM)
fmt.Println(-ch)
// Stop the service gracefully.
service.Stop()
}
重庆分公司
重庆分公司
