eleven26

gin 核心详解

Posted on 2022-11-16 Edited on 2022-11-17

gin 作为一个非常流行的 go web 框架，以简洁、高效的优势赢得了很多开发者的青睐，今天我们就来看看它的框架核心的一些设计，看看它是如何做到高效的，以及聊聊它的一些设计理念。当然，如果要从实际开发的角度看，gin 只是能够满足最基本的 web 开发的功能，但是由于其设计简洁，我们可以很方便地在其基础上进行扩展，以实现我们 web 开发中那些很常用的功能，比如 cache、db 等等。

前言

在探讨 gin 的核心功能之前，我们先来看看一个 web 框架的核心是怎样的。

我们先来看看一个 URL 的结构是怎样的：scheme://host.domain:port/path/to/file，scheme 是协议名称，web 开发里面是 http 或者 https，host.domain 是域名，port 是端口，最后的 /path/to/file 是请求的资源路径（文件路径）。

在二三十年前尚未出现动态页面之前，所有的页面都是静态的页面，然后不同的页面放在不同的 html 文件中，再复杂一点，通过不同文件夹来组织这些 html 文件。然后在用户要去访问这些页面的时候，先进入的是 index.html，然后在这个 html 文件里面通过不同的超链接跳转到不同的页面去，在我们点击不同的超链接的时候，一个新的请求到达同一个 http 服务器，然后这个 http 服务器读取文件内容（也就是 /path/to/file 的内容），返回给客户端。

在这一阶段，判断客户端请求内容在哪里是由 http 服务器来处理的，读取请求的数据也是 http 服务器来处理的。

然后经过一段时间发展，开始出现了动态生成网页内容的技术，这个时候，之前代表文件路径的 /path/to/file 现在开始由 web 服务器来动态生成。具体来说就是 http 服务器只是根据域名跟端口来判断这个请求具体是哪个应用的，然后将请求转发给对应的应用服务器，由应用服务器判断这个文件路径是要请求什么资源，然后派发给对应的处理逻辑进行处理，并在处理后将数据返回给 http 服务器，最后 http 服务器将数据返回给客户端。

在这一阶段，web 应用做了之前 http 做的一些工作，如根据用户请求的文件路径进行不同的处理，并返回数据。

具体如下图：

图 2 说明：

1：用户请求 http://example.com/path/to/file
2：http 服务器将请求转发给 web 服务器
3: web 服务器处理完请求，将数据返回给 http 服务器
4：http 服务器将数据返回给客户端。

图 2 的形式在今天依然是主流，http 服务器，现在大多只会处理静态资源，而动态的请求大多通过反向代理将请求转发给 web 服务器进行处理。当然我们也可以选择不使用 nginx 等 http 服务器，直接在应用服务器里面处理静态资源的请求，这个功能 go 官方提供的 net/http 就有提供。

路由

上面提到了，现在的 http 服务器会将动态资源的请求通过反向代理转发给 web 服务器，所以就出现了一个必须要解决的问题，web 服务器拿到了请求的信息，如何知道应该做点什么来响应客户端的请求？

其实说起来很简单，就是通过判断 URL 里面的 /path/to/file，也就是在远古时代表示文件路径的那一段，在 web 服务器中，它现在不再表示一个静态文件，而是表示客户端想要请求数据的一个标识而已，具体代表什么，还是看开发者怎么写。

而判断文件路径表示什么的这一操作，有一个我们惯常的叫法 路由，叫这个名字是因为它的功能跟路由器的功能相似吧，路由器是判断网络包应该发往哪一个 IP，而 web 服务器中的路由就是判断请求应该由哪一个函数来处理。

web 服务器要解决的问题是请求交给哪个函数处理，这个功能有个很常见的叫法："路由"。

gin 应用结构体

在所有的 web 服务器里面，一般都有一个对象表示应用本身，而且往往是一个单例，比如 PHP 框架 Laravel 里面的 app() 返回的 Application，Servlet 里面的 getServletContext，再比如 Spring 里面的 ApplicationContext。

而在 gin 里面，应用实例是 gin.Engine 这个结构体，gin.Engine 里面的属性大多是一些配置项，而其中有一个很关键的属性是 RouterGroup，这个就是 gin 核心的核心，它会处理用户请求，将用户请求派发到具体的方法上处理。

type Engine struct {
	RouterGroup     // 路由配置
	// ... 其他配置
}

而 RouterGroup 实现了 IRoutes 接口：

