背景

以前好好的导出功能突然就不行了，后台表示是前端没有传token导致的

封装

时间回溯到80天前，我刚入职公司2个月，要做导出功能，自然要参考下以前的写法，

可这些逻辑是复制黏贴的，有三处重复，我提取到了公共方法，一共4个地方使用，那三个重复的地方想着以后有迭代到时再换成公共方法。

这个后台管理项目是服务于多个端，每个端的导出方法都不近相同，而公用的ajax函数库封装的过于繁杂，单单method就分为get、 getForm、getJson、postForm、postJson、post、postFile等。

导出方法直接用的axios，因此只能自己带token，加token需要3行代码，要改四个文件，考虑到系统不止这一种形式的导出，所以我通过拦截器的形式统一加，很快啊，这个问题就解决了，发版，回家!

因为是线上bug，测试询问产生的原因，通过看前端代码的更改记录，怀疑是后端突然要了权限，于是就在前端群里问了一下有没有知道这件事的。

这时一位前端同事觉得统一加拦截器的解决方式不好，我便在全局搜索了下导出，加上问题反馈的模块，其实这次问题更应该定位为"我端的导出了问题"

更让我觉得不可思议的是，一个月前其他端的前端来帮忙，那种旧的导出方式又在三个文件复制黏贴了，只是这个功能还没上线，因为有简单的交接我才知道

跟项目管理人说明这次改动

如果说要在4个文件加token代码，我宁愿都使用公共方法，而这次也算是有需求迭代了。

这样的话一共波及到7个地方，4个已经使用公共方法的导出，3个使用重复逻辑的导出。

公共方法除了加token外没有改动，在这个过程，还发现了一处导出的下载地址是错的，导出条数也被限制死了，后端服务也要做修改。

代码和到测试环境，把影响范围给到测试，验收通过后合到master，打包给运维，发布到线上环境，再次验收，结束。

其实导出这种点对点的功能，当时就应该及早地把那三个复制黏贴的也改掉，主要是怕麻烦吧，这样后三个就不会出现了。

看来对于坏的代码要尽快地解决，不然它就变成了新代码了。

对比直接加拦截器的方法，在时间上确实也不是一个量级的。

封装是一种投资，经常因为不满足现阶段的利益而被忽视。