关于一次spring源码的探究

背景：

      最近项目新弄了一个系统服务，系统服务一般会做日志的采集收录工作，于是利用切面写的日志采集，这其中就遇到了问题，一般来说当前主流restful请求都是POST+JSON方式，因此一般来说入参都是会加入@RequestBody注解，但是为了在切面中获取流中的body体信息需要走一遍获取流的逻辑，但是注解的内容里已经走过一遍这个逻辑了，导致再次获取失败报错，这个错误其实也是常见以及开发人员会遇到的。由此需要自定义类似@RequestBody的注解，需要在自定义的内容中进行业务逻辑处理，这块的自定义其实网上篇幅很多，也基本可以应用就不再多说，我仅仅贴一点我的代码

 

 

 此时问题出现了，我自定义的返回对象必须写死在这里，这样每当我要给一个新的POST入参对象进行切面的时候如果这个对象和已经定义的不是一个那就要弄好多个这种配置，这话可能大家迷惑，那就迷惑吧 本身有些东西都是需要有缘人才能探索，知识无法共知。开源人也是自私的我写这个的目的其实是为了加深自己的印象以便于以后查阅。自己反过来想 为啥@RequestBody用一个注解就行了为啥我就必须受这个限制呢，于是乎开展了如火如荼的源码跟踪，总是听人说看spring源码如果围城的反义，城外的人感觉太难，特别避讳进入，城里的人觉得太美太妙不想出来，我今天也想试试。

    很多源码的查阅真的是需要个切入点的，而不是漫无目的的看，那样我觉得白扯累死你也看不明白，没得收获，要不看不懂要不看了就忘记，经验告诉我 90%以上的人都是看不懂然后就是反馈迷惑一团浆糊，然后在这个深渊中无法自拔，永远不想触及，好了那就跟着一个关键点走，spring是如何获取请求方法的入参是什么的

算了还是看人家写的吧 https://blog.csdn.net/weixin_42859458/article/details/118332596  已经写的很明白