type IRoutes interface {
	// 中间件使用
	Use(...HandlerFunc) IRoutes

	// 路由定义
	Handle(string, string, ...HandlerFunc) IRoutes
	Any(string, ...HandlerFunc) IRoutes
	GET(string, ...HandlerFunc) IRoutes
	POST(string, ...HandlerFunc) IRoutes
	DELETE(string, ...HandlerFunc) IRoutes
	PATCH(string, ...HandlerFunc) IRoutes
	PUT(string, ...HandlerFunc) IRoutes
	OPTIONS(string, ...HandlerFunc) IRoutes
	HEAD(string, ...HandlerFunc) IRoutes

	// 静态资源请求的路由定义
	StaticFile(string, string) IRoutes
	StaticFileFS(string, string, http.FileSystem) IRoutes
	Static(string, string) IRoutes
	StaticFS(string, http.FileSystem) IRoutes
}

我们可以看到这个接口的定义很简单，就是定义了不同的 HTTP 请求方法跟请求路径和 HandlerFunc（请求处理函数，一个请求可以有多个）的映射关系。我们也发现了其中还有 Use 方法，关于 Use，其实也是 web 服务器必备的功能了，我们可以通过这个方法来定义一些中间件，可以在中间件做鉴权啥的，又或者做一些请求后的处理（中间件分请求处理前调用的中间件和请求处理后调用的中间件）。我们也发现了，这个 IRoutes 里面所有方法都返回了 IRoutes，因为 gin 里面支持路由分组，我们可以根据前缀来划分不同的分组，对应到业务上可能就是不同的功能模块。

在 gin 里面，路由会通过 Engine 实例来声明，因为 Engine 嵌套了 RouterGroup 结构体，路由的功能在 RouterGroup 中实现。

一个例子：

package main

import "github.com/gin-gonic/gin"

func main() {
	// 创建应用实例
	r := gin.Default()
	
	// 路由声明，实际上调用的是嵌套结构体 RouterGroup 的方法
	r.GET("/ping", func(c *gin.Context) {
		c.JSON(200, gin.H{
			"message": "pong",
		})
	})
	
	// 启动 web 服务器
	r.Run() // 监听并在 0.0.0.0:8080 上启动服务
}

在这个例子中，gin.Default() 是 gin 里面创建应用实例的一个方法，另一个方法是 gin.New()，创建了应用实例之后，通过 r.GET 来声明了一个路径为 /ping 的路由，并且这个路由的处理函数里面返回了一个 json 响应。

这个例子很简单，但是一个 web 的核心功能便是如此简单，声明路由（定义接收到不同 uri 请求的时候交给什么方法处理）。

gin 的请求处理流程

上面也说了，路由是 web 服务器的核心功能，当我们抛开所有乱七八糟的功能之后，其实也就只剩下最核心的路由，就如 go 的标准库 net/http，我们要使用 go 启动一个 web 服务器非常简单，几行代码即可：

package main

import "net/http"

var _ http.Handler = &Server{}

// Server http 服务器结构体
type Server struct {
}

// 这个就是处理请求的方法，所有的请求都会由 ServeHTTP 方法处理。
func (s Server) ServeHTTP(writer http.ResponseWriter, request *http.Request) {
	writer.Write([]byte("Hello, world"))
}

func main() {
	// 启动 web 服务
	http.ListenAndServe("127.0.0.1:3000", Server{})
}

在所有的 go web 框架中，请求的处理最终都是由 ServeHTTP 处理，gin 也不例外，让我们抛开 Engine 中一切干扰的因素，只留下最核心的功能：

// gin 实例
type Engine struct {
}

// HTTP 请求的处理方法
func (engine *Engine) ServeHTTP(w http.ResponseWriter, req *http.Request) {
	// 从 Context 池中获取一个 Context 实例
	c := engine.pool.Get().(*Context)
	// writermem 也是 ResponseWriter 实例，只是多了 size(响应大小) 和 status(状态码) 两个字段
	c.writermem.reset(w)
	// 记录请求实例到 Context 实例中
	c.Request = req
	// 因为是池化的 Context，在请求处理的过程 Context 会产生一些状态，
	// reset 会重置这些状态。
	c.reset()

	// 实际处理 HTTP 请求的的代码
	engine.handleHTTPRequest(c)

	// 将 Context 实例放回 Context 池中
	engine.pool.Put(c)
}

我们在这里可以看到，gin 通过 sync.Pool 实现了 Context 的复用，这样一来不用每个请求都创建新的 Context 实例了，一定程度上提高了性能。

