Go日志内聚复用gjson踩坑

今天分享一下最近遇到的坑：

以下代码示例使用GoFrame框架，下文简称为gf框架。

统一日志格式

我有个不好的习惯，不管是之前开发PHP，还是现在开发GO，都习惯在开发过程中使用dump()打印数据进行调试。

本地调试虽然爽了，但是上到测试环境，甚至开发环境查不到日志，无法方便的定位问题可就傻了。

所以，我们需要养成关键步骤打印日志的好习惯，而且要统一日志格式。

打印日志

scm.Log.Info("测试的日志都打印在这里，res：%v", res)

封装打印日志的方法

指定日志打印目录

var Log = g.Log().Path(g.Log().GetPath() + "/scm")

通过gf提供的 g.log，再加上我们自己的封装，就能把日志按功能模块进行区分，方便定位问题。

内聚和复用

gf框架有一个设计：internal，即只允许内部调用的方法。

我觉得作者设计internal，一方面是处于安全考虑，另外一方面是处于高内聚的考虑。

但是，也不要过度内聚，我今天遇到的问题就是如何更好的实现代码复用。

所以在项目中抽取了公共方法目录shared，将原本写在internal中的可以复用的逻辑进行迁移。

gjson

今天发现一个非常好用的工具类：gjson

gjson 可以将json/xml/toml/等文件或者文件内容进行读取，创建对象，通过get方法可以取到对象对应的值

package main
import (
   "fmt"
   "github.com/gogf/gf/encoding/gjson"
)

func main() {
   jsonContent := `{"k5":1}`
   jsonObj, err := gjson.LoadContent(jsonContent)
   if err != nil {
      panic(err)
   }
   fmt.Println(jsonObj.Get("k5"))
}

打印结果

最近又在解决很坑人的问题，一直没能静下心来，总是想着一定是哪些小问题导致的，总想着快速解决问题。但是这种谋求快速解决问题的心理导致一直浮在问题表面，没有从根本上解决问题，反而一直在拖进度，让进度越来越慢。