ASP.NET Minimal API中Fetch与video标签请求视频的行为差异解惑

1. 浏览器对两种请求的核心处理逻辑不同 #

• fetch请求：获取完整资源
  fetch API的设计目标是获取完整的资源内容，浏览器会等待服务器返回全部数据后结束请求。所以你看到请求在300毫秒内完成，直接拿到了52MB的完整视频文件。
• 
  <video>标签是专门为媒体播放设计的，浏览器会采用边下载边播放的渐进式策略：它不需要等完整文件下载完成就能开始播放，而是根据当前播放进度，按需获取视频数据。这种设计的目的是节省带宽、缩短首帧加载时间，提升用户体验。

2. 关键机制：HTTP范围请求（Range Requests） #

浏览器加载视频时，默认会发送带有Range请求头的HTTP请求，比如Range: bytes=0-1023，表示只需要文件的前1024字节（用来获取视频元数据，比如时长、编码格式等）。

• 如果服务器支持范围请求，会返回206 Partial Content状态码，只发送客户端请求的片段数据；后续浏览器会根据播放进度，继续发送Range请求获取后续的视频片段。
• 如果服务器不支持范围请求，才会返回200 OK和完整文件——这就是你遇到的情况：你的服务器代码强制返回完整文件，浏览器只能持续接收数据，同时边接收边播放，所以请求会一直处于打开状态，直到整个文件发送完毕。

3. 你的ASP.NET Minimal API代码的问题 #

你当前的代码使用File.ReadAllBytesAsync把整个视频文件加载到内存，然后一次性返回：

app.MapGet("/video", async (HttpContext context) =>
{
    var filePath = "...";
    var binaryData = await File.ReadAllBytesAsync(filePath);
    return Results.File(binaryData, "video/mp4");
});

这种实现有两个核心问题：

• 占用大量服务器内存：52MB的文件会被完整加载到内存，高并发场景下会导致内存压力剧增。
• 不支持范围请求：不管客户端发送的Range头是什么，都会返回完整文件，迫使浏览器只能通过持续接收的方式实现渐进式播放。

4. 改进方案：让服务器支持范围请求 #

在ASP.NET Minimal API中，使用Results.PhysicalFile并开启范围处理，就能自动支持HTTP范围请求：

app.MapGet("/video", async (HttpContext context) =>
{
    var filePath = "...";
    // 开启enableRangeProcessing，自动处理客户端的Range请求
    return Results.PhysicalFile(filePath, "video/mp4", enableRangeProcessing: true);
});

修改后，浏览器的<video>标签会根据播放进度发送Range请求，服务器只返回需要的视频片段，请求会更高效，服务器内存占用也会大幅降低。

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