所以，gin 的请求处理过程是这样的： HTTP 请求到达 gin 的进程之后，交给了 ServeHTTP 处理，而在 ServeHTTP 中，实际的处理方法是 engine.handleHTTPRequest(c)。在 engine.handleHTTPRequest(c) 方法内部会通过 ResponseWriter 来输出响应给客户端。

handleHTTPRequest 内部实现

下面我们再来深入探索一下 gin 请求处理的核心逻辑：

func (engine *Engine) handleHTTPRequest(c *Context) {
	// HTTP 请求方法
	httpMethod := strings.ToUpper(c.Request.Method)
	// 请求资源路径
	rPath := c.Request.URL.Path
	unescape := false
	if engine.UseRawPath && len(c.Request.URL.RawPath) > 0 {
		rPath = c.Request.URL.RawPath
		unescape = engine.UnescapePathValues
	}

	// 移除路径中多余的斜杠
	if engine.RemoveExtraSlash {
		rPath = cleanPath(rPath)
	}

	// engine.trees 是路由树的根结点
	// trees 是一棵前缀树，根结点是 /，第二级结点是 HTTP 请求方法。
	// 每一个请求会先匹配 HTTP 请求方法，然后再匹配请求路径。
	t := engine.trees
	for i, tl := 0, len(t); i < tl; i++ {
		// 先比对 HTTP 方法，不匹配则跳过
		if t[i].method != httpMethod {
			continue
		}
		root := t[i].root
		// 在路由树中查找路径对应的结点
		value := root.getValue(rPath, c.params, c.skippedNodes, unescape)
		// 获取路由参数
		if value.params != nil {
			c.Params = *value.params
		}
		// 查找到结点，c.Next() 会调用路由定义的方法（但是可能会先调用中间件）
		if value.handlers != nil {
			// handlers 是请求所有需要调用的处理函数
			c.handlers = value.handlers
			// 请求路径
			c.fullPath = value.fullPath
			// 处理请求
			c.Next()
			// 处理完请求，如果请求处理过程没有任何响应，会在这里处理
			c.writermem.WriteHeaderNow()
			return
		}
		// 匹配不到的时候，会尝试移除请求路径中的斜杠
		if httpMethod != http.MethodConnect && rPath != "/" {
			if value.tsr && engine.RedirectTrailingSlash {
				redirectTrailingSlash(c)
				return
			}
			if engine.RedirectFixedPath && redirectFixedPath(c, root, engine.RedirectFixedPath) {
				return
			}
		}
		break
	}

	// 匹配不到路由，会先判断是否是因为 HTTP 请求方法不对，
	// 比如：路由定义了 `GET /`，但实际上请求的时候是 `POST /` 这种。
	// 如果 HTTP 请求方法不对，而且用户配置了处理这种情况，
	// 则会调用 405 的处理逻辑来处理这种错误。
	if engine.HandleMethodNotAllowed {
		for _, tree := range engine.trees {
			// 不判断 HTTP 请求方法，
			// 因为路由树的结构是，根结点下一级结点是不同的 HTTP 请求方法。
			if tree.method == httpMethod {
				continue
			}
			// 判断是否有匹配的路由
			// 有的话，当做 405 错误处理
			if value := tree.root.getValue(rPath, nil, c.skippedNodes, unescape); value.handlers != nil {
				c.handlers = engine.allNoMethod
				serveError(c, http.StatusMethodNotAllowed, default405Body)
				return
			}
		}
	}

	// 匹配不到路由的处理
	c.handlers = engine.allNoRoute
	serveError(c, http.StatusNotFound, default404Body)
}

上面代码写了注释，简单来说处理流程如下： * 前导处理：比如 HTTP 方法统一转换为大写等 * 路由匹配：在 gin 里面，路由的结构是一棵前缀树，当然在这里看不出来。具体实现在 root.getValue 方法中。 * 路由匹配不到，先判断是否是 405，如果也不是 405，那就是 404，不管 404 还是 405，最终都是返回关于请求错误的响应。

在这里，我们可以得知，gin 高效的另一个原因是，它的路由树使用了前缀树，有一些路由匹配实现会使用正则匹配，但是效率肯定不如前缀树高效。

gin 核心其他一些功能

除了上面提到的 Context 和路由，gin 核心也提供了一些其他的功能，比如：

白名单机制：对应属性 trustedProxies
防止 json 劫持的配置：secureJSONPrefix
模板渲染：相关属性有 delims、HTMLRender、FuncMap

总结

贴了很多源码，说了大概如下内容：

