就拿 axios 请求后台 api 来说吧 很多人喜欢把 api 专门写到一个文件里 然后每个页面里面请求的时候 import 导入。
这样确实可以统一管理 api 接口。但是用多了反而感觉很麻烦。一个 import 导入的时候麻烦。第二个是后期维护修改的时候并没有感觉到便利。 反而这个文件跳那个文件 那个再跳另一个。总感觉切换查看不同文件是一个很浪费时间的过程。当然坏处就是不能复用，真的用的很多的接口也提出来 - 知乎提问
先回答问题本身：当然有必要。
前端项目本质上是在为人提供人机交互的服务，所以封装的意义不止在于能够少写代码，方便维护，另一个意义是可以保持交互的统一。
就拿题主问题中的请求封装来说吧，发起请求要不要有 Loading 提示？请求成功和失败要不要有弹窗提示？鉴权失败了要不要去跳转授权？等等这些统一的交互行为仅仅靠开发者的自觉性是难以保障的，关于这一点我的其他文章里也专门强调过。
显然要求团队成员在实现某个功能时记得要干这干那的成本要远远高于记得调用某个统一的方法。
话说回来，输出一个高质量的前端项目仅靠代码封装也还是不够的。单看问题描述，感觉题主其实有点吐槽错对象了，你遇到的那个问题其实不是封装的锅，而是在工程化里决定用那样的文件结构来组织代码的锅。
我个人也非常反感那样的文件组织形式，因为前端工程大多可以以页面为单元，然后把该页面涉及到的所有资源都收敛到一处，把外部真正需要的资源再收敛到 index 里暴露出去。首先能够带来的一个显而易见的好处就是开发者不需要来来回回各种切换文件夹了。除了页面，其它所有的小单元，比如组件，比如模块，都可以这样去做文件组织，其他地方甚至其他项目想复用的时候，整个文件夹拷贝过去就是了。
然后在「聚焦」的过程中再去寻求「发散」，大概的意思是那些真的需要放在全局，放在外部统一搞的事情，自然会在你面向单元开发的过程中被暴露出来，到那时再去有的放矢地做设计。这貌似有点奥卡姆剃刀的意思，也体现了软件工程里高内聚低耦合的思想（我为什么要像小学生作文那样做个思想总结。。）
再多说两句，我把封装理解成是开发者的行为约束工具，当封装也约束不了的时候再去考虑文档（这种情况一般出现在当时的封装对于当前的需求来说粒度太细，需要文档来提供组合用例），当文档也约束不了的时候再靠人来约束人吧。。。
