Soybean Admin 项目中非JSON响应处理的优化实践

问题背景

在Web开发中，前后端分离架构下，前端通常期望后端接口返回JSON格式的数据。然而实际业务场景中，后端有时需要返回非JSON格式的响应，例如文件流、纯文本或HTML内容等。Soybean Admin项目在1.0.5版本中就遇到了这样的问题：当后端返回文件流等非JSON格式响应时，前端接口处理会出现异常。

问题分析

问题的根源在于前端请求拦截器中对响应数据的默认处理方式。许多前端框架和库会默认假设所有HTTP响应都是JSON格式，并自动进行JSON解析。当实际响应是二进制文件流或其他非JSON格式时，这种自动解析就会抛出异常，导致整个请求处理流程中断。

在Soybean Admin项目中，这个问题表现为：

1. 当请求文件下载等返回非JSON数据的接口时
2. 前端拦截器尝试将响应数据解析为JSON
3. 解析失败导致接口报错
4. 用户无法正常获取文件流

解决方案

针对这个问题，Soybean Admin项目团队采用了以下解决方案：

1. 响应类型检查：在请求拦截器中增加对响应数据类型的判断，识别非JSON格式的响应
2. 差异化处理：对于JSON响应继续原有处理流程，对于非JSON响应保留原始数据
3. 错误处理优化：完善错误捕获机制，避免因数据格式问题导致整个应用崩溃

实现细节

在实际代码实现中，主要修改了请求拦截器的逻辑：

// 伪代码示例
axios.interceptors.response.use(response => {
  try {
    // 尝试解析JSON
    const data = JSON.parse(response.data)
    return { ...response, data }
  } catch (e) {
    // 非JSON数据保持原样返回
    return response
  }
})

这种实现方式确保了：

• JSON数据能够被正确解析为JavaScript对象
• 非JSON数据（如文件流）能够保持原样传递
• 不会因为格式问题抛出未捕获的异常

最佳实践建议

基于这个问题的解决，我们可以总结出一些前端处理HTTP响应的最佳实践：

1. 不要假设所有响应都是JSON：即使项目中大部分接口返回JSON，也要为特殊场景预留处理空间
2. 完善的错误处理：对响应数据的解析操作应该放在try-catch块中
3. 明确响应类型：后端API应该通过Content-Type头部明确声明响应数据类型
4. 前端类型检查：前端应该根据Content-Type决定如何处理响应体
5. 统一错误反馈：对于确实无法处理的响应，提供统一的错误反馈机制

总结

Soybean Admin项目通过优化非JSON响应的处理逻辑，增强了前端应用的健壮性和兼容性。这个案例提醒我们，在前后端分离架构中，前端不能对响应数据格式做过多假设，而应该采用更加灵活和健壮的处理方式。这种优化不仅解决了文件下载等特定场景的问题，也为将来可能出现的其他非JSON响应场景打下了良好的基础。