web 服务器的核心逻辑就是，接收从客户端或反向代理服务器的请求，然后根据请求路径将其派发给不同的函数进行处理。
gin.Engine 是 gin 框架的应用结构体，其主要包含了路由对象，以及一些应用配置，如白名单、模板配置等。
gin 通过 sync.Pool 来保存请求内创建的 Context 对象，从而实现复用，从而提高性能。
gin 的路由设计成一棵前缀树，这棵树的根节点是 /，根节点下一层的结点是不同的 HTTP 请求方法，如 GET、POST 等，再往下就是路由的路径了。而且路径并不是简单地根据斜杠分割的，而是使用最大公共前缀（LCP）来作为树的结点。因为使用了前缀树，所以 gin 在路由匹配的时候可以获得非常高的性能。

总的来说，gin 是一个简洁的 web 框架，其主要功能就是一个 web 服务器的基本功能，就是简单的请求处理，但是其他很多现实开发中需要的东西它都没有（比如数据库、缓存），当然它的定位应该就是提供 web 框架的基本功能，对于其他的功能，我们可以通过扩展它的方式来实现（当然，也可以直接使用其他 web 框架）。

go 依赖注入设计与实现

Posted on 2022-11-12 Edited on 2022-11-15

在现代的 web 框架里面，基本都有实现了依赖注入的功能，可以让我们很方便地对应用的依赖进行管理，同时免去在各个地方 new 对象的麻烦。比如 Laravel 里面的 Application，又或者 Java 的 Spring 框架也自带依赖注入功能。

今天我们来看看 go 里面实现依赖注入的一种方式，以 inject 库为例子（https://github.com/flamego/flamego/tree/main/inject）。

我们要了解一个软件的设计，先要看它定义了一个什么样的模型，但是在了解模型之前，我们更应该清楚了解，为什么会出现这个模型，也就是我们构建出了这个模型到底是为了解决什么问题。

依赖注入要解决的问题

我们先来看看，在没有依赖注入之前，我们需要的依赖是如何构建出来的，假设有如下 struct 定义：

type A struct {
}

type B struct {
	a A
}

type C struct {
	b B
}

func test(c C) {
    println("c called")
}

假设我们要调用 test，就需要创建一个 C 的实例，而创建 C 的实例需要创建一个 B 的实例，而创建 B 的实例需要一个 A 的实例。如下是一个例子：

a := A{}
b := B{a: a}
c := C{b: b}
test(c)

我们可以看到，这个过程非常的繁琐，只有一个地方需要这样调用 test 还好，如果有多个地方都需要调用 test，那我们就要做很多创建实例的操作，而且一旦实例的构建过程发生变化，我们就需要改动很多地方。

所以现在的 web 框架里面一般都将这个实例化的过程固化下来，在框架的某个地方注册一些实例化的函数，在我们需要的时候就调用之前注册的实例化的函数，实例化之后，再根据需要看看是否需要将这个实例保留在内存里面，从而在免去了手动实例化的过程之外，节省我们资源的开销（不用每次使用的时候都实例化一次）。

而这里说到的固化的实例化过程，其实就是我们本文所说的依赖注入。在 Laravel 里面我们可以通过 ServiceProvider 的 app()->register() 或者 app()->bind() 等函数来做依赖注入的一些操作。

inject 依赖注入模型/设计

以下是 Injector 的大概模型，Injector 接口里面嵌套了 Applicator、Invoker、TypeMapper 接口，之所以这样做是出于接口隔离原则考虑，因为这三者代表了细化的三种不同功能，分离出不同的接口可以让我们的代码更加的清晰，也会更利于代码的后续演进。

Injector：依赖注入容器
Applicator：结构体注入的接口
Invoker：使用注入的依赖来调用函数
TypeMapper：类型映射，需要特别注意的是，在 Injector 里面，是通过类型来绑定依赖（不同于 Laravel 的依赖注入容器可以通过字符串命名的方式来绑定依赖，当然将 Injector 稍微改改也是可以实现的，就看有没有这种需求罢了）。

// 依赖注入容器
type Injector interface {
	Applicator
	Invoker
	TypeMapper
    // 上一级 Injector
	SetParent(Injector)
}

// 给结构体字段注入依赖
type Applicator interface {
	Apply(interface{}) error
}

// 调用函数，Invoke 的参数是被调用的函数，
// 这个函数的参数事先通过 Injector 注入，
// 调用的时候从 Injector 里面获取依赖
type Invoker interface {
	Invoke(interface{}) ([]reflect.Value, error)
}

