前言
我是个前端的技术小白，最近入职了一家新的公司，面试的时候全程都比较顺利，到技术主管二面的时候问了个对API使用的看法，问我平时使用API的一个代码习惯问题。我以vue为技术栈举例，当时我的回答是先通过npm或pnpm将拦截器和基地址封装成一个request.js的文件夹后，再把里面的axios实例导出。然后再src目录下新建一个API文件夹，再按照模块的方式新建文件后，导入request实例将所有接口封装一个函数，然后将函数导出使用。
(涉及到公司代码，就只能大致写个逻辑举例😂)
我平时这个做法主要是为了方便分模块管理接口，在代码运行的环境不同情况下，接口有的时候需要做更换url或者请求方式或者传参数据。然后考虑到某些接口会出现在多个模块使用，更换起来就很麻烦，所以我的习惯是以这种三层封装的方式去管理接口。
面试了几家虽然也有问到关于封装的问题，但是问到api的还是第一次，当时比较疑惑但是回答出来技术主管也是比较认同的。后面也是顺利入职后才知道技术主管会问这个问题。
当时入职后项目比较赶，还有不到一个月项目就需要部署上线了，当时我接手项目后看到是在网上购买了一个开源的C端项目，按照当时的负责人描述的是项目分了S端、C端、B端，时间比较赶只能是去购买的开源项目。当时给我的任务是需要将原项目内的接口全部替换成我们的接口，因为项目复杂程度比较高，也没时间给我去熟悉代码和后端返回的状态等信息，最重要的是里面的接口都是直接写在页面内的，这就导致我在更改一条接口的时候需要全局搜索去全局替换，虽然听起来也比较方便，但是后端的接口也是临时赶出来的，导致返回的参数也不一定完全正确，而C端的逻辑我一时半会也没完全捋清楚，导致在更改接口或者逻辑的时候异常艰苦。
(还是模拟一下当时搜索的场景，真实情况比这个离谱🤣)
在后面项目不是特别赶的时候，我也是尝试将接口全部封装出来(里面的细节还是挺多的，因为源码中在拦截器部分是把异步处理和同步处理抽离了出来，以及我封装好接口后需要去源码那边将之前的接口换成我导出的函数，就涉及到需要特别熟悉里面代码实现的逻辑交互等)，用的也是我楼上描述的三层封装方式。这样子后面项目维护或者增加需求的时候在可能需要更改接口的情况下，维护起来就会特别方便。
结语
通过以上的个人经历小分享，每个公司的项目都会多多少少遇到一些和之前项目结构不一样的情况，需要做到就是在出现不规范或者不利于维护的代码情况下，我们需要学会怎么去处理。
