开始之前，介绍一下​最近很火的开源技术，低代码。

作为一种软件开发技术逐渐进入了人们的视角里，它利用自身独特的优势占领市场一角——让使用者可以通过可视化的方式，以更少的编码，更快速地构建和交付应用软件，极大程度地降低了软件的开发、配置、部署和培训成本。

应用地址： https://www.jnpfsoft.com
开发语言：Java/.net

这是一个基于 Java Boot/.Net Core 构建的简单、跨平台快速开发框架。前后端封装了上千个常用类，方便扩展；采用微服务、前后端分离架构，集成了代码生成器，支持前后端业务代码生成，满足快速开发；框架集成了表单、报表、图表、大屏等各种常用的 Demo 方便直接使用；后端框架支持 Vue2、Vue3，平台即可私有化部署，也支持 K8S 部署。

从其他语言刚转入go语言的时候比较容易出现以下方面的问题：

• 字符串string
• interface断言
• 切片slices
• map
• 控制结构(for、switch)
• defer channel管道
• sync同步机制
• select+timer

1.字符串String（Split分割）

项目可能使用情况： 当使用string的split功能分割空字符串时，再进行数据库模糊查询时候，如下：

踩坑分析： 当对空字符串进行Split，将会返回一个包含一个空字符串的切片数组，数组长度为1，但是查询时由于空字符串会被过滤掉了该条件，会导致查询出来的数据不正确，甚至可能会是全表扫，由于查询所有数据可能会系统崩溃掉。

如何避坑： 使用前可以排除空字符串

2.interface断言

在项目中也会经常使用类型断言，当使用interface()转化成相对应的类型时，如果不恰当使用断言而导致panic，踩坑代码：

踩坑分析： golang中对于类型的断言，一定需要加上第二个参数ok判断，否则类型不一致的话直接panic退出 如何避坑： 增加第二个参数ok来判断

3.切片slice

3.1 容量问题

要注意在make切片的时候的参数设置，参数设置有问题很容易导致取下标值不是自己想象中的值，如下：

踩坑分析： 一般来说，slice的初始化为 make([]T, length, capacity)。 如果省略了capacity，默认capacity等于length。因此上面建了一个[]int类型的切片，长度和容量为3的[0,0,0]切片，因此通过append(s,1)会使slice扩容成6，并添加元素1进去。输出结果为：[0,0,0,1]

如何避坑：1.使用make([]T, length, capacity)补全参数；2.使用make([]T, length)，则使用通过索引方式赋值，例如，s[0]=1

3.2 截取[:n]

在项目中可能会使用到切片截取功能，如下简单的代码，那么会出现什么问题呢？

踩坑分析： 因为切片的截取是引用关系，共有 2 个切片 a 和 b，截取了 a 的一部分赋值给了 b，两者存在着关联。图3-2-1 因此，虽然切片 a 只有底层数组中 0 和 1 两个索引位正在被使用，其余未使用的底层数组空间毫无作用，图3-2-2。但由于正在被引用，他们也不会被 GC，因此造成了内存泄露。

图3-2-1

图3-2-2

如何避坑： 可以通过拷贝的方式，同时将原有的切片或者数组释放。

4.map

4.1nil的map赋值问题

在项目中也经常使用到map，但是对于map的使用也很容易出错，比如，对一个nil的map进行赋值：

踩坑分析： 对未初始化的map变量，添加元素时会空指针panic，抛出错误：

如何避坑：往map添加元素时需要先分配内存。 例如 m := make(map[int]int)

4.2 判断map中的key是否存在

在使用map的key取值时，需要先判断key是否存在，踩坑代码：

如何避坑： 不能通过取出来的值来判断key是否存在map中。需要采用如下的形式：

  if _, ok := m[1]; !ok {
            print("key not exists")
        }
​

4.3map的遍历顺序问题

在使用map for循环时，也会出现一些踩坑问题，比如，判断map两次循环相同顺序的值是否一致。

踩坑分析： map的遍历时，golang会提前取一个随机数，把桶的遍历顺序随机化。因此，在程序中，不能依赖遍历的顺序。 如何避坑： 如果需要确保遍历顺序，一般需要自行维护一个额外的有序的数据结构。比如，使用list+sorts

4.4 map的并发读写

