Angular Mock拦截器返回Blob后如何转换为可用JSON结果

• 拦截器统一将mock响应包装为Blob返回，但前端业务开发时本来需要消费结构化JSON，硬套Blob类型会导致多一步冗余解析，等真实后端联调时还要反过来改业务代码。
• Blob是原始二进制数据容器，无法直接读取内部的JSON内容，必须通过内置的异步读取接口把内容转成文本后再做JSON解析，没有直接同步取值的方法。
• 组件代码中await和subscribe的搭配存在逻辑错误：subscribe返回值是用于取消订阅的Subscription对象，不是HTTP请求的结果，这种写法根本无法拿到接口返回值。
• mock响应构造时存在冗余的双重字符串化：handleCasesRequest里把数组对象先JSON.stringify后嵌到output字段，再在拦截器里对整个body做一次JSON.stringify，最终Blob里的内容是两层转义的字符串，直接解析会拿到带多余转义的无效数据。

方案1：调整拦截器逻辑对齐真实HTTP请求行为（推荐） #

这种方案不需要修改任何业务侧的请求逻辑，等后端接口开发完成后，前端代码可以无缝切换到真实接口，不需要额外删除Blob解析的临时代码。
具体修改点：

1. 修改拦截器的getResponse方法，不再强制把mock body转成Blob，直接将原始结构化对象作为HttpResponse的body返回，和真实后端返回JSON的行为完全对齐：

   getResponse(
     options: MockResponseOptions,
     request: HttpRequest<unknown>
   ): Observable<HttpEvent<unknown>> {
     console.log('[REQUEST after interception]', request, options);
     return of(
       new HttpResponse({
         status: options.status || 200,
         body: options.body,
         url: request.url,
       })
     ).pipe(delay(options.delay || 1000));
   }
   

2. 修正mock响应里的冗余字符串化逻辑，直接返回结构化数据，避免多层转义：

   export function handleCasesRequest(
       request: HttpRequest<unknown>
   ): MockResponseOptions {
       console.log('mock response triggered!');
       const data = [
           { item: 1 },
           { item: 2 },
           { item: 3 }
       ];
       return {
           body: data
       };
   }
   

3. 修正组件里的请求逻辑，删掉不必要的responseType: 'blob'配置，修掉async/await和subscribe混用的错误：

   private fetchData() {
     this.response = [];
     this.http.get<Array<{item: number}>>("http://localhost:4200/cases")
       .subscribe(data => {
         // 直接拿到结构化的数组对象，不需要额外解析
         this.response = data;
       })
   }
   

方案2：如果必须保留Blob格式的mock响应（需要统一模拟文件下载等Blob响应场景） #

这种场景下需要在前端拿到Blob后，通过异步读取接口把Blob内容转成可用的JSON，具体实现：

1. 利用Blob原生提供的text()方法读取内部文本内容，这个方法本身返回Promise，可以配合async/await写异步逻辑。
2. 修正组件的请求流程，将Observable转成Promise后搭配await使用，在读取完Blob文本后做JSON解析：

   private async fetchData() {
     this.response = "";
     try {
       // 发起请求拿到Blob对象，将Observable转为Promise适配await写法
       const blobResponse = await this.http
         .get("http://localhost:4200/cases", { responseType: 'blob' })
         .toPromise();
       
       // 异步读取Blob内部的文本内容
       const responseText = await blobResponse.text();
       // 将文本解析为可用的JSON对象
       const parsedResult = JSON.parse(responseText);
       this.response = parsedResult;
     } catch (err) {
       console.error('Blob响应解析失败', err);
     }
   }
   

注意：如果Blob内容经过多层字符串化，这里JSON.parse会抛出语法错误，需要对照拦截器里的构造逻辑，把多余的字符串化步骤删掉，保证Blob内部存的是合法的、单层的JSON字符串。

• 拦截器现在用url.endsWith(handlerUrl)匹配请求的逻辑容易出现误拦截（比如前端路由路径和API路径同名时），后续可以改成按固定API前缀匹配（比如所有后端请求都带/api开头，就判断请求URL是否匹配/api+handlerUrl），匹配精度更高。
• 组件里导入的handleCasesRequest没有实际使用，属于无效导入，可以删掉减少打包体积。
• 拦截器对POST请求的handler匹配逻辑没有做参数路径处理，后续如果有带动态参数的API（比如/cases/123），可以扩展匹配规则支持路径参数替换。

内容的提问来源于stack exchange，提问作者Rodney Wormsbecher