微前端容器标准化 —— 公共能力篇：通用请求

大型前端项目统一请求解决方案：从乱象到落地实践

✅ 本文解决的核心问题 ：大型前端项目中多业务团队请求封装各自为政、实现差异大、跨 Portal 复用困难等痛点。

✅ 核心方案 ：基于「核心层 + 适配层 + 业务层」的三层架构，通过插件化扩展与统一注册机制，实现请求能力标准化与业务灵活性的平衡。

✅ 落地收益 ：代码复用率提升 80%+，维护成本降低 50%+，子应用跨 Portal 迁移零代码修改，支撑微前端架构落地。

✅ 适合人群：前端架构师、微前端实践者、多团队协作项目开发者。

一、业务背景：请求封装的乱象与痛点

1.1 现状：多团队并行下的请求封装困境

在大型前端项目中，多业务团队并行开发时，HTTP 请求封装环节普遍存在以下问题：

现状问题	具体表现	业务影响
各自为政	各团队独立实现 request 封装，代码重复度高	资源浪费，重复造轮子
实现差异	接口、错误处理、配置策略各不相同	协作成本高，学习曲线陡峭
维护分散	相似功能多版本维护，质量参差不齐	技术债务累积，升级困难
复用障碍	子应用跨 Portal 迁移时，request 实例切换导致行为不一致	微前端架构推进受阻

1.2 典型场景：跨 Portal 复用的核心矛盾

子应用在不同 Portal 间迁移时，请求行为不一致是最突出的痛点：
Portal B Portal A 子应用 Portal B Portal A 子应用 原始状态 迁移后 ❌ 行为不一致，需要修改代码 ❌ 接口调用方式变更 ❌ 错误处理逻辑差异 使用 Portal A Request 实例 返回符合 Portal A 规范的响应 被迫使用 Portal B Request 实例 返回不同格式的响应

1.3 痛点汇总：影响业务迭代的核心障碍

痛点类别	具体问题	业务影响	优先级
跨 Portal 复用	子应用无法在不同 Portal 间无缝复用	微前端架构推进受阻，开发成本激增	🔥 高
技术债务	多团队重复实现相似功能，质量参差	维护成本指数级上升，迭代效率低下	⚠️ 中
协作效率	接口标准不统一，知识共享困难	跨团队协作成本高，新人上手慢	⚠️ 中
监控缺失	无统一监控与错误上报机制	问题排查困难，用户体验无法保障	📊 低

二、设计目标与核心价值

2.1 建设目标

1. 统一请求能力：为所有业务线提供标准化的请求管理工具
2. 提升开发效率：消除重复开发，降低维护成本，提升代码可维护性
3. 增强功能扩展性：集成各业务线特有需求，支持灵活扩展
4. 保障跨 Portal 复用：实现子应用在不同 Portal 间的无缝迁移

2.2 核心价值

• 统一而不失灵活：核心能力标准化，业务层可按需定制
• 高效而不失质量：一次开发，多团队复用，保障稳定性
• 简单而不失强大：易用的 API，丰富的插件扩展能力

三、整体架构设计：三层架构解耦业务与核心

3.1 设计理念：高内聚、低耦合

基于高内聚、低耦合原则，采用「核心层 + 适配层 + 业务层」三层架构，既保证核心能力的统一性，又给予业务团队充分的定制空间：

• 核心层：提供基础 HTTP 请求能力与扩展接口，是整个系统的"地基"
• 适配层：提供默认插件与便捷 API，是连接核心与业务的"脚手架"
• 业务层：各团队基于核心层实现业务特有配置与逻辑，是"业务定制层"

3.2 架构分层职责

层级	核心职责	主要组件	维护方
核心层	提供基础 HTTP 请求能力与扩展接口	HttpRequest、PluginCenter、InterceptorPipeline	架构组
适配层	提供默认插件与扩展能力，隔离业务与核心	RetryPlugin、CachePlugin、MonitorPlugin	架构组
业务层	基于核心层实现业务特有配置与逻辑	AppRequest、AuthPlugin、业务方法	各业务团队

3.3 完整架构图

