情谊提醒：此篇文章大概须要浏览 20分钟33秒，不足之处请多指教，感激你的浏览。 订阅本站
此文章首发于 Debug客栈 ｜https://www.debuginn.cn

Go 语言是一种强类型、编译型的语言，在开发过程中，代码标准是尤为重要的，一个小小的失误可能会带来重大的事变，领有一个良好的 Go 语言开发习惯是尤为重要的，恪守开发标准便于保护、便于浏览了解和减少零碎的健壮性。

以下是咱们项目组开发标准加上本人开发遇到的问题及补充，心愿对你有所帮忙：
注：咱们将以下束缚分为三个等级，别离是：【强制】、【举荐】、【参考】。

Go 编码相干

【强制】代码格调标准遵循 go 官网规范：CodeReviewComments，请应用官网golint lint 进行格调动态剖析；

【强制】代码格局标准按照gofmt，请装置相干 IDE 插件，在保留代码或者编译时，主动将源码通过gofmt做格式化解决，保障团队代码格局统一（比方空格，递进等）

【强制】业务解决代码中不能开goroutine，此举会导致goroutine数量不可控，容易引起零碎雪崩，如果须要启用goroutine做异步解决，请在初始化时启用固定数量goroutine，通过channel和业务解决代码交互，初始化goroutine的函数，原则上应该从main函数入口处明确的调用：

