前端如何携带Authorization Header实现带鉴权的文件下载

你遇到的是浏览器原生行为限制，不是代码bug：所有由浏览器自动发起的原生资源请求（包括<img>标签加载src、<a>标签触发跳转/下载、window.open打开地址），都不支持手动添加Authorization这类自定义请求头，没有任何前端API可以绕过这个限制。

不需要修改你现有的Bearer Token认证体系，也不需要改用Cookie认证，更不需要用fetch转blob牺牲原生下载进度条，只需要补充轻量的临时签名逻辑即可：

1. 后端新增一个临时签名签发接口，该接口沿用你现有的Authorization头校验逻辑，校验用户身份合法后，返回对应资源的短期有效签名串：签名绑定用户ID、绑定目标资源路径、设置极短有效期（比如3-5分钟，避免被盗用）
2. 调整现有两个资源下载/图片接口的校验规则：优先检查请求头里的Authorization，走原有认证逻辑；如果请求头不存在，就校验URL查询参数里的签名是否合法、是否过期、是否匹配当前请求资源，校验通过就正常返回文件流
3. 前端在对应场景下先获取签名，拼接成带签名参数的资源URL再触发原生加载/下载即可。

各场景具体实现逻辑 #

• 个人照片加载：页面初始化时先调用签名接口获取照片的临时签名URL，再将URL赋值给img标签的src属性，浏览器原生加载图片时会自动发起请求，签名校验通过即可正常显示
• a标签直接下载：页面渲染a标签时提前请求对应简历的签名URL，赋值给a标签的href属性，用户点击后直接触发浏览器原生下载流程，保留原生下载进度条
• 按钮触发window.open下载：用户点击按钮时，先调用签名接口拿到简历的临时签名URL，再执行window.open(签名后的URL)即可，同样走原生下载逻辑。

Bearer Token普及度高于Cookie，核心是适配现代前后端分离、多端调用的架构需求：

• Cookie会自动随同域请求携带，天然存在CSRF攻击风险，Bearer Token需要前端手动附加，天然规避这类风险
• Cookie受严格的同源策略限制，跨域场景下的配置、传递逻辑非常繁琐，Bearer Token可以灵活在任意跨域请求、多端（Web/移动端/桌面端）请求中手动携带，适配场景更广
• 你遇到的原生请求无法带自定义头的问题，是浏览器层面的规则限制，并非Bearer Token本身的设计缺陷，用上述临时签名方案就可以绕开这个限制，不需要全量切换认证方式。

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