1.Gin源码分析 - 中间件（3）- Logger
2.Gin源码分析 - 中间件（1）- 介绍及使用
3.Golang源码剖析panic与recover，码剖看不懂你打我好了
4.Gin源码分析 （3）- Context功能概述
Gin源码分析 - 中间件（3）- Logger
本文深入剖析Gin框架内置中间件Logger，析实详细阐述其四种创建形式。码剖基本形式以默认配置输出日志至标准输出。析实自定义格式器形式允许用户调整日志输出格式。码剖指定输出流形式则灵活地将日志输出至特定写入器，析实spark运行流程源码同时可忽略指定路径的码剖日志。复杂配置形式提供高度定制化，析实是码剖创建中间件的高级手段。深入探讨LoggerConfig结构体，析实解析其三个关键属性：日志格式、码剖输出器和忽略路径。析实LogFormatter方法实现日志的码剖格式化，包含辅助函数进行颜色调整，析实如根据HTTP响应码和请求类型设置显示颜色。码剖defaultLogFormatter方法提供默认的日志格式化操作。详细解析LoggerWithConfig方法，该方法获取配置参数并判断输出环境，随后将忽略路径保存为映射，记录过滤的路径。计算处理时间和构建日志字符串，输出至指定写入器。
Gin源码分析 - 中间件（1）- 介绍及使用
中间件在Gin中起着至关重要的作用，它们构成了一条处理HTTP请求的链式结构，实现了代码的解耦和业务分离。本文将深入解析Gin的中间件使用和工作原理。
2.1 中间件的后端源码安装作用
Gin中间件有两个核心功能：一是对请求进行前置拦截，如权限验证和数据过滤；二是对响应进行后置处理，如添加统一头信息或格式化数据。这是它们作为前置过滤器和后置拦截器的角色。
2.2 中间件的实现
在Gin框架中，中间件本质上就是接收gin.Context参数的函数，与处理HTTP请求的Handler并无本质区别，非常直观易懂。
3.1 使用中间件
gin.Default()默认包含了Recovery和Logger中间件，而gin.New()则提供不带中间件的Engine。全局使用可通过gin.Engine的Use()方法，而局部使用则针对路由分组，如user组中使用Logger和Recovery。
4.1 开发自定义中间件
Gin支持自定义中间件，有直接接收Context参数的函数方式和返回HandlerFunc类型的封装方式，后者提供了更好的封装性。
5. 演示与总结
通过实际示例，我们将看到中间件如何串联执行，以及c.Next(), c.Abort(), c.Set(), c.Get()这些方法在处理流程中的作用。下文将深入剖析中间件的代码实现和常用中间件的工作机制。
Golang源码剖析panic与recover，看不懂你打我好了
哈喽，大家好，我是asong，今天与大家来聊一聊go语言中的"throw、try.....catch{ }"。如果你之前是钻石机构源码一名java程序员，我相信你一定吐槽过go语言错误处理方式，但是这篇文章不是来讨论好坏的，我们本文的重点是带着大家看一看panic与recover是如何实现的。上一文我们讲解了defer是如何实现的，但是没有讲解与defer紧密相连的recover，想搞懂panic与recover的实现也没那么简单，就放到这一篇来讲解了。废话不多说，直接开整。
Go 语言中panic 关键字主要用于主动抛出异常，类似 java 等语言中的 throw 关键字。panic 能够改变程序的控制流，调用 panic 后会立刻停止执行当前函数的剩余代码，并在当前 Goroutine 中递归执行调用方的 defer；
Go 语言中recover 关键字主要用于捕获异常，让程序回到正常状态，类似 java 等语言中的 try ... catch 。recover 可以中止 panic 造成的程序崩溃。它是一个只能在 defer 中发挥作用的函数，在其他作用域中调用不会发挥作用；
recover只能在defer中使用这个在标准库的注释中已经写明白了，我们可以看一下：
这里有一个要注意的点就是recover必须要要在defer函数中使用，否则无法阻止panic。最好的验证方法是先写两个例子：
运行我们会发现example2()方法的panic是没有被recover住的，导致整个程序直接crash了。这里大家肯定会有疑问，为什么直接写recover()就不能阻止panic了呢。我们在 详解defer实现机制(附上三道面试题，海豚app源码我不信你们都能做对)讲解了defer实现原理，一个重要的知识点**defer将语句放入到栈中时，也会将相关的值拷贝同时入栈。**所以defer recover()这种写法在放入defer栈中时就已经被执行过了，panic是发生在之后，所以根本无法阻止住panic。
通过运行结果可以看出panic不会影响defer函数的使用，所以他是安全的。
这里我开了两个协程，一个协程会发生panic，导致程序崩溃，但是只会执行自己所在Goroutine的延迟函数，所以正好验证了多个 Goroutine 之间没有太多的关联，一个 Goroutine 在 panic 时也不应该执行其他 Goroutine 的延迟函数。
其实我们在实际项目开发中，经常会遇到panic问题， Go 的 runtime 代码中很多地方都调用了 panic 函数，对于不了解 Go 底层实现的新人来说，这无疑是挖了一堆深坑。我们在实际生产环境中总会出现panic，但是我们的程序仍能正常运行，这是因为我们的框架已经做了recover，他已经为我们兜住底，比如gin，我们看一看他是怎么做的。
我们先来写个简单的生存闯关源码代码，看看他的汇编调用：执行go tool compile -N -l -S main.go就可以看到对应的汇编码了，我们截取部分片段分析：
上面重点部分就是画红线的三处，第一步调用runtime.deferprocStack创建defer对象，这一步大家可能会有疑惑，我上一文忘记讲个这个了，这里先简单概括一下，defer总共有三种模型，编译一个函数里只会有一种defer模式。在讲defer实现机制时，我们一起看过defer的结构，其中有一个字段就是_panic，是触发defer的作用，我们来看看的panic的结构：
简单介绍一下上面的字段：
上面的pc、sp、goexit我们单独讲一下，runtime包中有一个Goexit方法，Goext能够终止调用它的goroutine，其他的goroutine是不受影响的，goexit也会在终止goroutine之前运行所有延迟调用函数，Goexit不是一个panic，所以这些延迟函数中的任何recover调用都将返回nil。如果我们在主函数中调用了Goexit会终止该goroutine但不会返回func main。由于func main没有返回，因此程序将继续执行其他gorountine，直到所有其他goroutine退出，程序才会crash。
下面就开始我们的重点吧～。
在讲defer实现机制时，我们一起看过defer的结构，其中有一个字段就是_panic，是触发defer的作用，我们来看看的panic的结构：简单介绍一下上面的字段：上面的pc、sp、goexit我们单独讲一下，runtime包中有一个Goexit方法，Goext能够终止调用它的goroutine，其他的goroutine是不受影响的，goexit也会在终止goroutine之前运行所有延迟调用函数，Goexit不是一个panic，所以这些延迟函数中的任何recover调用都将返回nil。如果我们在主函数中调用了Goexit会终止该goroutine但不会返回func main。由于func main没有返回，因此程序将继续执行其他gorountine，直到所有其他goroutine退出，程序才会crash。写个简单的例子：运行上面的例子你就会发现，即使在主goroutine中调用了runtime.Goexit，其他goroutine是没有任何影响的。所以结构中的pc、sp、goexit三个字段都是为了修复runtime.Goexit，这三个字段就是为了保证该函数的一定会生效，因为如果在defer中发生panic，那么goexit函数就会被取消，所以才有了这三个字段做保护。看这个例子：
英语好的可以看一看这个： github.com/golang/go/is...，这就是上面的一个例子，这里就不过多解释了，了解就好。
接下来我们再来看一看gopanic方法。
gopanic的代码有点长，我们一点一点来分析：
根据不同的类型判断当前发生panic错误，这里没什么多说的，接着往下看。
上面的代码都是截段，这些部分都是为了判断当前defer是否可以使用开发编码模式，具体怎么操作的就不展开了。
在第三部分进行defer内联优化选择时会执行调用延迟函数(reflectcall就是这个作用)，也就是会调用runtime.gorecover把recoverd = true，具体这个函数的操作留在下面讲，因为runtime.gorecover函数并不包含恢复程序的逻辑，程序的恢复是在gopanic中执行的。先看一下代码：
这段代码有点长，主要就是分为两部分：
第一部分主要是这个判断if gp._panic != nil && gp._panic.goexit && gp._panic.aborted { ... }，正常recover是会绕过Goexit的，所以为了解决这个，添加了这个判断，这样就可以保证Goexit也会被recover住，这里是通过从runtime._panic中取出了程序计数器pc和栈指针sp并且调用runtime.recovery函数触发goroutine的调度，调度之前会准备好 sp、pc 以及函数的返回值。
第二部分主要是做panic的recover，这也与上面的流程基本差不多，他是从runtime._defer中取出了程序计数器pc和栈指针sp并调用recovery函数触发Goroutine，跳转到recovery函数是通过runtime.call进行的，我们看一下其源码(src/runtime/asm_amd.s 行)：
因为go语言中的runtime环境是有自己的堆栈和goroutine，recovery函数也是在runtime环境执行的，所以要调度到m->g0来执行recovery函数，我们在看一下recovery函数：
在recovery 函数中，利用 g 中的两个状态码回溯栈指针 sp 并恢复程序计数器 pc 到调度器中，并调用 gogo 重新调度 g ， goroutine 继续执行，recovery在调度过程中会将函数的返回值设置为1。这个有什么作用呢？ 在deferproc函数中找到了答案：
当延迟函数中recover了一个panic时，就会返回1，当 runtime.deferproc 函数的返回值是 1 时，编译器生成的代码会直接跳转到调用方函数返回之前并执行 runtime.deferreturn，跳转到runtime.deferturn函数之后，程序就已经从panic恢复了正常的逻辑。
在这里runtime.fatalpanic实现了无法被恢复的程序崩溃，它在中止程序之前会通过 runtime.printpanics 打印出全部的 panic 消息以及调用时传入的参数。
这就是这个逻辑流程，累死我了。。。。
结尾给大家发一个小福利，哈哈，这个福利就是如果避免出现panic，要注意这些：这几个是比较典型的，还有很多会发生panic的地方，交给你们自行学习吧～。
好啦，这篇文章就到这里啦，素质三连（分享、点赞、在看）都是笔者持续创作更多优质内容的动力！
Gin源码分析 （3）- Context功能概述
在深入研究Gin框架的内部结构时，Context作为核心组件之一，其重要性不言而喻。它不仅负责在中间件间共享变量，管理请求流程，还包括参数解析、结果渲染和业务逻辑的执行。context.go文件中详细定义了Context的功能。本文将概述Context的主要数据结构和功能，后续章节将详细剖析每个部分。Context的结构与功能
Context的设计旨在封装Request和Response，以及支持参数的传递。其核心数据结构包括对请求参数的高效管理和处理机制，如Keys map[string]interface{ }，通过Set和Get方法实现数据共享，其中Get方法提供了多种变体，方便获取不同类型的参数。参数处理
Context的核心职责之一是解析和管理各种请求参数。支持的类型包括URL Param（如/user/:name）, URL Query, PostForm, FormFile, 和 MultipartForm。例如，URL Param用于解析路径变量，URL Query处理查询字符串，而PostForm和FormFile则在POST请求中处理表单数据和文件上传。 Context的Bind函数提供了一站式的参数绑定和验证服务，能够将请求参数直接映射到结构体中，同时支持json, xml, protobuf, form, query, yaml等多种数据格式，极大地简化了数据解析工作。ShouldBind函数类似，但允许开发者在绑定错误时进行更精细的错误处理。Header和Cookie处理
除了上述内容，Context还负责处理HTTP Header和Cookie，这些功能尚未详述，后续章节会继续探讨。