// 往 Injector 注入依赖
type TypeMapper interface {
	Map(...interface{}) TypeMapper
	MapTo(interface{}, interface{}) TypeMapper
	Set(reflect.Type, reflect.Value) TypeMapper
	Value(reflect.Type) reflect.Value
}

表示成图像大概如下：

我们可以通过 Injector 的 TypeMapper 来往依赖注入容器里面注入依赖，然后在我们需要为结构体的字段注入依赖，又或者为函数参数注入依赖的时候，可以通过 Applicator 或者 Invoker 来实现注入依赖。

而 SetParent 这个方法比较有意思，它其实将 Injector 这个模型拓展了，形成了一个有父子关系的模型。在其他语言里面可能作用不是很明显，但是在 go 里面，这个父子模型恰好和 go 的协程的父子模型一致。在 go 里面，我们可以在一个协程里面再创建一个 Injector，然后在这里面定义一些在当前协程以及当前协程子协程可以用到的一些依赖，而不用影响外部的 Injector。

当然上面说到的协程只是 Injector 里面 SetParent 的一种用法，另外一种用法是，我们的 web 应用往往会根据路由前缀来划分为不同的组，而这种路由组的结构组织方式其实也是一种父子结构，在这种场景下，我们就可以针对全局注入一些依赖的情况下，再针对某个路由组来注入路由组特定的依赖。

injector 的依赖注入实现

我们来看看 injector 的结构体：

type injector struct {
    // 注入的依赖
	values map[reflect.Type]reflect.Value
    // 上级 Injector
	parent Injector
}

这个结构体定义很简单，就只有两个字段，values 和 parent，我们通过 TypeMapper 注入的依赖都保存在 values 里面，values 是通过反射来记录我们注入的参数类型和值的。

那我们是如何注入依赖的呢？再来看看 TypeMapper 的 Map 方法：

func (inj *injector) Map(values ...interface{}) TypeMapper {
	for _, val := range values {
		inj.values[reflect.TypeOf(val)] = reflect.ValueOf(val)
	}
	return inj
}

我们可以看到，对于传入给 Map 的参数，这里获取了它的反射类型作为 values map 的 key，而获取了传入参数的反射值作为 values 里面 map 的值。其他的两个方法 MapTo、Set 也是类似的功能，最终的效果都是获取依赖的类型作为 values 的 key，依赖的值作为 values 的值。

到此为止，我们知道 Injector 是如何注入依赖的了。

那么它又是如何去从依赖注入容器里面拿到我们注入的数据的呢？又是如何使用这些数据的呢？

我们再来看看 callInvoke 方法（也就是 Injector 的 Invoke 实现）：

func (inj *injector) callInvoke(f interface{}, t reflect.Type, numIn int) ([]reflect.Value, error) {
    // 参数切片，用来保存从 Injector 里面获取的依赖
	var in []reflect.Value
    // 只有 f 有参数的时候，才需要从 Injector 获取依赖
	if numIn > 0 {
        // 初始化切片
		in = make([]reflect.Value, numIn)
		var argType reflect.Type
		var val reflect.Value
        // 遍历 f 参数
		for i := 0; i < numIn; i++ {
            // 获取 f 参数类型
			argType = t.In(i)
            // 从 Injector 获取该类型对应的依赖
			val = inj.Value(argType)
            // 如果函数参数未注入，则调用出错
			if !val.IsValid() {
				return nil, fmt.Errorf("value not found for type %v", argType)
			}

            // 保存从 Injector 获取到的值
			in[i] = val
		}
	}
    // 通过反射调用 f 函数，in 是参数切片
	return reflect.ValueOf(f).Call(in), nil
}

参数和返回值说明：

第一个参数是我们 Invoke 的函数，这个函数的参数，都会通过 Injector 根据函数参数类型获取
第二个参数 f 的反射类型，也就是 reflect.TypeOf(f)
第三个参数是 f 的参数个数
返回值是 reflect.Value 切片，如果我们在调用过程出错，返回 error

在这个函数中，会通过反射来获取 f 的参数类型（reflect.Type），拿到这个类型之后，从 Injector 里面获取我们之前注入的依赖，这样我们就可以拿到所有参数对应的值。最后，通过 reflect.ValueOf(f) 来调用 f 函数，参数是我们从 Injector 获取到的值的切片。调用之后，返回函数调用结果，一个 reflect.Value 切片。