网络层
插件系统
核心能力层
业务请求层
注册中心
子应用层
子应用 A
子应用 B
子应用 C
RequestCenter
request-team-a
request-team-b
request-team-c
request-core
RetryPlugin
CachePlugin
MonitorPlugin
AuthPlugin
HTTP Client

四、核心模块详细设计：从地基到业务定制

4.1 核心层（@spc-fe-common/request-core）：基础能力抽象

核心层提供最基础的 HTTP 请求能力与插件扩展接口，是整个系统的基石，隔离了底层 HTTP 客户端与业务逻辑：

// ==================== 基础类型定义 ====================
// 请求配置项
interface RequestConfig {
  baseURL?: string;
  timeout?: number;
  method?: 'GET' | 'POST' | 'PUT' | 'DELETE';
  url?: string;
  data?: unknown;
  headers?: Record<string, unknown>;
  retry?: { maxRetries: number };
  cache?: { enabled: boolean };
  [key: string]: unknown;
}

// 响应体结构
interface Response<T = unknown> {
  data: T;
  status: number;
  [key: string]: unknown;
}

// 拦截器类型
type RequestInterceptor = (config: RequestConfig) => Promise<RequestConfig> | RequestConfig;
type ResponseInterceptor = (res: Response) => Promise<Response> | Response;

// 插件标准接口
interface Plugin {
  beforeRequest?: (config: RequestConfig) => Promise<RequestConfig>;
  afterRequest?: (res: Response) => Promise<Response>;
  onError?: (error: Error) => Promise<void>;
}

// 模拟底层HTTP客户端（实际可替换为axios/fetch）
declare function createHttpClient(config: RequestConfig): {
  request: <T>(config: RequestConfig) => Promise<Response<T>>;
};

// ==================== 插件中心：统一管理所有插件 ====================
class PluginCenter {
  private readonly plugins: Plugin[] = [];

  // 注册插件
  register(plugin: Plugin): void {
    this.plugins.push(plugin);
  }

  // 执行请求前插件钩子
  async handleBeforeRequest(config: RequestConfig): Promise<RequestConfig> {
    let result = config;
    for (const plugin of this.plugins) {
      if (plugin.beforeRequest) result = await plugin.beforeRequest(result);
    }
    return result;
  }

  // 执行响应后插件钩子
  async handleAfterRequest(res: Response): Promise<Response> {
    let result = res;
    for (const plugin of this.plugins) {
      if (plugin.afterRequest) result = await plugin.afterRequest(result);
    }
    return result;
  }
}

// ==================== 拦截器管道：链式执行请求/响应拦截器 ====================
class InterceptorPipeline {
  private readonly reqInterceptors: RequestInterceptor[] = [];
  private readonly resInterceptors: ResponseInterceptor[] = [];

  // 添加请求拦截器
  addReqInterceptor(fn: RequestInterceptor): void {
    this.reqInterceptors.push(fn);
  }

  // 添加响应拦截器
  addResInterceptor(fn: ResponseInterceptor): void {
    this.resInterceptors.push(fn);
  }

  // 串行执行所有请求拦截器
  execRequestInterceptors(config: RequestConfig): Promise<RequestConfig> {
    return this.reqInterceptors.reduce((p, fn) => p.then(fn), Promise.resolve(config));
  }

  // 串行执行所有响应拦截器
  execResponseInterceptors(res: Response): Promise<Response> {
    return this.resInterceptors.reduce((p, fn) => p.then(fn), Promise.resolve(res));
  }
}

// ==================== 核心请求类：封装请求全流程 ====================
abstract class HttpRequest {
  // 底层客户端、插件管理器、拦截器管道
  private readonly client: ReturnType<typeof createHttpClient>;
  private readonly pluginCenter: PluginCenter;
  private readonly interceptorPipeline: InterceptorPipeline;

  constructor(config: RequestConfig) {
    this.client = createHttpClient(config);
    this.pluginCenter = new PluginCenter();
    this.interceptorPipeline = new InterceptorPipeline();
  }

  /**
   * 统一请求入口（核心方法）
   * 执行流程：插件前置 → 拦截器 → 发起请求 → 拦截器 → 插件后置
   */
  async request<T = unknown>(config: RequestConfig): Promise<Response<T>> {
    // 1. 执行插件前置处理
    const finalCfg = await this.pluginCenter.handleBeforeRequest(config);
    // 2. 执行请求拦截器
    const reqCfg = await this.interceptorPipeline.execRequestInterceptors(finalCfg);
    // 3. 发起网络请求
    const rawRes = await this.client.request<T>(reqCfg);
    // 4. 执行响应拦截器
    const res = await this.interceptorPipeline.execResponseInterceptors(rawRes);
    // 5. 执行插件后置处理
    return this.pluginCenter.handleAfterRequest(res);
  }

  // 插件注册方法（对外暴露）
  use(plugin: Plugin): void {
    this.pluginCenter.register(plugin);
  }

  // 拦截器注册入口（对外暴露）
  interceptor = {
    request: { use: (fn: RequestInterceptor) => this.interceptorPipeline.addReqInterceptor(fn) },
    response: { use: (fn: ResponseInterceptor) => this.interceptorPipeline.addResInterceptor(fn) },
  };
}

4.2 适配层（BaseRequest）：开箱即用的能力封装

适配层基于核心层，提供默认插件与便捷 HTTP 方法，降低业务团队接入成本：

// ==================== 通用内置插件（空实现，可按需扩展逻辑） ====================
class RetryPlugin implements Plugin {}
class CachePlugin implements Plugin {}
class MonitorPlugin implements Plugin {}

// ==================== 基础请求类：通用能力封装 ====================
class BaseRequest extends HttpRequest {
  constructor(config: Partial<RequestConfig> = {}) {
    // 合并默认配置：超时10s、重试3次、开启缓存
    super({ timeout: 10000, retry: { maxRetries: 3 }, cache: { enabled: true }, ...config });

    // 注册全局通用插件
    this.use(new RetryPlugin());
    this.use(new CachePlugin());
    this.use(new MonitorPlugin());
  }

  // 快捷GET请求
  get<T>(url: string, options?: Partial<RequestConfig>): Promise<Response<T>> {
    return this.request<T>({ method: 'GET', url, ...options });
  }

  // 快捷POST请求
  post<T>(url: string, data?: unknown, options?: Partial<RequestConfig>): Promise<Response<T>> {
    return this.request<T>({ method: 'POST', url, data, ...options });
  }

  // 快捷PUT请求
  put<T>(url: string, data?: unknown, options?: Partial<RequestConfig>): Promise<Response<T>> {
    return this.request<T>({ method: 'PUT', url, data, ...options });
  }

  // 快捷DELETE请求
  delete<T>(url: string, options?: Partial<RequestConfig>): Promise<Response<T>> {
    return this.request<T>({ method: 'DELETE', url, ...options });
  }
}

4.3 业务层（AppRequest）：业务特有逻辑定制

各业务团队基于 BaseRequest，实现自身业务特有配置与逻辑：

// ==================== 业务工具方法 ====================
// 模拟获取用户认证Token
const getToken = async (): Promise<string> => 'user-authorization-token';

// ==================== 业务专属插件 ====================
// 认证插件：请求头自动携带Token
class AuthPlugin implements Plugin {
  async beforeRequest(config: RequestConfig): Promise<RequestConfig> {
    const token = await getToken();
    // 不覆盖原有请求头
    config.headers = { ...config.headers, Authorization: `Bearer ${token}` };
    return config;
  }
}

// 业务数据类型定义
interface UserInfo {
  id: string;
  name: string;
}

// ==================== 应用请求类：业务定制入口 ====================
export class AppRequest extends BaseRequest {
  constructor(options: Partial<RequestConfig> = {}) {
    // 注入业务基础地址，合并自定义配置
    super({ baseURL: import.meta.env.VITE_API_BASE_URL, ...options });
    // 注册业务专属认证插件
    this.use(new AuthPlugin());
  }

  // 封装业务接口：获取用户信息
  getUserInfo(userId: string): Promise<Response<UserInfo>> {
    return this.get<UserInfo>(`/user/${userId}`);
  }
}

// 工厂函数：简化实例创建
export const createRequest = (config?: Partial<RequestConfig>): AppRequest => new AppRequest(config);

4.4 统一请求中心（RequestCenter）：解耦子应用与实现

为支持子应用跨 Portal 无缝复用，提供统一注册与获取机制：

// ==================== 请求中心：全局单例管理 ====================
class RequestCenter {
  // 实例缓存池 + 工厂函数缓存池
  private static readonly instanceMap = new Map<string, HttpRequest>();
  private static readonly factoryMap = new Map<string, (config?: unknown) => HttpRequest>();

  // 注册请求实例工厂
  static register(key: string, factory: (config?: unknown) => HttpRequest): void {
    this.factoryMap.set(key, factory);
  }

  /**
   * 获取单例请求实例
   * @param key 实例唯一标识
   * @param config 自定义配置
   */
  static get<T extends HttpRequest>(key: string, config?: unknown): T {
    // 双重校验锁，保证单例
    if (!this.instanceMap.has(key)) {
      const factory = this.factoryMap.get(key);
      if (!factory) throw new Error(`请求实例创建失败：未找到 key 为【${key}】的工厂函数`);
      this.instanceMap.set(key, factory(config));
    }
    return this.instanceMap.get(key) as T;
  }
}

五、插件系统设计：灵活扩展业务需求

5.1 核心价值

插件系统是请求框架的扩展核心，遵循开闭原则，实现核心代码与业务功能的彻底解耦：

• 可插拔：插件支持独立开发、注册与卸载，按需加载不冗余
• 高扩展：无侵入式扩展功能，无需修改核心层代码
• 易维护：通用能力模块化拆分，降低代码维护成本

5.2 插件上下文

插件的全局共享容器，为所有插件提供统一的资源与通信能力：

• 共享全局配置、状态数据
• 支持插件间事件通信、日志输出

5.3 插件分类

覆盖主流业务场景，支持内置通用插件 + 自定义业务插件：

• 通用插件：认证、缓存、请求重试、监控上报
• 自定义插件：适配业务专属的扩展需求

5.4 生命周期流程

插件严格遵循标准化流程执行，贯穿请求全生命周期：
成功
失败
install 初始化
beforeRequest 请求前置
发起网络请求
请求结果
afterRequest 响应处理
onError 异常处理
uninstall 资源销毁

1. 初始化：插件全局初始化，仅执行一次
2. 请求前置：处理请求头、参数等信息
3. 响应/异常处理：针对请求结果执行对应逻辑
4. 资源销毁：插件卸载时清理占用资源

六、请求流程与扩展机制：从调用到响应的全链路管理

6.1 完整请求流程：子应用到 HTTP 客户端的串联

HTTP客户端 PluginCenter HttpRequest AppRequest RequestCenter 子应用 HTTP客户端 PluginCenter HttpRequest AppRequest RequestCenter 子应用 getInstance('team-a') 创建业务请求实例 继承核心能力 request(config) 调用核心请求方法 executeBeforeRequest(config) 处理后的config 发起HTTP请求 响应数据 executeAfterRequest(response) 处理后的response 返回最终响应 返回业务数据

6.2 错误处理流程：智能重试与错误上报

成功
失败
否
是
是
否
请求发起
请求执行
响应处理
成功回调
返回数据
错误分类
可重试错误?
错误上报
错误回调
返回错误
重试机制
重试次数达限?
延迟重试

6.3 缓存策略：多级缓存提升性能

缓存策略
缓存层次
缓存场景
GET请求缓存
静态资源缓存
用户信息缓存
内存缓存
本地存储缓存
HTTP缓存
LRU淘汰
TTL过期
手动清理

6.4 监控体系：全链路可观测性

分析层
上报层
采集层
监控指标
请求耗时
成功率
并发数
错误率
MonitorPlugin
性能探针
错误捕获
批量上报
实时上报
异常上报
性能分析
错误分析
趋势分析

七、实施方案：渐进式落地，降低迁移风险

7.1 实施阶段规划

阶段	核心内容	目标
核心层建设	开发 @spc-fe-common/request-core，实现插件系统、拦截器、类型定义	完成核心能力交付，通过单元测试验证
试点迁移	选择业务团队创建业务 request 包，在子应用中验证	验证架构可行性，实现跨 Portal 无缝复用
全面推广	所有业务团队完成迁移，建立开发规范	实现全团队统一请求能力
生态建设	搭建插件市场、监控平台，完善文档培训	构建可持续生态，支撑长期迭代

八、迁移指南：无痛过渡，兼容现有业务

