JavaScript通过外部URL显示图片的不同实现方式相关疑问

问题1：服务端视角两种加载方案的差异 #

你的理解完全正确，从服务端的角度看，两种方案的下发逻辑没有任何区别。
二者发起的都是标准的GET请求，只要你没有手动修改fetch的请求头，服务端收到的请求参数、响应的图片二进制内容完全一致，唯一的区别仅在浏览器端的处理逻辑：第一种方案是浏览器内核自动接管请求的发送、响应解析、图片解码渲染的全流程；第二种是你手动通过fetch拿到二进制响应后自行处理。

问题2：两种方案的适用场景与CORS差异 #

适用场景 #

• 优先选直接赋值src的场景：90%以上的普通图片展示场景都选这个方案。浏览器自带缓存、自动解码、错误降级、懒加载等原生优化，代码量最小，没有额外内存开销，性能最优。
• 优先选fetch方案的场景：你需要对图片请求做自定义控制时才用，比如：
  • 需要给图片请求加自定义鉴权头（比如Token，不方便直接拼在URL里）
  • 需要先拿到图片二进制内容做预处理：比如加水印、格式转换、校验文件哈希、或者要把图片存到本地IndexedDB做离线使用
  • 需要精确控制请求的取消、超时等逻辑

CORS问题的原因 #

你遇到的CORS差异是浏览器的策略导致的：

• 普通img标签的src加载属于跨域资源嵌入，是浏览器默认允许的场景，不受CORS策略限制（除非你主动给img标签加了crossorigin属性）
• fetch属于跨域XMLHttpRequest类请求，默认受到CORS策略限制，必须图片服务端配置了允许你的域名跨域，请求才能成功，因此第二种方案更容易遇到CORS报错。

问题3：其他图片展示方案与base64相关问题 #

其他实现方式 #

除了你提到的两种，还有常见的base64嵌入、CSS background-image设置、SVG内联嵌入、Canvas绘制展示等方案。

base64和Blob的关系 #

二者可以互相转换，但属于不同的展示方案：

• Blob是浏览器内存里存储的二进制对象，createObjectURL生成的是指向这块内存的临时链接，生命周期和当前页面绑定，页面关闭就会自动释放
• base64是把二进制数据编码成可打印的ASCII字符串，可以直接嵌入到HTML、CSS、JS代码里，不需要额外发起HTTP请求

base64展示图片示例 #

你可以直接把base64字符串赋值给img的src属性，示例代码：

// 从blob转base64的示例
fetch(imageUrl)
  .then(res => res.blob())
  .then(blob => {
    const reader = new FileReader()
    reader.onload = () => {
      // reader.result 就是完整的base64图片地址
      document.querySelector('#myImage').src = reader.result
    }
    reader.readAsDataURL(blob)
  })

静态使用的示例：

<!-- 直接嵌入1像素透明png的base64，不需要额外发请求 -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z/C/HgAGgwJ/lK3Q6wAAAABJRU5ErkJggg==" alt="占位图">

注意base64编码会比原二进制体积大1/3左右，只适合用来嵌入极小的图标，大图片用base64会大幅降低加载和解析性能。

问题4：相关学习资源推荐 #

1. 可以先看MDN文档的「图像与多媒体」板块，覆盖了图片加载、相关API使用、格式特性的全部基础内容
2. 接着学习前端性能优化相关指南里的图片优化部分，覆盖实际业务中的图片选型、加载策略、懒加载/渐进式加载等实战内容
3. 进阶可以看Chromium等浏览器官方文档里的媒体资源加载原理部分，能帮你理解底层的缓存、跨域、渲染的逻辑

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