当然，这只是其中一种使用依赖的方式，另外一种方式也比较常见，就是为结构体注入依赖，这跟 hyperf 里面通过注释注解又或者 Spring 里面的注入方式有点类似。在 Injector 里面是通过 Apply 来为结构体字段注入依赖的：

// 参数 val 是待注入依赖的结构体
func (inj *injector) Apply(val interface{}) error {
	v := reflect.ValueOf(val)

    // 获取底层元素
	for v.Kind() == reflect.Ptr {
		v = v.Elem()
	}

    // 底层类型不是结构体则返回
	if v.Kind() != reflect.Struct {
		return nil // Should not panic here ?
	}

    // v 的反射类型
	t := v.Type()

    // 遍历结构体的字段
	for i := 0; i < v.NumField(); i++ {
        // 获取第 i 个结构体字段
        // v 的类型是 reflect.Value
        // v.Field 返回的是结构体字段的值
		f := v.Field(i)
        // t 的类型是 *reflect.rtype
        // t.Field 返回的是 reflect.Type，是类型信息
		structField := t.Field(i)
        // 检查是否有 inject tag，有这个 tag 才会进行依赖注入
		_, ok := structField.Tag.Lookup("inject")
        // 字段支持反射设置，并且存在 inject tag 才会进行注入
		if f.CanSet() && ok {
            // 通过反射类型从 Injector 中获取对应的值
			ft := f.Type()
			v := inj.Value(ft)
            // 获取不到注入的依赖，则返回错误
			if !v.IsValid() {
				return fmt.Errorf("value not found for type %v", ft)
			}

            // 设置结构体字段值
			f.Set(v)
		}

	}
	return nil
}

简单来说，Injector 里面，通过 TypeMapper 来注入依赖，然后通过 Apply 或者 Invoke 来使用注入的依赖。

例子

还是以一开始的例子为例，通过依赖注入的方式来改造一下：

a := A{}
b := B{a: a}
c := C{b: b}

// 新建依赖注入容器
inj := injector{
    values: make(map[reflect.Type]reflect.Value),
}
// 注入依赖 c
inj.Map(c)
// 调用函数 test，test 的参数 `C` 会通过依赖注入容器获取
_, _ = inj.Invoke(test)
// 输出 "c called"

这个例子中，我们通过 inj.Map 来注入了依赖，在后续通过 inj.Invoke 来调用 test 函数的时候，将会从依赖注入容器里面获取 test 的参数，然后将这些参数传入 test 来调用。

这个例子也许比较简单，但是如果我们很多地方都需要用到 C 这个参数的话，我们通过 inj.Invoke 的方式来调用函数就可以避免每一次调用都要实例化 C 的繁琐操作了。

go 编译期判断类型是否实现接口

Posted on 2022-11-11 Edited on 2022-11-15

在看一些源码的过程中，发现一些如下的写法：

1 2	// var _ Interface = (Type)(nil) var _ FastInvoker = (LoggerInvoker)(nil)

其中 FastInvoker 是一个 interface，而 LoggerInvoker 实现了 FastInvoker 的方法。

这样看起来没什么作用，但是却可以帮助我们在编译期就发现 LoggerInvoker 是否实现了 FastInvoker 接口，因为我们这样写了之后，编译器会去检查，如果 LoggerInvoker 没有实现 FastInvoker 就会报错了。

这样我们就可以在编译的时候发现代码潜在的问题。

golang 反射

Posted on 2022-11-10 Edited on 2022-11-15

类型和接口

Go 是静态类型语言。每一个变量都有一个静态的类型，即在编译时类型已知且固定：比如 int、float32。

接口类型

接口类型是类型的一个重要类别，它表示固定的方法集。接口变量可以存储任何具体值（非接口），只要该值实现接口的方法即可。如：

// Reader 是封装基本 Read 方法的接口
type Reader interface {
    Read(p []byte) (n int, err error)
}

// Writer 是封装基本 Write 方法的接口
type Writer interface {
    Write(p []byte) (n int, err error)
}

任何实现了 Read(p []byte) (n int, err error) 方法的类型都被称为实现了 Reader 接口（Writer 同理）。这意味着 Reader 可以保存实现了 Read 方法的任何值：

var r io.Reader
r = os.Stdin
r = bufio.NewReader(r)
r = new(bytes.Buffer)

需要明确的是，不管 r 可能包含什么具体值，r 的类型始终是 io.Reader：Go 是静态类型的语言，而 r 的静态类型是 io.Reader。

空接口

接口类型的一个非常重要的示例是空接口：

1	interface{}

它表示空的方法集，并且任何值都满足空接口，因为任何值都有零个或者多个方法。

