.NET Core FileStreamResult绑定img src移动端不显示问题排查

桌面端浏览器和移动端浏览器对图片响应的容错逻辑存在差异，你的代码存在三个影响移动端兼容的问题：

• 从GetImageAsMemoryStream获取的MemoryStream在写入完成后，流指针默认停留在流的末尾位置。桌面端浏览器请求图片时，框架和浏览器的容错逻辑会自动重置流位置再读取内容，但移动端WebKit内核（iOS Safari、iPadOS Safari、安卓系统WebView）不会做这层自动处理，实际读取到的流内容长度为0，无法渲染图片。
• 直接传入MemoryStream调用File()方法返回结果时，ASP.NET Core默认会使用分块传输编码（Transfer-Encoding: chunked），不会在响应头里附加明确的Content-Length字段。移动端Web核对二进制图片资源的解析要求更严格，没有明确Content-Length的分块图片响应会被直接判定为无效资源终止加载，桌面端浏览器支持分块传输的图片解析，所以可以正常显示。
• 部分旧版移动端浏览器会校验图片资源URL的后缀，你当前接口路由没有.jpg后缀，会被部分浏览器识别为普通二进制文件而非图片资源，直接拦截加载。

调整接口代码，显式处理流位置、设置响应头、补充文件名即可实现全设备兼容，修正后的代码如下：

public ActionResult DrawSummaryImage(int id, int pageNumber = 1)
{
    var ms = GetImageAsMemoryStream(id, pageNumber);
    // 重置流指针到起始位置，保证可以读取到完整流内容
    ms.Seek(0, SeekOrigin.Begin);
    // 显式设置Content-Length响应头，关闭分块传输
    Response.ContentLength = ms.Length;
    // 传入带.jpg后缀的文件名，兼容旧版移动端浏览器的后缀校验
    return File(ms, MediaTypeNames.Image.Jpeg, $"draw_summary_{id}_{pageNumber}.jpg");
}

如果你的服务前面挂了Nginx、IIS等反向代理，需要额外检查代理配置，不要手动移除图片响应的Content-Length头，也不要强制对图片接口开启分块传输。
修复后可以通过浏览器开发者工具的移动端模拟模式验证：查看接口响应头存在正确的Content-Length值，响应内容长度和流长度一致，JPEG文件的起始标识（0xFF 0xD8）存在即可。

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