一不小心又踩了个feign的坑！

引言

前阵子不是刚刚使用feign调用了第三方的接口吗，觉得feign这玩意还挺好用，代码写起来比较简单， 不过也被读者喷啦，引入一个httpClien就能够解决的问题，非要搞得这么复杂。其实本来项目里面就是采用feign来进行和其他业务进行交互的，所以没有必要再去搞一个HttpUtils。最近又收到一个需求，需要继续接入第三方的一个视频校验视频。为啥要去接入视频校验，主要是比如用户传入一个视频，我们需要对这个视频进行校验，看看这个视频是否合规，是否涉黄、涉政等。如果这些视频都需要人工一个个去审核的话，这样比较耗费人力，所以需要接入阿里云的视频校验功能，通过这个来帮我们解决这个视频是否合规的问题。看了下文档对接起来还是比较容易的参数也就几个一个是视频的url，还有一个是视频需要校验的情况有哪些。

踩坑

背景介绍完了我们就直接接入就可以啦，三下五除二就接完了，自测了几个小视频看下来都是符合正常流程，然后就提测了。测试测了十几个case也没发现啥问题，然后就跟着下一个发布版本正常发布生产啦，生产也看啦几个视频没啥问题。然后这个功能就算正式 交互完成啦。不过过了几天就又被运营找上来了，说好多突然积累啦好多视频审核都是失败的，我心想你肯定是不会用，上线的时候都是好好的，肯定是你操作姿势不对。嘀咕归滴咕问题还是需要去解决的。首先打开下日志发现好多报错都是返回同一个错误码，但是也有调用成功的。既然是第三方返回的报错那肯定是第三方的bug了，如果是我写的bug那肯定都会是校验失败的就不会存在部分成功和部分失败啦。所以我随手挑了一个报错的case，把请求参数，以及请求返回结果扔给第三方让他们帮忙查下是啥问题。让人家排查问题最起码的东西还是需要提供的，比如调用时间、请求参数、请求接口等这信息。有了这些信息人家才能更方便快捷的帮你定位问题。但是在公司里面往往业务方找你排查问题就是直接@你，调用你的接口报错了，赶紧解决下。不说哪个环境？也不说哪个接口？也不发下请求参数。反正啥都没有，就是你的问题，赶紧给我解决就行。但是这样往往都是自己漏传了这个参数，或者是自己环境不对。找人帮你定位问题，问题三要素至少要说清楚吧？至少需要先自己排查下是否是你的问题吧？这应该是作为程序员最基本的素养吧！扯远啦回到正题。毕竟花钱了的，作为第三方排查生产问题响应速度还是可以的，立马就定位到问题了。原来是我提交过去的视频链接打不开，导致无法被校验，所以返回校验失败。但是我根据我这边记录的日志这个视频链接是可以打开的。我马上让他们把他们接受到的参数发给我下，然后和我这边记录日志的链接对比下:

我们可以发现不同点就是在最后几个字母，知道的朋友肯定一眼就能看出问题所在了，第三方接受到的URL是被decode了，然后我们自己这边的URL能打开的话就是这个链接有些特殊字符需要被encode之后才能被打开，如果直接decode之后就不能够打开了。然后找第三方的人确认是否他们有对我们的参数进行decode，最终得到的结论是没有。那难道是我们代码的问题，仔细检查了下代码发现了这么一行可能有影响的代码

 @PostMapping(value = "xxxx", produces = MediaType.APPLICATION_FORM_URLENCODED_VALUE)
    Response submit(@SpringQueryMap VideoValidationSubmitReq req);

这个produces是按照提供的文档接入的看下来应该没啥问题。然后通过POSTMAN调试一把也没有复现出问题，那问题肯定是出在feign调用的过程中啦。源码之下无秘密，经过上次踩坑事件，《feign的一个注解居然隐藏这么多知识！》阅读过源码，这次阅读它的源码就有点轻车熟路了，最终很快就定位到问题了。最终定位到问题的关键代码是这一行，

UriUtils.encode

我们可以进入这个方法首先看看这个方法的注释我们就明白其中的原因所在了：如果需要进行encode的参数已经是被encode了就不会被继续被encode了，直接跳过这个字符。很明显上述我们的参数已经是有部分已经被encode了，然后在通过feign传过去之后只有没有被encode 的参数才会继续encode，这样就会导致第三方服务端那边接受到这边的参数再经过decode所以我传过去的URL参数就全部被解密了。全部解密后然后就导致url解析后失败了，不能够被正常打开了。找到原因了我们解决问题就比较简单了，既然feign使用的encode不能满足我们的要求，我们就不使用它的提供的方法，本着快速解决bug的原则然后把produces 指定为application/json;charset=UTF-8"，然后把参数通过手动调用URLEncoder.encode(xxx,"utf-8")把参数传给第三方。这个方法如果已经被encode的字符串也会继续第二次encode并不会和UriUtils.encode一样遇到已经被encode的字符就直接不encode了。快速修复完这个bug然后让测试帮忙测了一把没啥问题，赶紧发布到生产去，不然运营人员一直催个不停。代码被发布上去之后，把校验失败的视频改下状态，然后手动触发下job让它重新跑一下，观察了一会全部校验通过。幸好我当时多了个心眼留了个后门可以通过job重新拉取校验失败的视频。这个bug总算修复了，虽然解决的不是很完美，但是先把问题修了再说，后续再去研究下比较优雅的解决方法，还得赶紧跟领导去解释原因去？不然年终奖不知道还有么有？

结束

• 由于自己才疏学浅，难免会有纰漏，假如你发现了错误的地方，还望留言给我指出来,我会对其加以修正。
• 如果你觉得文章还不错，你的转发、分享、赞赏、点赞、留言就是对我最大的鼓励。
• 感谢您的阅读,十分欢迎并感谢您的关注。