有人说 Go 的接口是动态类型的，但这会产生误导。接口是静态类型的：接口类型的变量始终具有相同的类型，即使在运行时存储在接口变量中的值可能会更改类型，该值也始终满足接口的要求。

接口的表示形式

接口类型的变量存储了一对值：分配给该变量的具体值，以及该值的类型描述。更确切地说，该值是实现接口的基础具体数据项，而类型描述了该数据项的完整类型。例如：

var r io.Reader
tty, err := os.OpenFile("/dev/tty", os.O_RDWR, 0)
if err != nil {
    return nil, err
}
r = tty

r 中包含了 (value, type) 对，即 (tty, *os.File)。请注意，类型 *os.File 实现的方法不只有 Read；尽管接口仅提供对 Read 方法的访问，但是其内部的值仍包含有关该值的所有类型信息。这就是为什么我们可以做下面的事情：

1 2	var w io.Writer w = r.(io.Writer)

因为 r 的具体类型里面包含了 Write 方法，而 r 里面包含的值依然持有它原来的值，所以这个断言是没有问题的。

一个重要的细节是，接口内始终保存 (值, 具体类型) 形式的元素对，而不会有 (值, 接口类型) 的形式。接口内部不持有接口值。

反射

反射第一定律：从接口值反射出反射对象

反射对象主要有两类：reflect.Type、reflect.Value

从底层讲，反射只是一种检查存储在接口变量中的值和类型对的机制。首先，我们需要了解反射包的两个类型：Type 和 Value，通过这两个类型可以访问接口变量的内容。还有两个函数 reflect.TypeOf 和 reflect.ValueOf，它们可以从接口值中取出 reflect.Type 和 reflect.Value。（另外，从 reflect.Value 可以很容易地获取到 reflect.Type，但是让我们暂时将 Value 和 Type 的概念分开。）

package main

import (
    "fmt"
    "reflect"
)

func main() {
    var x float64 = 3.4
    // 打印 type: float64
    fmt.Println("type:", reflect.TypeOf(x))
}

上面的代码看起来像将 float64 类型的变量 x 传递给了 reflect.TypeOf，而不是传递的接口值。但实际上，传递的是接口；

1 2	// TypeOf 返回 interface{} 中值的反射类型 func TypeOf(i interface{}) Type

当我们调用 reflect.TypeOf(x) 时，x 先被存在一个空接口中，然后再作为参数传递；reflect.TypeOf 从该空接口中恢复类型信息。

相应的，reflect.ValueOf 函数会恢复值信息。

1
2
3

var x float64 = 3.4
// value: <float64 Value>
fmt.Println("value:", reflect.ValueOf(x).String())

reflect.Type 和 reflect.Value 都有许多方法可以让我们执行检查和操作： * Value 具有 Type 方法，该方法返回 reflect.Value 的 Type 类型。 * Type 和 Value 都有一个 Kind 方法，该方法返回 go 的类型（语言本身的类型，而不是自定义的类型） * Value 的很多方法，名字类似于 Int 和 Float64，可以让我们获取存储在里面的值。 * 还有诸如 SetInt 和 SetFloat 之类的方法，可以修改接口的值。

反射第二定律：从反射对象到接口值

给定 reflect.Value，我们可以使用 Interface() 方法恢复接口值；

实际上，该方法将类型和值信息打包回接口表示形式并返回结果：

1 2	//接口返回v的值作为接口{}。 func (v Value) Interface() interface{}

结果，我们可以说

1 2	y := v.Interface().(float64) // y的类型为float64 fmt.Println(y)

打印反射对象 v 表示的 float64 值。一种更简洁的写法是：

1 2	// fmt.Println 本身就接受 interface{} 参数 fmt.Println(y)

反射第三定律：要修改反射对象，该值必须可设置

不可设置的例子：

var x float64 = 3.4
v：= reflect.ValueOf(x)
// panic: reflect.Value.SetFloat using unaddressable value
v.SetFloat(7.1)//错误：会panic错误。

因为调用 reflect.ValueOf(x) 的时候，函数只拿到了 x 的副本，而不是 x 变量本身，如果我们在函数内部修改了 x 那也只是修改了副本而已。

Value 的 CanSet 方法报告 Value 的可设置性：

var x float64 = 3.4
v：= reflect.ValueOf(x)
// false
fmt.Println("settability of v:", v.CanSet())

如果我们想修改它，可以在反射的时候，直接使用 x 的指针：

