在挣扎中前行～～

近期需要使用 go kit 搭建，go 的微服务架构体系，毕竟这个东西是第一次使用，感觉好烦，都是从零开始，也从网上找一些文档来看，又一次看到一个使用工具直接生成kit工程的方案，后来随着自己的摸索，其实可以不用使用工具，直接创建一个空的工程，随后一点一点的完善这个工程就好，说了一点自己确实遇到的感受，好了，接下来开始 我们的学习

我们先介绍一下kit中的各个模块，这些模块是真的需要理解的模块定义，因为kit这个东西就是这么命名定义的：

kit

kit 究竟是什么？他不是框架，一定要记住，他不是框架，他是一个开发项目的工具包，框架和工具包的区别在哪？框架好多好多都是封装好的，你只需要调用相关接口，就可以完成好多好多功能；但是kit不是框架，他不会给你封装接口，不是你直接调用接口就可以完成你需要的功能，kit只会给你提供工具，工具包，第三方的工具包，kit会进行封装，封装自己的工具，放在自己的内部，因为kit是工具包，这个就相当于将第三方的工具封装成自己的工具；举一个简单的例子：

这是框架iris的 设置跨域的例子
func CRS(ctx iris.Context) {
	ctx.Header("Access-Control-Allow-Origin", "*")
	ctx.Header("Access-Control-Allow-Credentials", "true")
}
这一步是框架给你封装的，需要跟进去看一下，这个到底是给谁设置的
我们需要先看 这个context，到底是都包含了哪些东西～
type Context struct {
	// the http.ResponseWriter wrapped by custom writer.
	writer ResponseWriter
	// the original http.Request
	request *http.Request
	// the current route registered to this request path.
	currentRoute RouteReadOnly

	// the local key-value storage
	params RequestParams  // url named parameters.
	values memstore.Store // generic storage, middleware communication.
	query  url.Values     // GET url query temp cache, useful on many URLParamXXX calls.
	// the underline application app.
	app Application
	// the route's handlers
	handlers Handlers
	// the current position of the handler's chain
	currentHandlerIndex int
	// proceeded reports whether `Proceed` method
	// called before a `Next`. It is a flash field and it is set
	// to true on `Next` call when its called on the last handler in the chain.
	// Reports whether a `Next` is called,
	// even if the handler index remains the same (last handler).
	proceeded uint32
}


====》〉》〉 然后我门在看这个设置到底是谁的设置
//  +------------------------------------------------------------+
//  | Response Headers helpers                                   |
//  +------------------------------------------------------------+

// Header adds a header to the response, if value is empty
// it removes the header by its name.
func (ctx *Context) Header(name string, value string) {
	if value == "" {
		ctx.writer.Header().Del(name)
		return
	}
	ctx.writer.Header().Add(name, value)
}

====》〉》〉 这一步还是看不出来，但是 我们能找到这个 ctx.writer，  writer 是重点
==》〉那我们继续看
type Context struct {
	// the http.ResponseWriter wrapped by custom writer.
	writer ResponseWriter
	
==》〉他是 ResponseWriter
也就是说，iris的context封装了 ResponseWriter

但是kit的context 是原生 context，所以不可能封装这个属性，而且我们也不可能重重新把这个再一次封装一次，所以我只能去寻找这个设置

// NewServer constructs a new server, which implements http.Handler and wraps
// the provided endpoint.
func NewServer(
	e endpoint.Endpoint,
	dec DecodeRequestFunc,
	enc EncodeResponseFunc,
	options ...ServerOption,
) *Server {。。。}
这个方法，在kit中是最常见并且使用的函数，也是作为http的handle使用的，具体为啥后续说，
那我们需要解决的是跨域问题，而且是，我们需要在ResponseWriter中，进行设置属性，那我们就可以在这个NewService中进行查找，一定会有我们需要的 ResponseWriter，为什么？因为设计kit的人一定会想到这个问题而且ResponseWriter，是返回前端的响应，所以在httphandle中一定会有，所以，我们一个一个看，DecodeRequestFunc。type DecodeRequestFunc func(context.Context, *http.Request) (request interface{}, err error)，这个明显是一个请求入口，不会有，EncodeResponseFunc：type EncodeResponseFunc func(context.Context, http.ResponseWriter, interface{}) error；嗯啊找到了，这是一个出口，而且我们找到了，那我们就可以设置属性，从而跨域问题解决；

在此，也提一下跨域问题，当前端出现跨域问题时，这个问题不一定出现在前端还是后端

跨域问题：我理解的有两种：
一：前端请求时，被浏览器拦截，前端直接报跨域问题，请求不会发送到后端
二：后端接收到请求，响应前端时，也被浏览器拦截，服务器不会报异常，但是前端回报异常，但这个时候后端是接收到了请求。

天才第一步，了解第一步