为何子资源完整性（Subresource Integrity）需要跨源资源共享（CORS）？

关键逻辑：SRI验证需要读取资源内容，跨域读取默认被同源策略限制 #

你遇到的问题核心在于子资源完整性（SRI）的验证机制：当你给<script>加上integrity属性时，浏览器必须读取整个脚本的内容，计算哈希值后和你提供的integrity字符串对比，确认资源没被篡改。

但浏览器的同源策略默认禁止跨域读取资源内容——这是为了防止恶意站点窃取第三方资源里的敏感信息。不过，普通加载跨域脚本时，浏览器只是执行脚本，不会去读取脚本的文本内容，所以不需要任何CORS许可，这就是不带integrity的脚本能正常加载的原因。

为什么必须要服务器许可？ #

要完成SRI验证，浏览器就得打破同源策略的限制去读取资源内容，这时候就需要资源服务器通过CORS响应头（比如Access-Control-Allow-Origin）明确授权：允许你的站点读取这个资源的内容。如果服务器没返回这个头，浏览器就会直接阻断加载，避免潜在的安全风险。

谷歌这边的特殊情况 #

谷歌的reCAPTCHA脚本是动态生成的——不同请求返回的脚本内容可能不一样（比如适配不同地区语言、设备类型，或者包含会话相关的动态参数）。你指定的固定integrity哈希值根本不可能匹配所有动态生成的内容，所以谷歌干脆不允许站点对这个脚本做SRI验证，自然也不会返回对应的CORS授权头。

说白了：SRI验证需要读资源内容，跨域读内容必须服务器点头；而谷歌的这个脚本本身就不支持固定哈希验证，所以不会给你这个权限。

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