Pain Point： 所有差异都被塞进同一个拦截器，文件瞬间变成黑洞。

“AxiosFactory + 多实例”。主要保持复用，不同服务拥有独立拦截器。

**以下结构让职责清晰。而且每一层只关心自己的事**

. 请求内核层 ts const request = new AxiosFactory({ timeout:5000,interceptorHooks: apiInterceptor,});只负责创建实例和挂载公共拦截器，不涉及业务码或 token 来源。

. 服务协议层 针对每个后端写专属 interceptor，例如 UserCenterInterceptor、OrderSystemInterceptor。它只处理该服务特有的成功码、message 字段名和 header 要求。

. 应用装配层 在应用启动时注入运行时能力： ts configureServiceAuth({ getToken: => localStorage.getItem?，''。onAunticationFailure: => router.push,});setErrorMessenger=>ElMessage.error);这样，无论是 Web、Electron还是移动端。只需要在 bootstrap 中提供对应实现即可。

四 、 别让 Service 层直接 import router

 import router from '@/router';request.interceptors.response.use=>{ if{router.push;
}return Promise.reject;})，强耦合导致：



公共包无法独立使用；

不同项目路由方法不同；

单元测试必须 mock router；


说到推荐做法，

ts
configureServiceAuth({
getToken:=>localStorage.getItem?，'',onAunticationFailure:=>router.push
});

Service 层只调用 onAunticationFailure真正行为由 App 决定，实现依赖反转。说起来，

说到常见写法。

ts
import { ElMessage } from 'element-plus';ElMessage.error;

Pain Point换 UI 库或在不同网站时必须改动 Service 层。

方法这方面，注入错误展示器。

ts
setErrorMessenger=>ElMessage.error);

Service 内部仅调用 showErrorMessage展示细节交给 App 注入。

真实业务中并非所有错误都需要弹 toast，也不是所有认证失效都要跳登录。说到例如，



页面轮询接口；

静默刷新 token；其实，

后台探测接口；


通过请求配置提供行为开关：

ts
request.get;request.get，

Pain Point没有开关会导致“一刀切”体验糟糕；有开关则能灵活控制，





AxiosFactory

ts
const request = new AxiosFactory({
timeout:5000。interceptorHooks: apiInterceptor,});

apiInterceptor

ts
// 注入 token 与业务码校验，但不直接读取 localStorage 或 router
const token = servicesCoreHelper.getAunticationToken;servicesCoreHelper.handleAunticationFailure;怎么说呢，

configureServiceAuth

setErrorMessenger

整个链路中。没有任何 Service 层硬编码具体实现，使得该库可以被多个项目复用。

至于如果是单应用，

src/
├── app/
│   └── bootstrap.ts // 注入 token 获取、错误展示等
├── services/
│   ├── core/
│   │   ├── axios-factory.ts
│   │   ├── helper.ts
│   │   └── index.ts // 导出 configureServiceAuth 等 API
│   ├── interceptors/
│   │   ├── user-center.ts // 使用者中心专属拦截器
│   │   └── order-system.ts // 订单程序专属拦截器
│   ├── modules/
│   │   ├── user.ts // 对外暴露的业务接口
│   │   └── order.ts
│   └── types.ts // 公共类型定义
└── shared/
└── constants.ts // 常量与枚举
如果是 Monorepo。可把 services 提到 packages：
packages/
├── services/
│   ├── src/core/
│   ├── src/api/
│   └── src/types/
└── apps/
└── example-vite/
└── src/bootstrap/ // 应用级注入点
关键点的观点是，services 永远 **不 import** 任意 app 文件；话说回来，app 在 bootstrap 时把能力注入 services。

九 、 请求层自查清单



是否直接 import router？→ 否 → 使用 onAunticationFailure 注入。

是否直接 import UI 库？→ 否 → 使用 setErrorMessenger 注入。

是否只有一个全局 axios 实例且对接多个后端？不过，→ 否 → 为每个后端创建独立实例。

拦截器里是否出现大量 if 分支？→ 否 → 拆分为不同 Service 实例。

是否支持 hiddenNotify / skipAuthRedirect 等行为开关？按理说，→ 是 → 满足业务细粒度需求。

Token 获取方式是否硬编码为 localStorage？话说回来，→ 否 → 使用注入函数获取。

错误是否按 “网络 / HTTP / BusinessCode / 构造 / 忽略” 分类处理？→ 是 → 易于定位与统一处理。


十 、 并非所有项目都需要复杂封装
Pain Point： 盲目引入大型 services 架构会导致开发成本激增，特别是一次性 demo 或活动页。适合轻量封装的场景：



单页面 demo；

活动页、小工具；

项目仅对接单一后台；

登录态简单，仅本地存储；

适合完整 services 架构的场景：



中后台程序；

多应用共享同一套请求能力；其实，

对接多个异构后端；

登录态来源复杂；

项目生命周期长，需要长期维护和演进；

再看原则。先评估复杂度，再决定是否引入“三层”设计；不要为小项目背负沉重架构。

十一 、 小结



前端请求层是 协议边界 + 应用边界 + UI 边界 的交叉口。

当这些边界没有划清，就会出现“黑洞”——所有异常与差异都塞进一个文件。不过，


 

请求内核复用

每个后端对应独立 Service 实例及拦截器

Token 与登录失效行为由 App 注入

错误展示方式由 App 注入

请求级别行为开关





这样。即使以后增加新后端、更换 UI 框架或迁移到 Electron，也只需在 App 层做少量配置，而不会触碰主要 Service 层，从而保持代码可维护性与可复用性。