在使用map时需要注意，map写入和读取操作是否存在并发问题，特别是引用第三方库的时候，比较容易出现并发map操作的问题，比如：

踩坑分析： golang中的普通map不是线程安全的，如果并发读写，会导致panic。出现这样的错误：

如何避坑：不要并发读写map，也即不要在多个goroutine中同时对map进行读和写。如果一定要有读和写，可以使用sync.Map，但是sync.Map性能比较低，小心使用。

5.控制结构

5.1for循环取址问题

在项目中经常使用for循环进行遍历，但是很容易在指针类型上使用错误,比如：

踩坑分析： 因为在循环里创建的所有函数变量共享相同的变量，其实就是一个可访问的存储位置，而不是固定的值。 因此在for多次循环中，value的地址只有一个。比如，在上面的循环变量p中，在每次迭代中只给它分配了一个新值，而循环变量的地址在每次迭代中都是相同的，因此将存储相同的指针。因此，上面的遍历中，在循环之后，它将保存在最后一次迭代中分配的值。因此运行以上代码，输出如下，和预期不一样：

如何避坑：

(1).在上面的case中不要使用指针

(2).在本地赋予一个临时指针，使用临时指针进行赋值，就不会被覆盖。

 for _, p := range persons {
               innerP := p
               personMap[p.name] = &innerP
       }

5.2 for必包问题

在项目中也经常使用for循环进行启动协程，在使用协程的时候，需要注意的for循环体中的变量也是一样,比如：

踩坑分析： 这个问题和上面的指针问题类似，因为for遍历非常快，所以当for遍历完毕后，v的值是最后的值。因此，在go闭包函数运行的时候，打印的全部都是最新的值。 如何避坑：

在循环中的闭包，应该使用传参的方式，将变量传入函数中。这个时候会发生一次拷贝，因此，不会被其它的变量所覆盖：

for _, v := range s {
  go func(v string) {
     println(v)
  }(v)
}
​

或者使用临时变量，将循环体中值重新赋值给临时变量中：

for _, v := range s {
    tempV:=v
  go func() {
     println(tempV)
  }()
} 

5.3 switch多个case问题

在项目中也会使用到switch，但是由于go语言跟其他的语言的switch，也很容易误以为多个case放在一起能够接着执行，如下：

package main
 
import "fmt"
 
func main() {
    i := 1
    switch i {
    case 1:
    case 2:
        fmt.Println("ok")
    }
    fmt.Println("end")
}
​

踩坑分析： golang的switch和其它语言差别很大。像Java/c等，上面的情况可能使case 1和case 2都执行到了下面的语句。但是golang会自动为每个case增加break。 因此，上面执行到了case 1之后就退出了。 如何避坑：如果需要上面的case满足预期，可以在case1后面增加fallthrougth语句。 或者直接case1, 2多个条件一起。

package main
 
import "fmt"
 
func main() {
    i := 1
    switch i {
    case 1:
     fallthrougth
    case 2:
        fmt.Println("ok")
     fallthrougth
    }
    fmt.Println("end")
}
​

6.defer问题

6.1 defer在跨协程的问题

在项目中defer经常在使用func方法最前面，进行捕获一些非法异常，但是也很容易忽略了跨协程的问题，比如：

//PublishBusiness 发布 
func PublishBusiness(ctx context.Context, businessId int64) error {
    var e error
      defer func() {
        if e !=nil{
      logger.CtxLogErrorf(ctx, "PublishBusiness err: %v", err)
​
        }
     }()
     //更新
     e = b.doPublishBusiness(c, businessId)
     go func() {
        1/0 //子协程 pianc
      }() 
  return err
}
​

踩坑分析： defer 只会在当前函数返回前执行传入的函数，理解这句话主要在三个方面：当前函数返回前执行传入的函数，即 defer 关键值后面跟的是一个函数，包括普通函数如（fmt.Println）, 也可以是匿名函数 func() 因此，在使用recover时，必须在同一个goroutine中使用才可以捕获panic。上面出现panic是在子goroutine中，因此无法捕获，会导致程序crash中断退出。 如何避坑：一般启动一个goroutine时，必须在该goroutine中处理panic，使用defer捕获一下。

6.2 循环中使用defer

在项目中会使用到for循环打开文件，但是在关闭文件的时候容易出现问题，比如：

package main
 
import (
    "log"
    "os"
)
 
