摘要：一个项目可以从多个方面进行优化，这篇笔记主要记录的是我上周在思考不够成熟的情况下，贸​然对公司项目中的Axios请求方法进行了大量的优化而导致不停踩坑不断坑自己坑同事的狗血经历。虽然改造的出发点是好的，但执行起来并没有那么顺利，主要原因还是思考不够全面。也希望各位看官不要再踩此类坑，凡事三思而后行。

一、项目中关于Axios请求接口这块的命名现状

每个程序猿都有自己的写代码习惯，对于类似或同样的功能，大家都喜欢Ctrl+C、Ctrl+V大法。确实，有时候我也挺喜欢用的。但有些时候，团队协作开发，往往就会出现意想不到的结果。如图：公司项目中关于请求接口的各种混乱命名和传参.jpg

上图是我昨晚为了写文章而整理出来的一部分，在整理时我发现曾经自己也复制错了不少代码。

1.1、一个真实的小故事

还是给大家讲一个小故事吧，故事的主人公是前同事@智伟。因为那次的错误坑了大家很久，所以我的印象比较深刻。

时间回退到2021年8月中旬，公司有了搞中台的想法。此中台非彼中台，所以大家不要把它想的很高大上。那时我们的中台作用很简单，给自己用，可以给商户开套餐和管理商户的菜单权限。尽管现在它已经变得更复杂了，但实质上还是有些鸡肋。

智伟在接到新任务后像往常一样在自己的分支上开发功能，在对接完接口后我会把代码合到dev分支上。

有天夜晚我们要发布上线，@琳妹妹在中台上写发版说明，一提交结果报错了。智伟、@郑阳和其他几个同事都凑过去看了一眼，然后各自回来找问题。智伟回到自己电脑前，试了下写发版说明的功能，点击提交按钮后成功发布。然后你们能想到的，琳妹妹刷新了浏览器，也清空了浏览器缓存，但提交仍然失败。负责后端接口的是郑阳，前端写页面和对接的是智伟，他们两个来来回回跑了几趟，也看了又看，还是没有找出问题。

大约持续了快半个小时吧，我看了下代码，发现这里的提交用的是put，但请求参数挂给了params: params。然后我网上搜索了下axios的几种请求传参方式，发现果然是这里出了问题。当把接收参数改为data: params后，再提交就成功了。

那么问题来了，为什么在原来写错的时候，智伟能提交成功而琳妹妹却提交失败呢？

从提交内容上来说，智伟能提交成功是因为发版内容那里写的东西少，而琳妹妹则吧啦吧啦写了几百字。从源头上来说，是URL长度限制引起的。虽然不同的浏览器对URL长度限制标准是不一样的，但始终还是有上限。请求中params: params这种方式接收的参数会直接跟在url后面，所以你懂的哈。

解决完问题后，我们终于可以开心的回家了。

你以为事情就这样结束了吗？太天真了！智伟小兄弟在多个项目中Ctrl+V了同样的错误代码，结果导致多个项目在后续的一段时间内总是曝出此类问题......

故事讲完了，再回过头来看看前面的那张代码现状图有什么想法？有些是对的，有些是错的，但即使是对的，在命名上也给他人带来了误解。

二、优化之路并不顺利

我总结了下目前项目中关于请求接口这块代码的弊端有以下三点：

1. 命名不规范、传参不规范，其他同事在复制后修改时极其容易发错
2. 所有接口变化的地方只有url(接口地址)和method（请求方式）有变化，完全没必要使用export 函数名来再封装一层。
3. 部分页面上会出现methods中定义的方法名跟调用的接口同名，坑新人绝佳！

2.1、优化第一版太过草率

鉴于此，我在清明节后才开始正式的进行了改造。改造的规则也很简单，代码见下方。

// 接口文件中使用新的定义方式v1.0.0版
import { urlAPIToKey } from '@/utils/publicMethod' // 引入自己封装的方法，可将url接口生成一个key名，避免乱命名的现象发生
const urlList = [
  { url: '/Message/keywords_lists' }, // 获取字段适配列表
  { url: '/Message/keywords_save_status', method: 'patch' }, // 更新状态
  { url: '/Message/keywords_add', method: 'post' }, // 添加
  { url: '/notice/list', diy: { auth: true } }, // auth: true表示需要登录权限，实际上在后台中这个校验没啥用处，因为后台本身就需要登录才能访问
  { url: '/goods_groups/{id}', method: 'put' }, // 更新商品分组，{id}为动态参数
  { url: '/goods/{id}/share_image/' }, // 分享海报，{id}为动态参数
]
export default urlAPIToKey(urlList)

上面的代码中，我用一个数组来存放当前文件中所用到的url请求地址和method请求方式，url中的动态参数用{id}来定义，方便后面调用时用正则替换。开发者也不用纠结给接口取什么样的名字，因为我会使用method + url最后一级目录的形式自动生成一个key名。这一切的工作都靠urlAPIToKey()这个方法来实现，我还专门写了一个示例demo页面。如图：

