关于Prometheus的自定义埋点，前一篇博文已经介绍了，为啥这里又来一次？
看过前文的小伙伴可能会知道，之前采用的simpleclient包定义的几个metric来实现的，实际上有更简单方便的姿势，那就是直接借助MeterRegistry来创建Metric来实现数据采集即可
相比较于前文的实现，总的来说简易程度可见一般，上篇文章可以点击下文查看
在实际的业务开发中，为了方便获取Spring容器中的Bean对象，一个常见的case就是创建一个SpringUtil类，内部持有SpringContext上下文，然后提供一个静态的方式获取bean对象，然而这种使用姿势，一个不小心可能导致npe
今天我们来看一下这个场景
之前介绍过一篇拦截器的基本使用姿势: 【WEB系列】SpringBoot之拦截器Interceptor使用姿势介绍
在SpringBoot中，通过实现WebMvcConfigurer的addInterceptors方法来注册拦截器，那么当我们的拦截器中希望使用Bean时，可以怎么整？
话说自从前后端分离之后，前后端放在一起的场景就很少了，最近写个简单的后台，突然踩坑了，使用themeleaf模板渲染时，发现th:each来遍历生成表单数据，一直抛异常，提示Property or field 'xxx' cannot be found on null
接下来看一下这个问题到底是个什么情况
之前介绍了一篇SpringBoot集成Prometheus实现数据上报的博文，在前面一篇博文中，更多的是一个SpringBoot应用如何最小成本的接入Prometheus，并结合Grafana配置一个完整的应用监控大盘
有看过前文的小伙伴可能知晓，SpringBoot接入Prometheus之后，基本上不用做额外的开发，就已经实现了我们关心的JVM情况、GC情况、HTTP调用请求等信息，然而在实际的业务开发过程中，我们总会遇到一些需要手动上报的场景，那么我们可以怎么处理呢？
本文的核心知识点：
在使用Mybatis开发时，借助xml来写具体的sql，再写传参类型或者返回结果类型时，通常会与ParameterType, ParameterMap, ResultMap, ResultType这四个打交到，那么这个Type与Map到底怎么区别，什么时候要指定类型，什么时候又可以不指定呢？
最近有小伙伴在讨论#{}与${}的区别时，有提到#{}是用字符串进行替换，就我个人的理解，它的主要作用是占位，最终替换的结果并不一定是字符串方式，比如我们传参类型是整形时，最终拼接的sql，传参讲道理也应该是整形，而不是字符串的方式
接下来我们来看一下，mapper接口中不同的参数类型，最终拼接sql中是如何进行替换的
在mybatis的xml文件中直接写sql比较方便简洁，但是需要注意的是，在xml文件中，经常会遇到一些需要转义的场景，比如查询 id < xxx的数据，这个小于号就不能直接写在sql中，接下来我们将看一下，mybatis中的有哪些转义符，可以怎么处理转义问题
上面一篇博文介绍了mybatis + xml配置文件的使用方式，在上文中介绍到，xml文件是可以省略掉的，直接使用java注解来实现CURD，接下来我们看一下，如何使用注解来实现等同的效果
今天遇到一个非常有意思的事情，一个小伙伴反馈，同样的sql，为啥直接通过mysql终端执行的结果，和mybatis的执行结果不一致，感觉有点鬼畜；然后看了一下，发现这是个比较典型的问题，#{}与${}的使用区别
接下来我们看一下这个问题，顺带也重新学习一下它们两的区别
mybatis作为数据的ORM框架，在国内的应用市场还是非常可观的，当初刚开始工作时使用spring + mybatis进行开发，后来也使用过hibernate, jdbctemplate, jooq，mybatisplus等其他的一些框架，
就个人使用感触来讲jooq的使用姿势和写sql差不多，基本上可以会写sql的无需额外的培训，立马可以上手；
hibernate最大的特点就是借助方法名来映射sql语句，非常有特点，但是当查询条件复杂一些的话，对小白而言就没有那么友好了；
而jdbctemplate，这个在小项目，轻量的db操作中，用起来还是很爽的，非常灵活，但是也有一些点需要特别注意，比如queryForObject，查不到数据时抛异常而不是返回null；
至于mybatis以及衍生的mybatis-plus，也就是接下来的主角了，它的特点如何，为什么受到国内大量开发者的追捧，将它作为db操作的第一ORM框架，让我们看完之后再说