func crond() {    defer func() {      if err := recover(); err != nil {        // dump stack & log      }    }()    // do something}func main() {    // init system    go crond()    go crond2()    // handlers }

【强制】异步开启goroutine的中央（如各种cronder)，须要在最顶层减少recover()，捕获panic，防止个别cronder出错导致整体退出：

func globalCrond() {   for _ := ticker.C {      projectCrond()      itemCrond()      userCrond()   }}func projectCrond() {   defer func() {      if err := recover(); err != nil {         // 打日志，并预警      }   }   // do }

【强制】当有并发读写map的操作，必须加上读写锁RWMutex，否则go runtime会因为并发读写报panic，或者应用sync.Map代替；

【强制】对于提供给内部应用的package，返回函数里必须带上err返回，并且保障在err == nil状况下，返回后果不为nil，比方：

resp, err := package1.GetUserInfo(xxxxx)// 在err == nil 状况下，resp不能为nil或者空值

【强制】当操作有多个层级的构造体时，基于防御性编程的准则，须要对每个层级做空指针或者空数据判断，特地是在解决简单的页面构造时，如：

type Section struct {     Item   *SectionItem     Height int64     Width  int64 } type SectionItem struct {     Tag    string     Icon   string     ImageURL string     ImageList []string     Action *SectionAction } type SectionAction struct {     Type  string     Path  string     Extra string }func getSectionActionPath(section *Section) (path string, img string, err error) {   if section.Item == nil || section.Item.Action == nil { // 要做好足够进攻，防止因为空指针导致的panic      err = fmt.Errorf("section item is invalid")      return   }   path = section.Item.Action.Path   img = section.Item.ImageURL   // 对取数组的内容，也肯定加上防御性判断   if len(section.Item.ImageList) > 0 {       img = section.Item.ImageList[0]   }   return}

【举荐】生命期在函数内的资源对象，如果函数逻辑较为简单，倡议应用defer进行回收：

func MakeProject() {   conn := pool.Get()   defer pool.Put(conn)   // 业务逻辑   ...   return}

对于生命期在函数内的对象，定义在函数内，将应用栈空间，缩小gc压力：

func MakeProject() (project *Project){   project := &Project{} // 应用堆空间   var tempProject Project  // 应用栈空间   return}

【强制】不能在循环里加defer，特地是defer执行回收资源操作时。因为defer是函数完结时能力执行，并非循环完结时执行，某些状况下会导致资源（如连贯资源）被大量占用而程序异样：

// 反例：for {   row, err := db.Query("SELECT ...")   if err != nil {      ...   }   defer row.Close() // 这个操作会导致循环里积攒许多长期资源无奈开释   ...}// 正确的解决，能够在循环完结时间接close资源，如果解决逻辑较简单，能够打包成函数：for {   func () {      row, err := db.Query("SELECT ...")      if err != nil {         ...      }      defer row.Close()      ...   }()}

【举荐】对于可预感容量的slice或者map，在make初始化时，指定cap大小，能够大大降低内存损耗，如：

headList := make([]home.Sections, 0, len(srcHomeSection)/2) tailList := make([]home.Sections, 0, len(srcHomeSection)/2)dstHomeSection = make([]*home.Sections, 0, len(srcHomeSection))….if appendToHead {   headList = append(headList, info)} else {   tailList = append(tailList, info)}….dstHomeSection = append(dstHomeSection, headList…)dstHomeSection = append(dstHomeSection, tailList…)

【举荐】逻辑操作中波及到频繁拼接字符串的代码，请应用bytes.Buffer代替。应用string进行拼接会导致每次拼接都新增string对象，减少GC累赘：

// 正例：var buf bytes.Bufferfor _, name := range userList {   buf.WriteString(name)   buf.WriteString(",")}return buf.String()// 反例：var result stringfor _, name := range userList {   result += name + ","}return result

【强制】对于固定的正则表达式，能够在全局变量初始化时实现预编译，能够无效放慢匹配速度，不须要在每次函数申请中预编译：

var wordReg = regexp.MustCompile("[w]+")func matchWord(word string) bool {   return wordReg.MatchString(word)}

【举荐】JSON 解析时，遇到不确定是什么构造的字段，倡议应用json.RawMessage而不要用interface，这样能够依据业务场景，做二次unmarshal而且性能比interface快很多；

【强制】锁应用的粒度须要依据理论状况进行把控，如果变量只读，则无需加锁；读写，则应用读写锁sync.RWMutex；

【强制】应用随机数时(math/rand)，必须要做随机初始化(rand.Seed)，否则产生出的随机数是可预期的，在某些场合下会带来平安问题。个别状况下，应用math/rand能够满足业务需要，如果开发的是平安模块，倡议应用crypto/rand，安全性更好；

【举荐】对性能要求很高的服务，或者对程序响应工夫要求高的服务，应该防止开启大量gouroutine；
阐明：官网尽管号称goroutine是便宜的，能够大量开启goroutine，然而因为goroutine的调度并没有实现优先级管制，使得一些关键性的goroutine（如网络/磁盘IO，管制全局资源的goroutine）没有及时失去调度而拖慢了整体服务的响应工夫，因此在零碎设计时，如果对性能要求很高，应防止开启大量goroutine。

打点标准

【强制】打点应用.来做分隔符，打点名称须要蕴含业务名，模块，函数，函数解决分支等，参考如下：

// 业务名.服务名.模块.性能.办法service.gateway.module.action.func

【强制】打点应用场景是监控零碎的实时状态，不适宜存储任何业务数据；

【强制】在打点个数太多时，展现时速度会变慢。倡议单个服务打点的key不超过10000个，key中单个维度不同值不超过 1000个（千万不要用 user_id 来打点)；

【举荐】如果展现的时候须要拿成千盈百个key的数据通过 Graphite 的聚合函数做聚合，最初失去一个或几个 key。这种状况下能够在打点的时候就把这个要聚合的点聚合好，这样展现的时候只有拿这几个 key，对展现速度是微小的晋升。

日志相干

【强制】日志信息需带上下文，其中logid必须带上，同一个申请打的日志都需带上logid，这样能够依据logid查找该次申请相干的信息；

【强制】对debug/notice/info 级别的日志输入，必须应用条件输入或者应用占位符形式，防止应用字符拼接形式：

log.Debug("get home page failed %s, id %d", err, id)

【强制】如果是解析json出错的日志，须要将报错err及原内容一并输入，以不便核查起因；

【举荐】对debug/notice/info级别的日志，在打印日志时，默认不显示调用地位（如/path/to/code.go:335）
阐明：go获取调用栈信息是比拟耗时的操作(runtime.Caller)，对于性能要求很高的服务，特地是大量调用的中央，应尽量避免开发人员在应用该性能时，需知悉这个调用带来的代价。

Redis 相干

【举荐】对立应用:作为前缀后缀分隔符，这里能够依据 Redis中间件 key proxy 怎么解析剖析 Key 进行自定义，便于根底服务的数据可视化及问题排查；

【强制】防止应用 HMGET/HGETALL/HVALS/HKEYS/SMEMBERS 阻塞命令这类命令在value较大时，对 Redis 的 CPU/带宽耗费较高，容易导致响应过慢引发零碎雪崩；

【强制】不可把 Redis 当成存储，如有统计相干的需要，能够思考异步同步到数据库进行统计，Redis 应该回归缓存的实质；

【举荐】防止应用大 key，按教训超过 10k 的 value，能够压缩(gzip/snappy等算法)后存入内存，能够缩小内存应用，其次升高网络耗费，进步响应速度：

value, err := c.RedisCache.GetGzip(key)….c.RedisCache.SetExGzip(content, 60)

【举荐】Redis 的分布式锁，能够应用:

lock: redis.Do("SET", lockKey, randint, "EX", expire, "NX")unlock: redis.GetAndDel(lockKey, randint) // redis暂不反对，能够用lua脚本

【举荐】尽量避免在逻辑循环代码中调用 Redis，会产生流量放大效应，申请量较大时需采纳其余办法优化（比方动态配置文件）；

【举荐】key 尽量离散读写，通过uid/imei/xid等跟用户/申请相干的后缀摊派到不同分片，防止分片负载不平衡；

【参考】当缓存量大，申请量较高，可能超出 Redis 接受范畴时，可充分利用本地缓存(localcache)+redis缓存的组合计划来缓解压力，削减峰值：

应用这个办法须要具备这几个条件：

  • cache 内容与用户无关，key 状态不多，属于公共信息；
  • 该cache内容时效性较高，然而访问量较大，有峰值流量。
key := "demoid:3344"value := localcacche.Get(key)if value == "" {   value = rediscache.Get(key)   if value != "" {      // 随机缓存 1~5s，各个机器间错开峰值，只有比 redis缓存短即可      localcache.SetEx(key, value, rand.Int63n(5)+1)   }}if value == "" {   ....   // 从其余零碎或者数据库获取数据   appoint.GetValue()   // 同时设置到redis及localcache中   rediscache.SetEx(key, content, 60)   localcache.SetEx(key, content, rand.Int63n(5)+1)}

【参考】对于申请量高，实时性也高的内容，如果纯正应用缓存，当缓存生效霎时，会导致大量申请穿透到后端服务，导致后端服务有雪崩危险：

如何兼顾扛峰值，爱护后端系统，同时也能放弃实时性呢？在这种场景下，能够采纳随机更新法更新数据，办法如下：

  1. 失常申请从缓存中读取，缓存生效则从后端服务获取；
  2. 在申请中依据随机概率1%（或者依据理论业务场景设置比率）会跳过读取缓存操作，间接从后端服务获取数据，并更新缓存。

这种做法能保障最低时效性，并且当访问量越大，更新概率越高，使得内容实时性也越高。

如果联合上一条 localcache+rediscache 做一二级缓存，则能够达到扛峰值同时放弃实时性。

数据库相干

【强制】操作数据库 sql 必须应用 stmt 格局，应用占位符代替参数，禁止拼接 sql；

【强制】SQL语句查问时，不得应用 SELECT （即形如 SELECT FROM tbl WHERE），必须明确的给出要查问的列名，防止表新增字段后报错；

【强制】对于线上业务 SQL，需保障命中索引，索引设计基于业务需要及字段区分度，个别可辨别状态不高的字段（如 status 等只有几个状态），不倡议加到索引中；

【强制】在成熟的语言中，有实体类，数据拜访层(repository / dao)和业务逻辑层(service)；在咱们的标准中存储实体struct搁置于entities包下；

【强制】对于联结索引，需将区分度较大的字段放后面，区分度小放前面，查找时能够缩小被检索数据量；

-- 字段区分度 item_id > project_idalter table xxx add index idx_item_project (item_id, project_id)

【强制】所有数据库表必须有主键 id；

【强制】主键索引名为 pk字段名; 惟一索引名为 uk字段名; 一般索引名则为 idx_字段名；

【强制】避免因字段类型不同造成的隐式转换，导致索引生效，造成全表扫描问题；

【强制】业务上有惟一个性的字段，即便是多字段的组合，也必须建成惟一索引；

【强制】个别事务规范操作流程：

func TestTXExample(t *testing.T) {   // 关上事务   tx, err := db.Beginx()   if err != nil {      log.Fatal("%v", err)      return   }   // defer异样   needRollback := true   defer func() {      if r := recover(); r != nil {  // 解决recover，防止因为panic，资源无奈开释         log.Fatal("%v", r)         needRollback = true      }      if needRollback {         xlog.Cause("test.example.transaction.rollback").Fatal()         tx.Rollback()      }   }()   // 事务的逻辑   err = InsertLog(tx, GenTestData(1)[0])   if err != nil {      log.Fatal("%v", err)      return   }   // 提交事务   err = tx.Commit()   if err != nil {      log.Fatal("%v", err)      return   }   needRollback = false   return}

【强制】执行事务操作时，请确保SELECT ... FOR UPDATE条件命中索引，应用行锁，防止一个事务锁全表的状况;

【强制】禁止超过三个表的join，须要join的字段，数据类型必须统一，多表关联查问时，保障被关联的字段有索引;

【强制】数据库max_open连接数不可设置过高，会导致代理连接数打满导致不可用情况;