.NET Core 3.1 Lambda Web API返回JS客户端的响应与预期不符问题

问题诱因 #

• 核心原因是ASP.NET Core与.NET Framework Web API对控制器返回值的处理逻辑存在兼容性差异：.NET Framework Web API会直接将HttpResponseMessage类型的返回值作为原始HTTP响应输出，但ASP.NET Core默认将所有控制器返回值视为业务数据对象，自动执行JSON序列化后返回，你代码中构造的HttpResponseMessage实例本身被序列化为JSON结构，因此响应头的Content-Type变为application/json，你手动配置的媒体类型、文件流、响应头均未生效，该行为和你观察到的控制台日志输出完全吻合。
• curl请求表现正常通常是因为请求头Accept取值与浏览器fetch请求不同，触发了ASP.NET Core的兼容格式化器逻辑，属于偶发现象，不代表代码逻辑适配了ASP.NET Core的运行规则。

解决方案 #

方案1（推荐）：使用ASP.NET Core原生文件返回逻辑 #

ASP.NET Core的ControllerBase内置了File方法，可直接构造文件响应，无需手动管理流和响应头，修改控制器代码如下即可，原有ResponseHelper类可直接废弃：

[Route("api/[controller]")]
public class GetSongController : ControllerBase
{
    public async Task<IActionResult> GetSong(string Url)
    {
        SongRequest songRequest = new SongRequest();
        songRequest.Url = Url;

        var pathInfo = await Task.Run(() => QueryLib(songRequest));
        if (pathInfo.IsError)
        {
            return BadRequest("音频文件下载失败");
        }
        var filePath = Path.Combine(pathInfo.FilePath, pathInfo.FileName);
        var fileBytes = await System.IO.File.ReadAllBytesAsync(filePath);
        // 原生File方法自动配置Content-Type、Content-Disposition等响应头
        return File(fileBytes, "audio/mpeg", pathInfo.FileName);
    }
}

方案2（临时兼容）：启用Web API兼容包 #

如果需要保留原有HttpResponseMessage相关代码，可以在项目中安装Microsoft.AspNetCore.Mvc.WebApiCompatShim NuGet包，然后在Startup的ConfigureServices方法中添加兼容配置：

services.AddControllers()
    .AddWebApiConventions();

该方案仅适合迁移过渡阶段使用，不建议长期依赖兼容包。

AWS Lambda部署注意事项 #

部署到AWS平台后需要额外配置API网关的二进制媒体类型支持，将audio/mpeg加入二进制媒体类型列表，避免API网关将音频流当作文本处理导致文件损坏。

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