为何相同GET请求在JavaScript中被CORS拦截，HTML src却可正常加载？

这是浏览器的预期行为，核心是浏览器对不同发起方式的请求有不同的安全规则：

1. 为啥HTML <img> 能正常加载？ #

像<img>、<script>这类标签的资源请求，是浏览器自动发起的被动资源加载，属于同源策略的例外情况——允许跨域加载资源，但会限制JavaScript代码读取返回的内容。简单说就是浏览器能把图片渲染出来，但你没法用JS去拿图片的二进制数据或响应头，这是一种安全妥协：既让网站能引用外部资源，又防恶意脚本偷敏感内容。

2. 为啥JS fetch 会被CORS拦？ #

fetch、XMLHttpRequest这类由JS主动发起的请求，属于主动数据请求，完全受同源策略严格限制。只有目标服务器返回合法的CORS响应头（比如Access-Control-Allow-Origin），浏览器才允许JS读取响应内容。哪怕都是GET请求、响应头看起来和<img>的一样，只要服务器没明确授权跨域读取，浏览器就会拦截。

3. 这个行为的安全意义 #

• 防跨域数据窃取：要是允许JS随便读跨域资源，恶意网站就能通过脚本加载用户在其他网站的私密资源（比如带身份凭证的图片、文档），进而偷用户信息。
• 划清资源访问的权限边界：服务器可以通过CORS头精确控制哪些网站能主动读自己的资源，而被动加载的资源是“公开可嵌入”的，两者权限边界清晰。

4. 怎么绕过限制获取简单请求？ #

如果你的需求是要拿到图片的二进制数据（比如做本地缓存、处理），可以试试这些方法：

• 用<img>加Canvas（仅限服务器允许跨域读取的情况）：如果服务器开了CORS（返回Access-Control-Allow-Origin），可以先把图片加载到<img>，再通过Canvas转成Blob或Base64。但如果服务器没开CORS，这种方法会触发Canvas“污染”，没法读取数据。
• 搭后端代理：在自己的服务器上做个代理接口，由后端去请求目标图片，再把响应返回给前端。后端请求不受浏览器同源策略限制，前端只需要请求自己的代理接口就行。
• 检查目标资源是否支持CORS：有些CDN或资源服务器会对图片开放CORS权限，你可以在fetch时加mode: 'cors'，如果服务器返回合法的CORS头，就能正常读取响应。

内容的提问来源于stack exchange，提问作者s.demuro