配置通配CORS的GCS公共存储桶使用fetch请求仍触发跨域报错

• 当前CORS配置缺少GCS必填的声明字段
  和DO Spaces会自动隐式补全CORS响应头的逻辑不同，GCS不会自动为符合origin、method规则的请求注入Access-Control-Allow-Origin响应头。你当前的配置仅指定了origin和method两个字段，缺少响应头声明、预检方法支持等必要配置，直接导致响应中没有携带跨域允许头。
• CORS规则未正确下发到目标存储桶
  GCS没有全局统一的CORS配置入口，所有CORS规则都是绑定到单个存储桶的。如果你仅在控制台完成了规则编辑，但没有通过gsutil命令将规则绑定到pub-bucket桶，或者误操作绑定到了其他桶，规则实际不会在pub-bucket的资源响应中生效。
• 旧响应缓存干扰测试
  GCS的边缘节点会缓存公共资源的响应头，如果你之前测试过该资源，缓存的旧响应（不带CORS头）会被优先返回，即使后续更新了CORS规则，短时间内拉取到的还是旧的缓存内容。
• 非简单GET请求触发预检失败
  如果你在fetch请求中添加了自定义请求头（如Range、Authorization或自定义X-开头的请求头），GCS会触发CORS预检（OPTIONS）请求，但你当前的规则没有允许OPTIONS方法，直接导致预检失败，最终抛出无跨域允许头的报错。

1. 调整CORS规则配置 #

先将本地CORS规则文件修改为如下完整内容：

[
  {
    "origin": ["*"],
    "method": ["GET", "HEAD", "OPTIONS"],
    "responseHeader": ["Content-Type", "Range", "If-Modified-Since"],
    "maxAgeSeconds": 3600
  }
]

说明：

• 新增HEAD、OPTIONS方法支持，覆盖资源元信息请求和CORS预检请求
• responseHeader字段显式声明允许返回的请求头，可根据你的实际fetch请求头需求增删
• maxAgeSeconds设置预检请求的缓存时间，减少不必要的预检请求

2. 将规则绑定到目标存储桶 #

执行如下命令将规则下发到pub-bucket：
gsutil cors set cors.json gs://pub-bucket
执行完成后，用gsutil cors get gs://pub-bucket验证返回的内容和你写入的配置一致，才说明绑定成功。

3. 绕过缓存验证配置 #

测试时给资源URL添加随机查询参数（如https://storage.googleapis.com/pub-bucket/v1/example.mid?t=1699999999），绕过本地浏览器和GCS边缘节点的旧缓存，再发起fetch请求即可正常获取资源。

注意事项 #

• 生产环境建议将origin字段从*替换为实际的前端访问域名（如http://localhost:3001、https://你的线上前端域名），避免安全风险。
• 如果你的fetch请求中使用了其他自定义请求头，一定要同步添加到responseHeader的允许列表中，否则响应不会携带对应头。

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