var x float64 = 3.4
p := reflect.ValueOf(&x) // 注意：取 x 的地址
// type of p: *float64
// settability of p: false
fmt.Println("type of p:", p.Type())
fmt.Println("settability of p:", p.CanSet())

我们注意到，这里我们使用了指针，但依然是不能设置其值。这是因为反射对象 p 是不可设置的，实际上我们想要设置的不是 p，而是 *p。为了获取 p 指向的内容，我们调用 Value 值的 Elem 方法，该方法指向指针：

1
2
3

v := p.Elem()
// settability of v: true
fmt.Println("settability of v:", v.CanSet())

现在，v 是一个可设置的反射对象了，我们可以使用 v.SetFloat 来修改 x 的值了：

v.SetFloat(7.1)
// 7.1
fmt.Println(v.Interface())
// 7.1
fmt.Println(x)

反射值需要变量的地址才能修改其表示的值。

结构体

在下面的例子中，我们使用结构体的地址创建反射对象，因为稍后将要对其进行修改。然后我们将 typeOfT 设置为其反射类型，并使用简单的方法调用对字段进行迭代。

type T struct {
    A int
    B string
}
t := T{23, "skidoo"}
s := reflect.ValueOf(&t).Elem()
typeOfT := s.Type()
for i := 0; i < s.NumField(); i++ {
    f := s.Field(i)
    fmt.Printf("%d: %s %s = %v.", i,
        typeOfT.Field(i).Name, f.Type(), f.Interface())
}

1 2	0: A int = 23 1: B string = skidoo

此处传递的内容还涉及可设置性的另一点：T 的字段名是大写（已导出），因为只能设置结构体的导出字段。

因为 s 包含可设置的反射对象，所以我们可以修改结构的字段：

1
2
3

s.Field(0).SetInt(77)
s.Field(1).SetString("Sunset Strip")
fmt.Println("t is now", t)

如果我们修改代码从 t 而不是 &t 创建 s，则对 SeteInt 和 SetString 的调用将失败，因为无法设置 t 的字段。

结论

反射定律：

反射可以从接口值到反射对象
反射可以从反射对象到接口值
要修改反射对象，该值必须可设置。

参考文档

MySQL 字符集踩坑记

Posted on 2022-11-05

环境：MySQL 5.7

现象

假设有一张表，结构如下：

1
2
3

CREATE TABLE `test` (
  `a` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

然后插入两条数据（一条是中文括号，一条是英文括号）：

1 2	INSERT INTO `test` (`a`) VALUES ('（甲）'); INSERT INTO `test` (`a`) VALUES ('(甲)');

然后大家觉得下面的语句结果如何？

1	SELECT * FROM test GROUP BY a

是不是觉得应该有两条，像下面的一样：

mysql> SELECT * FROM test;
+-----------+
| a         |
+-----------+
| （甲） |
| (甲)     |
+-----------+
2 rows in set (0.01 sec)

但实际上只有一条：

+-----------+
| a         |
+-----------+
| （甲） |
+-----------+
1 row in set (0.01 sec)

也就是说，对于 MySQL 来说，"（甲）" 和 "(甲)" 是一样的。

但是我们明确知道，这里其中一个是中文的括号，另一个是英文的括号。

原因

在 utf8_unicode_ci 下，MySQL 在比较的时候，"（" 跟 "(" 是一样的：

参考链接：https://stackoverflow.com/a/6602382/6048782

mysql> select _utf8"（" collate utf8_unicode_ci = _utf8"(" collate utf8_unicode_ci;
+-----------------------------------------------------------------------+
| _utf8"（" collate utf8_unicode_ci = _utf8"(" collate utf8_unicode_ci |
+-----------------------------------------------------------------------+
|                                                                     1 |
+-----------------------------------------------------------------------+
1 row in set (0.06 sec)

解决办法

使用 utf8mb4 字符集，因为：

mysql> select _utf8mb4"（" collate utf8mb4_general_ci = _utf8mb4"(" collate utf8mb4_general_ci;
+-----------------------------------------------------------------------------------+
| _utf8mb4"（" collate utf8mb4_general_ci = _utf8mb4"(" collate utf8mb4_general_ci |
+-----------------------------------------------------------------------------------+
|                                                                                 0 |
+-----------------------------------------------------------------------------------+
1 row in set (0.01 sec)

也就是说，在 utf8mb4_general_ci 这种字符集下，MySQL 在进行比较的时候才能正确判断中英文括号。

修改字段的 SQL 语句

1	alter table tbl modify col varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci