Angular 18 中 HttpClientModule 的替代方案

问题概述

在 Angular 18 中，官方已将 HttpClientModule 标记为弃用状态。当从 Angular 17 升级后，开发者会遇到以下典型场景：

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule, // 此处显示弃用警告
    ...
  ],
  // ...
})
export class AppModule {}

这导致两个关键疑问：

1. 为什么 HttpClientModule 被弃用？
2. 应该如何正确替代该模块以实现 HTTP 请求功能？

解决方案

核心替代方案：provideHttpClient()

官方推荐使用函数形式的 provideHttpClient() 取代旧模块。两种主要应用场景及配置方法如下：

1. 基于 NgModule 的应用

@NgModule({
  imports: [BrowserModule], // 移除 HttpClientModule
  declarations: [AppComponent],
  providers: [provideHttpClient()], // 在此处添加提供者
  bootstrap: [AppComponent]
})
export class AppModule {}

2. 基于独立组件的应用 (Standalone)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideHttpClient(), // 在配置中添加
  ],
};

// main.ts
bootstrapApplication(AppComponent, appConfig);

为何进行此变更？

• 简化架构：HttpClientModule 内部仅封装了 provideHttpClient(withInterceptorsFromDi())，造成冗余
• 消除常见陷阱：避免开发者在模块和提供者中重复声明 HTTP 客户端
• 统一 API：使基于模块和独立组件的应用使用相同的配置方式

进阶配置选项

通过链式方法扩展 HTTP 客户端功能：

启用 Fetch API

provideHttpClient(
  withFetch() // 启用现代 Fetch API 替代传统 XHR
)

添加拦截器

// auth.interceptor.ts
import { HttpInterceptorFn } from '@angular/common/http';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const authReq = req.clone({
    setHeaders: {
      Authorization: `Bearer ${sessionStorage.getItem('JWT')}`
    }
  });
  return next(authReq);
};

// 配置中启用拦截器
provideHttpClient(
  withInterceptors([authInterceptor]) // 传入拦截器数组
)

常见错误处理

若遇到以下类型错误：

Type 'EnvironmentProviders' is not assignable to type 'Provider'

通常因在组件层级错误导入 HttpClientModule 引起。解决方式：完全移除组件中的导入语句。

迁移步骤

1. 从所有 @NgModule 的 imports 数组中移除 HttpClientModule
2. 在模块的 providers 或应用配置中添加 provideHttpClient()
3. 删除任何组件内的 HttpClientModule 引用
4. （可选）通过 withFetch() 或 withInterceptors() 启用高级功能

变更原因解析

Angular 团队旨在简化 HTTP 客户端的配置流程：

• HttpClientModule 仅作为包装器存在（源码示例）
• 避免新开发者常见的配置冲突问题
• 为独立组件和模块应用提供统一的配置接口

此变更使 HTTP 配置更符合现代 Angular 的轻量化和函数式设计理念，同时保持功能完整性。

官方文档参考：Angular HTTP 服务配置指南