大家好，我是小悟。是怎么个事呢？
支付宝消费者投诉详情接口，刚对接的时候能正常使用，后面有一次去调用的时候，竟然报错了，提示"服务异常"。
仔细检查了开发文档，并没有什么明显的变化。业务请求参数就一个，通过传入投诉id查询详情数据。
于是就想到去支付宝商家后台，查看一下这条数据是否正常，不出意外的话，就要出意外。通过时间筛查，官方后台数据竟然没了。
那我会不会是记错了呢？这个时间段没有投诉数据，所以查询不到。小伙伴们，以Java之父的人格担保，这个时间段之前一定是有数据的，因为投诉id以及相关信息我是存数据库的。
于是把代码和开发文档，排查来排查去，耗了不少时间，始终无法解决。"服务异常"，"服务异常"，"服务异常"。
有一个朋友经常做支付宝的业务，抱着试试看的想法去咨询他。没想到真的有结果，虽然结果并不能解决"服务异常"的问题。
他也遇到这个问题，和官方技术支持聊了好久，配合他排查，一个发请求，一个看日志，一个看日志，一个发请求。
排查到最后，技术支持还是反馈给产品了，说是因为这个平台规则，只保留近180天客诉交易。意思就是超过180天的客诉都没了，这。。。我听完是直摇头啊。
从技术支持需要排查，到后面反馈给产品，可以看出他们之间信息也是不对称的。不然按理说一咨询就应该给出结果的。
但是在投诉这一块开发文档上也没有哪里写明了"只保留近180天客诉交易"的字眼。我真的会谢。
另外让我想起了，当初刚开始调用另一个接口，查询投诉记录，一直报错，提示"参数错误"，也不直说哪个请求参数错误。
业务请求参数除了条件必选就是可选，其中当前页码不传会有默认值1，每页条数不传会有默认值10。
有个习惯，对接第三方接口会先写伪代码看看返回的数据和格式，既然业务请求参数都不是必传的，本着怎么简单怎么来的原则，一个参数都没传就执行代码了。
没错，正如你所想的那样，执行了很多遍就是返回"参数错误"，心态要崩了呀。。。
这里要特别提一下，之所以一个请求参数都没传，除了看到开发文档的注释，没有必传字段外。
还有一个原因是因为同时间对接过支付宝另一个相似的接口，请求参数注释也没有必传，写伪代码的时候也是一个参数都没传就执行了，但是返回是成功的。
回到正题上来，抱着试试看的心态，给当前页码和每页条数传了值，我去，成功了啊。
呜呜呜，参数注释误我啊。。。
写到这里，就再提一嘴，接入准备写着本产品不支持服务商代商家接入。
但是每个接口又写着支持第三方代理调用，那到底是支不支持第三方代调用。
这种不确定性，有时候对开发者评估项目的可实现性是有一定影响的。少不了又要和产品经理扯了。
总结一下，就是说开发文档参数注释写得不正确。对接第三方，开发文档何其重要，请求参数注释又是重中之重。
因为于开发者来说直接面对的就是开发文档，参数能传正确与否，就看注释写的意思如何。
或者接口在返回提示的时候更具体些，比如请求参数param错误，对接人员不就一下明白错误出现在哪里了吗。你们说这开发文档是谁写的，是不是要扣绩效。
作为开发人员，难免会去对接一些第三方的接口，难免会遇到一些坑。接口一直对，坑就会一直遇。
刷一道面试题
Java的GC如何判断对象可以被回收？
谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。
您的一键三连，是我更新的最大动力，谢谢
山水有相逢，来日皆可期，谢谢阅读，我们再会
我手中的金箍棒，上能通天，下能探海