Go项目实际开发中的疑惑？

前言

这几年随着Go的发展，Go语言也是越来越火了，随意打开一个招聘软件都能发现有许多Go的招聘岗位。

那么我作为一个Javaer也开始学习Go的相关知识，Go的语法并不难学甚至还比较简单，但Go的思想、项目开发却与大多数的OOP语言有些不同。下面就来我就来描述一下自己在使用Go进行项目实践开发中遇到的疑惑吧，欢迎大伙在评论区交流一下。

这里不讨论Go语言本身设计或者语法这些问题哈，只是单纯的探讨作为Javaer学习Go可能会遇到的一些疑惑和不解。

无尽的：if err!=nil

疑惑

如果说你是个Javaer/Springer你可能会感觉到十分繁琐，在项目中要不断的写if err!=nil，在把他丢出去、或者处理，同时异常处理的代码和业务逻辑的代码混合在一起，降低了可读性。在Java中我们可能习惯统一throw出去，随后全局异常捕获处理，将异常处理和业务逻辑分割开来。

了解

关于几乎每个方法调用总是要判断err的问题，可以说是无解滴，这个Go社区本身是鼓励这么做的，让我们思考应该如何处理这个异常，是抛出还是自身就处理等。诚然我们也可以直接都panic/recover，如果是web业务项目我个人认为是可以这样做的，毕竟业务也都不关心是哪里出现了问题，只需要能够返回错误信息就可以了。

打印error没有堆栈信息

疑惑

当我们打印Go的error信息时，会发现其没有堆栈信息我们无法准确定位到报错位置，因为Go的error只关注于本身的错误信息。

了解

如果我们需要打印堆栈信息就使用errors包，通过里面的方法来实现。

Context传递问题

疑惑

在有些项目中会看见，context参数从头传到尾，几乎每个方法的第一个参数都是context，显得有些繁琐。有时项目的日志中需要打印

traceId，在Go中是否有类似Java中的MDC实现方式？

了解

首先Go官方确实是推荐context作为方法的第一个参数，error作为返回参数的最后一个这样子。在项目中context也就是用来管理go routine的生命周期和传递参数，同时使用context来传递traceId也是目前主流的做法。

日志格式统一问题

疑惑

如果大伙用的框架比较多，会发现不同框架的打印格式真是五花八门，没有类似Java中的SLF4J这样的日志门面模式，有时需要将日志进行统一格式收集就比较没法了。

了解

目前没有啥好的解决方法，Go官方并没有提供统一的log接口格式，不过有些框架有提供自定义的日志格式例如zap系统，不过遇到没有提供自定义格式的框架时，也许就只能二次创作了吧~

关于项目结构

疑惑

当你打算写一个项目的时候，可能会发现并不了解Go的项目结构，感觉把Java那一套用在Go上怪怪的，各种开源项目的结构也并不统一。

了解

Go中并没有结构的大统一，你直接使用MVC结构也不能说是有很大的问题，不过在大多数web的Go项目都类似于下面的结构

/
├── api
├── internal
│ ├── cmd 
│ ├── consts
│ ├── controller
│ ├── dao
│ ├── model
│ └── service
├── manifest 
├── resource
├── utils
├── go.mod
└── main.go

总结

由于Go本身不能说是传统的OOP语言，因此我们在开发的时候可能需要忘记掉Java的开发习惯，Go在很多地方都是可取的且优雅。不过不得不说使用Go来CRUD，心智负担还是有点大的，Go也应该适合在中间件等地方更好的发挥它的魅力~