使用Google Drive缩略图作为<img>标签src时出现429请求过多错误

原因分析 #

Google Drive的https://drive.google.com/thumbnail?id={photo.Id}&sz=w1000是重定向链接，而非直接的图片资源地址：

• 浏览器直接访问时，会完成两次跳转（先到中间URL，再到最终图片URL），且携带浏览器会话信息，不易触发限流。
• 但<img>标签的请求是无状态的嵌入式请求，Google服务器会将这类请求识别为非用户主动访问，更容易触发429限流，且触发逻辑依赖内部阈值，所以表现得随机无规律。

可行解决方案 #

1. 改用Google Drive永久直链（推荐） #

上传图片并设为公开后，放弃缩略图链接，直接构造永久直链：

• 基础格式：https://drive.google.com/uc?export=view&id={photo.Id}
• 指定尺寸：https://drive.google.com/uc?export=view&id={photo.Id}&w=1000
  这个链接直接指向图片资源，无重定向，能避开嵌入式请求的限流规则。

2. 后端缓存缩略图资源 #

利用你的ASP.NET API，在后端提前获取并缓存Google Drive的缩略图，前端直接访问自己服务器的资源：

• 操作步骤：
  1. 上传图片到Drive后，在API中请求缩略图链接，获取图片二进制内容。
  2. 将图片保存到本地存储、云存储或内存缓存。
  3. 向前端返回自有服务器的图片访问URL，用该URL作为img的src。
• 优势：彻底绕过Google限流，还能自主控制图片缓存策略。

3. 修改img标签属性 #

调整img标签的请求属性，让请求更接近浏览器直接访问的行为：

<img src="https://drive.google.com/thumbnail?id={photo.Id}&sz=w1000" referrerpolicy="no-referrer-when-downgrade" crossorigin="anonymous">

该方法无法完全避免限流，但能降低触发概率，因为优化了请求头属性，减少被识别为批量嵌入式请求的可能。

4. 前端添加重试逻辑 #

如果不想改动现有链接结构，可给img标签加加载失败重试机制：

document.querySelectorAll('img.drive-thumbnail').forEach(img => {
  img.addEventListener('error', function() {
    if (this.src.includes('drive.google.com/thumbnail')) {
      setTimeout(() => {
        this.src = this.src; // 延迟重新加载
      }, 1500);
    }
  });
});

这是被动应对方案，适合临时解决问题，但无法从根源避免限流。

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