func main() {
    for i := 0; i < 10; i++ {
        f, err := os.Open("/path/file")
        if err != nil {
            log.Fatalln(err)
        }
        defer f.Close()
    }
}
​

踩坑分析： 因为defer是在整个函数运行完毕之后才会执行。因此上面的代码中，会出现内存泄漏问题，因为在循环中，每个defer函数会压入到堆栈中。等到整个main函数执行完毕，才从堆栈中弹出来defer函数进行执行。假如循环比较大，而且里面的执行比较重，那么会严重影响性能。

如何避坑：不要再for循环中使用defer函数。可以通过匿名函数将函数快速结束，从而快速执行defer函数释放资源。例如：

package main
import (
    "log"
    "os"
)
func main() {
    for i := 0; i < 10; i++ {
        func() {
            f, err := os.Open("/path/file")
            if err != nil {
                log.Println(err)
                return
            }
            defer f.Close()
        }()
    }
}
​

7.channel管道问题

7.1 channel管道panic的问题

项目经常使用协程并发，结果收集会集中在channel管道中，但在channe使用也比较容易出问题，比如：

import "time"
 
func main() {
    ch := make(chan int)
    go func() {
        for i := 0; i < 1000; i++ {
            ch <- i
            time.Sleep(1)
        }
    }()
 
    go func() {
        close(ch)
    }()
    time.Sleep(100000)
}

踩坑分析： 在channel错误操作比较容易影响panic，下面几类：a).向已关闭的channel发送数据导致panicb).重复关闭channel会导致panicc).关闭nil channel会导致panic因此在上面的例子就是向已关闭的channel发送数据导致panic，会导致程序不可用 如何避坑： channel关闭要适当，也不要向关闭的channel中进行操作，包括发送信息，再次关闭等

7.2 channel管道死锁的问题

因为在channel存在生产者和消费者，也容易出现问题，比如：

 package main
 
   func main() {
   ch := make(chan int)
   ch <- 1
   <-ch
   }
​

踩坑分析： 造成死锁的原因：循环等待、资源共享、非抢占式， 在并发中出现通道死锁有两种情况：数据要发送，但是没有人接收数据要接收，但是没有人发送 因此上面就是，因为生产者和消费者在同一个goroutine中，因此无法并行执行，导致发送的消息一直无法被消费掉，而在ch<- 1一直阻塞着，出现死锁。 如何避坑： 生产者和消费者不能属于同一个goroutine，且生成者和消费者应该成对出现

8.sync同步机制panic问题

在并发下，sync同步机制也经常使用，也是比较容易出现问题的，比如，sync.Mutex：

package main
 
import "sync"
 
func main() {
    var r sync.Mutex
    r.Lock()
    r.Unlock()
    r.Unlock()
}
​

踩坑分析： 在同步机制上造成panic会有以下情况： a).sync.Mutex 没有加锁就进行解锁而导致panic b).sync.Mutex 重复解锁而导致panic c).sync.WaitGroup 计数为负而导致panic 因此上面就是，sync.Mutex 重复解锁而导致panic 如何避坑： 加锁和解锁配对出现

9 select+timer

项目中在一些情况下需要进行超时控制，使用select+timer去解决超时控制，这边也会有一个坑，比如：

package main
import (
    "fmt"
    "time"
)
 
func main() {
    ch := make(chan string)
    go func() {
        for i := 0; i < 100; i++ {
            ch <- "ok"
        }
    }()
 
    for {
        select {
        case v := <-ch:
            fmt.Println(v)
        case <-time.After(time.Second * 10):
            fmt.Println("timeout")
        }
    }
}
​

踩坑分析： 在for循环每次select的时候，都会实例化一个一个新的定时器。该定时器在10秒后 ，才会被激活，但是激活后已经跟select无引用关系，被gc给清理掉。 换句话说，被遗弃的time.After定时任务还是在时间堆里面，定时任务未到期之前，是不会被gc清理的。因此，会出现内存泄漏的现象。

如何避坑：

a).改为timer的方式：

ticker := time.NewTicker(3 * time.Second)
for {
  <-ticker.C
  fmt.Println("timeout")
}
​

b).使用context.WithTimeout方式：

ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
     defer cancel() 
     select {
  case <-ch:return true
  case <-ctx.Done():return false
}
​

go​编辑程序员