8.1 渐进式迁移策略：灰度发布，逐步切换

采用灰度发布策略，降低迁移风险，支持新旧系统并行：

import { featureToggle } from '@spc-fe-common/feature-toggle';
import { createRequest } from './new-request';
import { oldRequest } from './legacy-request';

// 特性开关唯一标识
const FEATURE_FLAG_KEY = 'use-new-request';

/**
 * 动态请求实例：灰度切换新/旧请求框架
 * 开关状态由配置中心统一管控
 */
export const request = featureToggle(FEATURE_FLAG_KEY, createRequest, oldRequest);

8.2 兼容性保证：零代码修改迁移

通过兼容适配层 实现新旧请求架构无缝对接，业务代码完全无需修改，保障平滑迁移：
原有业务API调用
兼容适配层
API签名兼容
行为逻辑兼容
TS类型兼容
新请求核心

兼容性类型	保障方案	验证标准
API 兼容	保留原有方法名、入参格式，无破坏性变更	自动化测试全覆盖调用链路
行为兼容	对齐旧版响应格式、错误捕获、配置规则	集成测试验证功能一致性
类型兼容	兼容原有 TS 类型定义，提供类型映射	TS 编译校验 + 静态类型测试

九、收益分析：从技术到业务的全面提升

9.1 技术收益

领域	具体收益	预期效果
代码复用	核心逻辑统一实现，消除重复开发	代码复用率提升 ≥ 80%
维护成本	仅需维护业务层逻辑，核心层统一维护	维护人力减少 ≥ 50%
开发效率	插件化扩展新功能，无需重复造轮子	新需求开发效率显著提升
协作效率	统一接口规范，知识共享更高效	跨团队沟通成本大幅降低

9.2 业务收益

领域	具体收益	业务价值
复用能力	子应用跨 Portal 无缝迁移，零代码修改	微前端架构落地，业务迭代加速
稳定性	核心层经过充分测试，质量可控	线上请求错误率显著下降
可观测性	统一监控与告警，问题排查更高效	问题排查时间大幅缩短
迭代速度	新功能全团队复用，快速上线	业务交付效率持续提升

9.3 长期价值

• 技术债务清零：消除多版本 request 维护成本，架构更健康
• 知识沉淀：优秀实践通过插件与规范沉淀，团队技术能力提升
• 架构演进：为微前端、Serverless 等未来架构提供基础能力

十、风险与对策：提前规避，保障落地

风险类别	风险描述	影响程度	对策
技术风险	核心层 API 设计不合理，导致业务接入困难	高	充分调研现有业务场景，小范围试点验证，迭代优化 API
性能风险	插件链与拦截器引入额外性能开销	中	性能测试优化关键路径，支持插件懒加载与按需执行
组织风险	业务团队迁移意愿低，不愿放弃现有实现	中	试点展示收益，提供迁移工具与培训
维护风险	版本管理混乱，breaking change 影响业务	低	严格 SemVer 规范，自动化测试与发布流程

十一、职责分工：清晰协作，高效推进

11.1 组织架构

架构组
核心层维护组
各业务团队
API 设计
核心功能开发
文档维护
业务团队 A
业务团队 B
业务团队 C
业务团队 D

11.2 职责明细

角色	核心职责	具体工作
架构组	整体技术规划与协调	制定技术规范、评审重大变更、跨团队协调
核心层维护组	核心包开发与维护	API 设计、核心功能开发、文档编写、技术支持
业务团队	业务包开发与实践	业务 request 包开发、插件贡献、问题反馈、内部推广

十二、总结：打造支撑微前端的统一请求基础设施

本方案通过「核心层 + 适配层 + 业务层」的三层架构，彻底解决了大型前端项目中多团队请求封装乱象与跨 Portal 复用困难的核心痛点：

• 统一性：核心能力标准化，消除重复开发与实现差异
• 灵活性：插件化扩展与业务层定制，满足不同团队需求
• 可维护性：清晰的职责分工，降低长期维护成本
• 可观测性：完善的监控体系，提升问题排查效率
• 复用性：统一注册机制，实现子应用跨 Portal 无缝迁移

最终，这套方案将成为支撑微前端架构的关键基础设施，为业务快速迭代保驾护航。