错误风险是代码中可能导致生产错误和中断的问题。错误是代码中的缺陷，它会产生不希望的或不正确的结果。由于糟糕的编码实践、缺乏版本控制、需求传达错误、不切实际的开发时间表以及有缺陷的第三方工具，代码通常存在错误风险。在这篇文章中，让我们来看看 Go 中一些常见的错误风险。
1.无限递归调用
递归调用自身的函数需要有一个退出条件。否则，它将永远递归，直到系统内存耗尽。
此问题可能是由常见错误引起的，例如忘记添加退出条件。它也可能“故意”发生。某些语言具有尾调用优化，这使得某些无限递归调用可以安全使用。尾调用优化允许您避免为函数分配新的堆栈帧，因为调用函数将返回它从被调用函数获取的值。最常见的用途是尾递归，其中为利用尾调用优化而编写的递归函数可以使用常量堆栈空间。然而，Go 并没有实现尾调用优化，你最终会耗尽内存。然而，这个问题不适用于产生新的 goroutine。
2. 分配给nil地图
在添加任何元素之前，需要使用make函数（或map文字）初始化映射。使用内置函数创建一个新的空映射值make，该函数将map类型和可选的容量提示作为参数：
make(map[string]int)
make(map[string]int, 100)初始容量不限制其大小：地图增长以容纳存储在其中的项目数量，nil地图除外。甲nil地图相当于不同之处在于可以添加没有元素的空映射。
不好的模式：
var countedData map[string][]ChartElement好的模式：
countedData := make(map[string][]ChartElement)推荐阅读：Go：赋值到 nil 映射中的条目
3.方法修改接收器
修改非指针接收器值的方法可能会产生不良后果。这是一个错误风险，因为该方法可能会更改方法内部接收器的值，但不会反映在原始值中。要传播更改，接收者必须是一个指针。
例如：
type data struct {
num int
key *string
items map[string]bool
}
func (d data) vmethod() {
d.num = 8
}
func (d data) run() {
d.vmethod()
fmt.Printf("%+v", d) // Output: {num:1 key:0xc0000961e0 items:map[1:true]}
}如果num必须修改：
type data struct {
num int
key *string
items map[string]bool
}
func (d *data) vmethod() {
d.num = 8
}
func (d *data) run() {
d.vmethod()
fmt.Printf("%+v", d) // Output: &{num:8 key:0xc00010a040 items:map[1:true]}
}4. Goroutine 中可能使用了不需要的值
循环中的范围变量在每次迭代中都被重用；因此，在循环中创建的 goroutine 将指向上作用域的范围变量。这样，goroutine 就可以使用带有不需要的值的变量。
在下面的示例中，goroutine 中使用的 index 和 value 的值来自外部范围。因为 goroutine 是异步运行的，所以 index 和 value 的值可能（通常是）与预期值不同。
mySlice := []string{"A", "B", "C"}
for index, value := range mySlice {
go func() {
fmt.Printf("Index: %d\n", index)
fmt.Printf("Value: %s\n", value)
}()
}
为了克服这个问题，必须创建一个本地作用域，如下例所示。
mySlice := []string{"A", "B", "C"}
for index, value := range mySlice {
index := index
value := value
go func() {
fmt.Printf("Index: %d\n", index)
fmt.Printf("Value: %s\n", value)
}()
}处理此问题的另一种方法是将值作为 args 传递给 goroutine。
mySlice := []string{"A", "B", "C"}
for index, value := range mySlice {
go func(index int, value string) {
fmt.Printf("Index: %d\n", index)
fmt.Printf("Value: %s\n", value)
}(index, value)
}5.Close在检查可能的错误之前推迟
对于实现接口的值defer的Close()方法，这是 Go 开发人员的常见模式io.Closer。例如，打开文件时：
f, err := os.Open("/tmp/file.md")
if err != nil {
return err
}
defer f.Close()但是这种模式对于可写文件是有害的，因为推迟函数调用会忽略其返回值，并且该Close()方法可能会返回错误。例如，如果您将数据写入文件，则在您调用Close. 应明确处理此错误。
虽然您可以在不使用的情况下继续，但defer您需要记住每次完成工作时关闭文件。更好的方法是defer使用包装函数，如下例所示。
f, err := os.Open("/tmp/file.md")
if err != nil {
return err
}
defer func() {
closeErr := f.Close()
if closeErr != nil {
if err == nil {
err = closeErr
} else {
log.Println("Error occured while closing the file :", closeErr)
}
}
}()
return err推荐阅读：不要在可写文件上延迟 Close()
在团队中工作时，审查其他人的代码变得很重要。DeepSource是一种自动化代码审查工具，可管理端到端代码扫描过程，并在推送新提交或新拉取请求时自动发出带有修复的拉取请求。
为 Go 设置 DeepSource非常简单。一旦设置完成，将对整个代码库执行初始扫描，找到改进的范围，修复它们，并为这些更改打开 PR。