我也在原项目稳定版上建立了若干个分支，一个分支对应一个要修改的API接口文件，然后把任务分发了下去。为了避免大家改错，我又给几个新同事演示了一遍如何修改。演示完毕后让他们按照我刚才的方法，每完全修改一个旧的方法名时再把此方法给注释掉，然后继续改下一个接口。其他同事在开发时，只需要按照我定义好的方法套用模板就行了，完全不用担心因错传data或params而导致接口报错的情况。此时，我安排了4个同事来做这件优化的事情。安排人多是因为项目中有50个被定义的接口文件要进行优化，这个工程量还是比较大的，大家分摊一些会比较好。我也自认为这一版的改造能够解决历史遗留问题，但很快就被现实打脸了。

2.2、优化第二版兼容更全面

对于上面第一版的优化，很快就暴露出问题了。先是遇到了因动态id导致key重名的问题，在解决后没过多久又再次出现了key重名的问题，这个问题是先在@坤那里遇到的。我的第一反应是不应该啊，看完代码后才发现我遗漏了一些特殊情况。这次的起因是在同一个接口文件中，出现了多个最后一级目录相同的接口。在使用urlAPIToKey()转换后，后面的会同名的会只保留最后一个。什么意思呢，代码如下：

// 定义时写了8个接口
import { urlAPIToKey } from '@/utils/publicMethod'
const urlList = [
  { url: '/points/lists' }, // 积分规则列表
  { url: '/points/del_integral' }, // 积分规则列表删除
  { url: '/points/info' }, // 积分规则详情
  { url: '/level/lists' }, // 会员等级列表
  { url: '/level/info' }, // 会员等级详情*
  { url: '/level/save', method: 'post' }, // 保存会员等级详情
  { url: '/user/list' }, // 会员列表
  { url: '/user/info' }, // 获取会员详情
]
export default urlAPIToKey(urlList)

// 生成后只有5个接口
{
  GetLists: { url: '/level/lists' },
  GetDel_integral: { url: '/points/del_integral' },
  GetInfo: { url: '/user/info' },
  PostSave: { url: '/level/save', method: 'post' },
  GetList: { url: '/user/list' },
}

这个结果确实挺尴尬的的哈，明明定义了8个接口，经过urlAPIToKey()转换后只有5个接口。之所以出现这种情况是因为上述接口中最后一级为lists的出现了2次，并且都是get请求，在执行方法自动生成后的key都为GetLists。于是我又加强了一下判断，若存在相同的key，则再向上再取一级目录名。为了避免后期接口路径有修改导致key自动发生变化，我还是采用了对象的形式来定义api接口。最终定义的代码结构如下：

// 采用对象的方式定义接口，可以自定义key名
const urlList = {
  GetLists: { url: '/points/lists' }, // 积分规则列表
  GetDel_integral: { url: '/points/del_integral' }, // 积分规则列表删除
  GetInfo: { url: '/points/info' }, // 积分规则详情
  GetLevelLists: { url: '/level/lists' }, // 会员等级列表
  GetLevelInfo: { url: '/level/info' }, // 会员等级详情*
  PostLevelSave: { url: '/level/save', method: 'post' }, // 保存会员等级详情
  GetList: { url: '/user/list' }, // 会员列表
  GetUserInfo: { url: '/user/info' }, // 获取会员详情
}
export default urlList

上述代码中的key也是通过优化后的urlAPIToKey方法生成，开发者也可以自己定义一个key。

2.3、未考虑支付功能的分支导致项目异常

经过这一版的优化，我个人觉得已经没啥坑了，毕竟现在已经解决了文章开头提到的痛点。大家花了整整一周的时间，优化完了30多个接口文件。我也做了一遍复检工作，有漏改或错改的我会让他们继续修改。眼看黎明即将到来，干就完了！但我又掉坑里面了！

前面说了，此次优化接口是在稳定版上单独拉分支优化，这一步没有问题。问题出现在我们不应该每改完一个旧接口后就将其注释掉，因为支付功能的分支不在稳定版中！无奈之下，我又让@坤赶紧拉了一个新分支，恢复前面所有接口中被注释掉的旧接口名。还好当初是注释而不是用更暴力的方法--删除，要不然又得加几个小时的班才能恢复完。[:笑哭]

三、最后

上周跟几个同事折腾了一周，挺坑也挺辛苦的。但对于结果来说，并没有达到预期，我个人也反思了好几天。优化这条路，还是比较漫长的，眼前先稳住当前项目的运转，后期再陆续改造。

转载声明：
　　若亲想转载本文到其它平台，请务必保留本文出处！
本文链接：/xwzj/2022-04-17/Optimize-the-request-method.html

若亲不想直保留地址，含蓄保留也行。艺灵不想再看到有人拿我的技术文章到他的地盘或者是其它平台做教(装)程(B)而不留下我的痕迹。文章你可以随便转载，随便修改，但请尊重艺灵的劳动成果！谢谢理解。