常见的拦截器和顺序：

1. 监控上报和访问日志打印：日志和监控是根本，出了任何事情，日志和监控都要有，因此该拦截器要作为第一个执行的， 这样才能在结束的时候，感知到最终结果。
2. 响应编码器：对外返回保证一致性，是好协议的必备条件。一致性都保证不好的协议，一定不是好协议。
3. 异常和panic捕获。
4. IP拦截
5. 限流和熔断
6. 登录态验证
7. 参数解码器
8. 加密和解密
9. 缓存接口内容：缓存不放在拦截器的原因可能是控制类接口互相调用。
10. 业务处理器

日志、监控、返回

当一个调用流程，因为一个非预期的原因无法继续时，如果可以同时将原因返回，对于可观测行时非常好的。 当非预期返回时，用户期待的信息一般有：

1. 有一个可枚举的字段，比如说大家常说的错误码、HTTP CODE，用来进行代码层面的逻辑判断。
2. 一个简短的描述，告知为何无法满足预期。用户可以依据此从感性上判断出了什么问题。
3. 对于系统的维护者，还需要一个归因，用于上报到监控平台。

接口设计

接口有三大要求：接口唯一标识、入参、出参。出参信息一般包含：

1. 错误码。判断接口是否按照预期完成功能，错误码用于程序逻辑判断。
2. 错误信息。文字版的描述信息。告诉调用方或者最终用户不满足预期的原因。
3. 主体信息。接口符合预期时，返回的信息。此时，错误码为类似0、SUCCESS这样的内容。

当接口执行过程中，碰到如下场景，需要打印日志和构造出参。常见的场景有： 日志分析工具：调用查询日志接口失败 现场打印日志，并返回错误。

内因、外果。

和OpenTelemetry的区别： 整合log、trace、metric，提高易用性。 降低不必要的抽象级别,提高性能。 扩展也不太行，有一些抽象，导致其性能很差，比如span End的时候，需要做snapshot，必要性不大。

httpkit要解决的问题

1. 统一打印日志，上报监控。需要能够定制method。http请求的method建议是method/path。
2. 可以定制编解码器，并且互不干扰。比如，不要通过域名映射解码器的方式，他们互相影响，不太好，带来额外复杂度。

参考资料

https://mp.weixin.qq.com/s/P0mbc0rqt6vYhK3YeTDBrQ https://foreverzmyer.hashnode.dev/go-cert