谁再用 Map 传参，上去就给他一jio，别客气

大家好，我是一航；

前几天，技术群(文末可加)里面有小伙伴儿在交流ApiPost在请求数据是List的时候，有个bug；为了验证，然后在Controller分别写了List和Map接收请求参数的接口进行测试；

也是出于好奇，就在群里面问了一句：有多少人写接口用过Map来接收数据的？结果发现还有好些个伙伴说现在就用的Map，让我还挺惊讶的，问其原因，出奇一致的说：所有请求格式都可以；换个表达就是：啥都能往里面塞…

好吧！我承认，这确实算是个优点；

但是，在我的团队里面，是明令禁止，不允许使用Map来进行传参的（除了那些和业务无关的工具类）；这个传参，不限于接口参数，业务逻辑间的调用也是一样；那为什么要这么规定呢？

下面就来好好交流一下使用Map传参存在那些优缺点；概括如下：

• 优点

  • 灵活（才疏学浅，作为传参，目前我只能总结这么一个了）

• 缺点

  • 代码可读性差
  • 使用麻烦
  • 大量硬代码
  • 可维护性差
  • 校验参数麻烦
  • 文档工具不友好

总结起来就一句话：优点没啥，缺点一箩筐

下面就来详细说说：

优点

灵活

唯一一个我觉得好的地方，就是足够灵活了；

使用Map<String,Object>去接收请求传参时，不管是URL链接上的key、value值，还是通过Body传递的Json串，都能直接转换成Map，不管是有多复杂的Json串，都能解析映射成Map；不需要专门定义任何额外的对象来接收数据；

如果要添加参数，只需要在Url或者Json数据中加上键值对，后端接口的Map中就能接收到新添加的值了；而且数据格式不限，因为Value是Object类型的，所以基础类型的任意值、文本，都是可以接收到的。

示例代码：

@PostMapping