本文目录
- 一、Hertz中间件Recovery
- 二、Hertz中间件跨资源共享
- 三、Hertz 响应
- 四、Hertz请求
- 五、Hertz中间件Session
一、Hertz中间件Recovery
Recovery中间件是Hertz框架预置的中间件，使用server.Default()可以默认注册该中间件，为Hertz框架提供panic回复的功能。
如果我们没有使用Default（），可以通过下面的方式进行注册：
h := server.New()
h.Use(recovery.Recovery())
在 panic 发生之后，Recover 中间件会默认打印出 panicRecovery 中间件会恢复 Hertz 框架运行中的任何panic的时间、内容和堆栈信息，同时通过 *app.Requestcontext 将返回响应的状态码设置成 500。
这也是处理Web框架异常的一种手段。
可以通过WithRecoveryHandler()函数来定义出现panic后处理的函数。示例如下。
配合Use使用中间件的示例代码如下。
二、Hertz中间件跨资源共享
跨源资源共享(CORS)机制允许服务器标识除了它自己的其它 origin，使得浏览器可以访问加载这些资源; 该机制也用来检查服务器是否允许浏览器发送真实的请求，通过浏览器发送"预检"请求实现，在预检请求头部中有HTTP 方法和真实请求会用到的头。
比方说前后端分离。前后端部署的域名都不一样，所以需要设置cors进行跨域。
hertz 提供 cors 跨域中间件的实现 ，这里的实现参考了 gin 的 cors。
通过go get github.com/hertz-contrib/cors就可以导入需要的cors包。
然后在config里面配置源、方法、头等，还能设置最大的缓存时间。
AllowAllOrigins配置为True的时候，允许任何来自任意originn的客户端跨域访问服务端资源。同时，AllowOriginFunc和AllowOrigins不可以使用，会冲突。
AllowOrigins就是一个切片列表，允许某些地址发起请求。比如：
三、Hertz 响应
Header响应设置：
- 设置Content-Type
func (ctx *RequestContext) SetContentType (contentType String)
- 通过
[]byte方式设置Content-Type
func (ctx *RequestContext) SetContentType (contentType []byte)
- 设置状态码
func (ctx *RequestContext) SetStatusCode(statusCode int)
未找到就是404，通过下面NotFound（）进行设置。
- 设置重定向
func ( ctx * RequestContext) Redirect(statusCode int, uri []byte)
- 设置cookie
- 渲染
支持对JSON（前后端分离）、HTML（模版）、Protobuf（微服务）等渲染，也就是输出的类型。
- Body
输出的内容可是流式、string、write等。
如下面的代码是进行流式样例。
- 添加File文件
四、Hertz请求
- URI
五、Hertz中间件Session
Session就是会话连接。
下面的代码就是使用了 sessions 来存储用户会话数据。服务器监听在 8000 端口，定义了一个 /incr 路由处理函数，该函数使用一个名为 “mysession” 的 session 来跟踪访问次数。每次访问 /incr 路径时，服务器都会从 session 中获取一个名为 “count” 的值，如果该值存在，则将其转换为整数并递增，然后将更新后的值存回 session，最后向客户端返回新的计数值。
在代码中，首先创建了一个 Web 服务器实例，并为其指定监听端口为 8000。然后创建了一个 cookie 存储实例，用于加密和安全地存储 session 数据。通过 h.Use(sessions.New(“mysession”, store)) 将 session 中间件添加到服务器处理链中。在 /incr 路由的处理函数中，通过 sessions.Default© 获取当前请求的 session 实例，接着获取并更新计数器值，并将更新后的计数器值保存到 session 中。最后，使用 c.JSON 向客户端返回状态码 200 和一个包含计数值的 JSON 响应。服务器通过调用 h.Spin() 方法开始监听并处理请求。
store := cookie.NewStore([]byte(“secret”)) 中，“secret” 是一个字符串，它被用作生成 cookie 的安全密钥。这个密钥用于在服务端对 cookie 进行加密和签名，以确保 cookie 的内容在客户端和服务器之间传输时不会被篡改，并且只有服务器能够读取和修改 cookie 的内容。
当创建一个新的 cookie.Store 实例时，提供一个 secret 密钥是非常重要的，因为它增强了会话管理的安全性。如果 secret 密钥不够安全（例如，如果它太短或者容易被猜到），那么攻击者可能会尝试对 cookie 进行攻击，比如进行会话劫持。
ookie.NewStore 函数接受一个字节切片作为参数，因此 “secret” 字符串被转换为字节切片 []byte(“secret”) 传递给该函数。这个 secret 密钥在服务器的整个生命周期中应该保持不变，以便能够正确地验证和读取之前设置的 cooki
session可以用在用户处，也就是当用户登录后，保存了session信息，可以在每个界面都获取购物车信息。
