Angular拦截器PUT/DELETE请求问题：成功提示无法触发

问题分析 #

从你提供的代码来看，PUT/DELETE请求无法触发提示框主要有几个核心原因：

1. 状态码匹配局限：多数RESTful后端处理PUT/DELETE成功后会返回204 No Content而非200 OK，原代码只判断status === 200会漏掉这类合法响应。
2. 操作符使用不当：用map处理提示框这类副作用不合适，map的核心作用是转换响应数据，若处理逻辑中意外返回undefined会破坏响应流。
3. URL匹配逻辑僵化：AlertUrls.includes(req.url)要求URL完全匹配，但实际PUT/DELETE请求往往带路径参数（如/api/users/123），和AlertUrls中的基准路径无法完全匹配。

修复后的拦截器代码 #

import { AlertUrls } from "../ApiUrl";

return next.handle(req).pipe(
  tap((event: HttpEvent<any>) => {
    // 仅处理成功的响应事件
    if (event instanceof HttpResponse) {
      // 灵活匹配目标URL：判断请求URL是否包含AlertUrls中的任意路径
      const isTargetUrl = AlertUrls.some(targetUrl => req.url.includes(targetUrl));
      // 排除GET请求，同时兼容200和204状态码
      if (isTargetUrl && req.method !== 'GET' && (event.status === 200 || event.status === 204)) {
        this.alertService.showSuccessAlert();
        // 可临时加日志调试：console.log('触发提示框', req.method, req.url);
      }
    }
  })
);

关键修改说明 #

• 替换map为tap：tap专门用于执行日志、提示这类不修改响应流的副作用操作，避免破坏原始响应数据。
• 扩展状态码范围：加入204状态码，覆盖PUT/DELETE请求的标准成功响应场景。
• 优化URL匹配：用some+includes替代严格匹配，适配带参数的动态URL。

额外排查点 #

1. 检查浏览器Network面板，确认PUT/DELETE请求的响应状态码是否为200或204。
2. 核对AlertUrls中的路径是否和实际请求URL的基准路径一致（注意大小写、是否带前缀）。
3. 临时添加console.log，确认拦截器是否进入了触发提示框的分支。

内容的提问来源于stack exchange，提问作者Kadir Ersezer