在现代前端开发中，Angular 结合 NgRx 状态管理已成为中大型企业级应用的主流选择。然而，当 API 返回 400 Bad Request 这样的客户端错误时，许多开发者发现 catchError 操作符并未按预期工作，导致错误信息无法正确流转至 reducer 或显示给用户。本文将深入剖析这一场景中的典型陷阱，并提供一套经过验证的解决方案。

问题现象：400 错误被“吞掉”

某团队在开发一个用户注册模块时，使用 NgRx Effects 监听 registerUser action，在 effect 中调用 HTTP 服务，随后通过 catchError 捕获异常。核心代码如下：

registerUser$ = createEffect(() =>
  this.actions$.pipe(
    ofType(registerUser),
    switchMap(({ user }) =>
      this.userService.register(user).pipe(
        map(response => registerUserSuccess({ response })),
        catchError(error => registerUserFailure({ error }))
      )
    )
  )
);

按照预期，当 API 返回 400 时，catchError 应该捕获错误并发 dispatch 一个 registerUserFailure action。然而，实际调试发现：catchError 确实被触发了，但 dispatch 的 action 并未被 reducer 处理，控制台也未显示任何异常。更诡异的是，如果网络连接完全断开（500 或 0 状态），错误却能正常流转。

根源分析：HttpErrorResponse 的微妙差异

深入追查后发现，问题出在 Angular HttpClient 对 400 错误的处理方式上。当 API 返回 400 时，HttpClient 会将错误封装为 HttpErrorResponse 对象，且其 error 属性通常包含后端返回的详细错误信息（如字段验证错误）。但在某些情况下，如果后端响应体不是标准 JSON 格式，或者响应头包含 Content-Type: text/plain，Angular 会尝试将响应体解析为字符串，导致 error 属性变成一个字符串而非对象。

更关键的是，许多开发者习惯在 catchError 中直接返回 registerUserFailure({ error })，但 reducer 中只期望从 action.error 提取 message 或 status，而忽略了 error 可能是一个完整的 HttpErrorResponse 对象。当 dispatch 时，reducer 试图访问 action.error.message，但如果 error 本身是字符串，则 message 为 undefined，最终导致 UI 不显示任何错误提示。

此外，NgRx Effects 中的 catchError 必须返回一个 Observable，上面代码中返回的 registerUserFailure action 实际是通过 of() 包装的。但如果忘记添加 of() 操作符，或者错误处理分支返回的 Observable 没有正确终止，会导致 effect 永远处于“忙碌”状态，后续的相同 action 不会再次触发。

解决方案：规范化错误处理流程

要彻底解决 400 错误不被正确捕获的问题，建议采取以下三层防护策略。

1. 统一错误格式化层

在 service 层增加一个错误格式化函数，将 HttpErrorResponse 转换为应用可理解的统一结构：

private handleError(error: HttpErrorResponse): Observable<never> {
  let errorMessage = '未知错误';
  if (error.error instanceof ErrorEvent) {
    // 客户端错误
    errorMessage = `客户端错误: ${error.error.message}`;
  } else {
    // 服务端错误
    errorMessage = `服务器错误(${error.status}): ${error.error?.message || error.statusText}`;
  }
  // 打印完整错误便于调试
  console.error('API 错误详情:', error);
  return throwError(() => ({
    status: error.status,
    message: errorMessage,
    details: error.error
  }));
}

然后在 HTTP 调用中使用该函数：

register(user: User): Observable<UserResponse> {
  return this.http.post<UserResponse>(this.apiUrl, user).pipe(
    catchError(this.handleError)
  );
}

2. Effect 中显式处理错误

更新 effect，确保 catchError 返回的 Observable 能正确 dispatch action：

registerUser$ = createEffect(() =>
  this.actions$.pipe(
    ofType(registerUser),
    switchMap(({ user }) =>
      this.userService.register(user).pipe(
        map(response => registerUserSuccess({ response })),
        catchError((formattedError) => 
          of(registerUserFailure({ error: formattedError }))
        )
      )
    )
  )
);

关键点是使用 of() 包装返回的 action，并确保 catchError 不提前终止。

3. Reducer 防御性取值

在 reducer 中处理 registerUserFailure 时，使用可选链或默认值：

const initialState: AuthState = {
  user: null,
  error: null
};

const authReducer = createReducer(
  initialState,
  on(registerUserFailure, (state, { error }) => ({
    ...state,
    error: {
      status: error?.status || 0,
      message: error?.message || '请求失败'
    }
  }))
);

进阶建议：全局 HTTP 拦截器

对于大型项目，建议在 Angular 模块中配置全局 HTTP 错误拦截器，统一处理所有 400、500 等错误，并将格式化后的错误派发到全局错误状态。这可以避免每个 effect 重复编写 catchError 逻辑：

@Injectable()
export class HttpErrorInterceptor implements HttpInterceptor {
  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    return next.handle(req).pipe(
      catchError((error: HttpErrorResponse) => {
        // 格式化并 dispatch 全局错误 action
        this.store.dispatch(showGlobalError({ 
          message: error.status === 400 ? '输入数据有误' : '服务器繁忙' 
        }));
        return throwError(() => error);
      })
    );
  }
}

总结

NgRx 中处理 400 错误的陷阱主要源于对 HttpErrorResponse 结构理解不足，以及 catchError 返回 Observable 的语法细节。通过统一错误格式化、确保 effect 返回正确的 Observable、以及 reducer 的防御性处理，可以完美解决这一问题。同时，全局拦截器能将错误处理提升到架构层面，显著提高代码可维护性。

当下一次你的 API 返回 400 错误但 NgRx 毫无反应时，不妨先检查：你的 catchError 是否真的返回了一个 Observable？你的 reducer 是否正确解析了错误对象？只要遵循上述规范，Bad Request 将不再成为前端开发者的噩梦。