我之前踩过几乎一模一样的坑！iOS上的Chrome和Firefox这种两次请求的情况，本质是它们的预加载/预检机制——在用户点击下载提示之前，浏览器会悄悄发起一次请求，去获取文件的大小、类型这些元数据，方便后续给用户展示下载相关的提示；等用户确认下载后，才会发起真正的第二次下载请求。而Safari没有这个额外的预检步骤，所以只会发一次请求，自然不会触发认证问题。

针对这个问题，我整理了几个实测有效的解决方案：

• 识别预检请求，调整认证逻辑
  先仔细分析两次请求的差异：通常第一次预检请求会带有Range: bytes=0-0这样的头，目的只是获取响应头信息，而不是真正下载文件。你可以在服务端添加判断逻辑：如果检测到这类仅请求元数据的请求，只要请求携带了有效的认证凭证（比如token、cookie），就允许返回文件的响应头（比如Content-Length、Content-Type），但不返回完整的文件内容；等第二次真正的下载请求过来时，再执行完整的权限校验并返回文件。

• 优化Content-Disposition响应头
  有些第三方浏览器在处理attachment类型的下载时会触发预请求。你可以尝试临时把Content-Disposition设置为inline; filename="your-file-name.ext"，看看是否能避免两次请求（不过这会让文件直接在浏览器打开而非触发下载弹窗，适合用来验证问题根源）。如果有效，再考虑结合其他方式，比如前端通过JS触发下载来配合服务端的头设置。

• 缓存认证状态，用临时令牌简化二次验证
  当第一次请求通过认证后，服务端生成一个短期有效的临时令牌（比如5分钟内有效），并将这个令牌放在响应头（比如X-Download-Token）里返回。前端在收到第一次响应后，把这个令牌存起来；等第二次请求发起时，携带这个令牌到服务端。服务端只要验证令牌有效，就直接放行下载请求，不需要重复走完整的认证流程，这样既不会破坏认证机制，也能提升二次请求的效率。

• 前端侧添加自定义确认交互
  如果你的下载是通过前端按钮触发的，可以先弹出一个自定义的确认弹窗，等用户点击确认后再发起下载请求。有些第三方浏览器是自动检测到页面中的下载链接就触发预请求，通过自定义交互延迟发起请求，能绕过这个预加载行为，让浏览器只发起一次真正的下载请求。

另外，你提到第一次请求返回全部字节后被丢弃，这说明服务端没识别出预检请求就直接返回了完整内容。建议在服务端判断Range头，如果是bytes=0-0，就只返回文件的第一个字节和完整响应头，这样既满足浏览器的预检需求，又不会浪费带宽。

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