企业官网建设流程全解析

整理本地游戏库这件事，我前后折腾过好几轮。最开始那版脚本只接了元数据接口，刮出来的条目名字、发行年份、厂商都对得上，可封面位置永远是灰底占位图，列表拉下来像一份没做完的报表。后来才想明白，元数据和美术资源在生态里根本是两条管线：前者告诉你"这是什么游戏"，后者决定"这个游戏长什么样"。SteamGridDB 和 IGDB 恰好各自守着一条管线，而它们的 API 密钥配置方式、认证模型、请求风格几乎没有共同点。这篇就把两套密钥从申请到跑通、从落盘到排错的全过程摊开讲清楚，顺带聊聊高清游戏封面资源抓回来之后怎么管。不管你是刚写第一个刮削脚本，还是已经在维护一套自用的库管理工具，下面这些坑大概率都会撞上其中一个。

1. 封面刮削为什么总要配两把钥匙：先把职责边界理清

1.1 元数据与美术资源是两条独立管线

很多人第一次接触这两个服务，会下意识以为它们是竞争关系，选一个就行。实际用下来完全不是。IGDB 的核心资产是结构化元数据：游戏条目、别名、发行日期、平台归属、开发商、类型标签、评分聚合，以及一份分辨率算不上高的官方封面。它对"封面"这件事的态度是够用就好，返回的图片 URL 默认还是个缩略图尺寸，你得自己在路径里改后缀才能拿到大图。而 SteamGridDB 反过来，它不提供发行日期、不提供平台信息，专注做一件事：把社区投稿的各种比例、各种风格的封面图、宽幅背景图、透明 LOGO、图标聚合起来，供你按尺寸和标签筛选。

这种分工带来的直接结论是：一个完整的库整理流程，需要先用 IGDB 把游戏身份确认下来（拿到准确的名称、年份、平台、IGDB 条目 ID），再用这个名称或 ID 去 SteamGridDB 匹配美术资源。前者解决"匹配准不准"，后者解决"看起来爽不爽"。两套密钥缺一套，流程就断在半路。

我见过不少人卡在这里：只配了 IGDB，抓回来的封面全是官方那张竖版图，放在宽屏前端里左右两条大黑边；或者只配了 SteamGridDB，搜索靠手动输入游戏名，遇到重名、地区版、复刻版就开始乱匹配。这两种情况的根因都不是技术问题，是没想清楚两条管线的边界。

1.2 只配一把钥匙的典型后果

把后果具体化一点，方便你判断自己属于哪一类。

只配 IGDB 的话，你会遇到三个具体症状。第一，封面比例单一。官方封面基本是竖版，而大多数库管理界面同时需要竖版网格图、横版背景图、方形图标三种规格，缺的那两种只能靠拉伸裁剪，观感很差。第二，透明 LOGO 完全拿不到。没有 LOGO，界面上的游戏标题只能靠文字渲染，字体和游戏风格对不上。第三，同人精修图无缘。社区里有大量手工重制的高清封面，质量远超官方素材，只接 IGDB 就等于放弃这一整块。

只配 SteamGridDB 的话，症状集中在匹配环节。它虽然有自动补全搜索接口，但返回的是扁平的游戏名列表，遇到"某系列 2"和"某系列 2 重制版"这种命名，光看名字分不清，只能靠人工逐条确认。而 IGDB 的查询语言支持按平台、发行年份、类型做组合过滤，能把这个歧义消掉一大半。

提示：如果你的库规模在几十个条目以内，纯手工挑图完全可行，配不配 IGDB 无所谓。一旦条目上到几百，匹配准确率就成了主要矛盾，这时候 IGDB 的价值不在元数据本身，而在于它能给出一个稳定、可过滤的身份锚点。

1.3 两套认证模型的差异先打个预防针

这一步值得提前说，因为它决定了后面代码的组织方式。SteamGridDB 用的是极简的长期令牌模型：你在账号设置里生成一串密钥，之后每个请求把它塞进 Authorization 头里带上就行，没有过期时间，没有刷新流程，不需要第二次握手。IGDB 走的是标准 OAuth2 客户端凭证流程：你拿到一对 Client ID 和 Client Secret，先用它们去换一个有时效的 access_token，之后每个业务请求同时带 Client-ID 头和 Bearer token。token 到期了要重新换。

一个是"一把钥匙开到底"，一个是"用长期凭证换临时通行证"。前者接起来五分钟，后者第一次接大概要花半小时理解流程，但接完之后你会得到一个能自动续期的凭证管理模块——这个模块在长期运行的定时刮削任务里是必需品，因为 token 总会过期，而你的任务不会刚好在过期前跑完。

2. 开工前的账号与网络前置：别等到填表单才发现卡住

2.1 两套账号体系的差异

SteamGridDB 的密钥获取路径最短：注册账号，登录，进个人设置页，找到 API 相关的区块，页面上会直接显示一串已生成的密钥，旁边有个重新生成的按钮。整个过程不需要填应用名称、不需要写用途说明、不需要等待审核。这串密钥代表的是"你这个账号"，而不是"你这个应用"，所以你写的所有脚本、工具共用同一串，没法做权限隔离。

IGDB 这边流程长一些，因为它是开发者平台的一部分。你需要先有一个开发者平台账号，登录后进入开发者控制台，注册一个应用。注册表单会问应用名称、OAuth 重定向地址、应用类型。这里有个关键点：做服务端刮削脚本，应用类型选机密型（confidential），重定向地址随便填一个合法 URL 就行，因为客户端凭证流程压根不走重定向。很多人卡在这一步，反复琢磨重定向地址该填什么，其实它对你的使用场景没有任何影响。

注册完成后，控制台会展示 Client ID 和 Client Secret。注意 Secret 通常只在创建时完整显示一次，之后页面会把它遮蔽，只留一个重置入口。第一次看到就立刻存好，别指望回头再找。

2.2 申请表单里那几个容易填错的字段

我整理了一份对照表，覆盖两个平台注册和配置环节最容易出问题的字段：

表单之外还有一个隐性前置：这两套接口都在境外，请求过程对网络环境有基本要求。我不展开讲这块，只说实践层面的建议——如果你在本地测试时一直超时，先在命令行里对两个 API 域名各发一次最简单的连通性检查，确认能拿到响应再往下写代码。把网络问题和代码问题混在一起排查，是最消耗时间的做法。

2.3 环境准备清单

除了账号，本地还需要几样东西，列一下省得你来回翻：

• 一个能发 HTTP 请求的工具。命令行用 curl 就够，它能把请求头、响应状态码、响应体全部打印出来，排查阶段比任何封装库都好用。
• 一个脚本运行环境。我个人偏好 Python，因为 requests 库处理 JSON 和异常很顺手；用 Node 也行，fetch 现在原生支持，不用装依赖。
• 一个存密钥的地方。测试阶段可以先写进一个不纳入版本管理的本地文件，正式使用务必走环境变量，理由在第五节展开。
• 一个文本编辑器加一个终端。听起来像废话，但把密钥从网页复制到终端再复制到文件的过程中，很容易带上不可见字符，这会在后面引发一个非常难查的 401。

注意：注册和首次调用之间最好别隔太久。IGDB 那套流程涉及账号、应用、凭证三层，隔几天再回来容易忘记当时选的应用类型和 Secret 存哪了。

3. SteamGridDB的密钥生成：从个人设置到第一次成功请求

3.1 密钥在哪、长什么样、权限边界

登录之后进个人设置页，往下找 API 区块。页面上会展示一串长度固定、由字母数字组成的密钥，旁边是重新生成按钮。这串东西就是全部凭证，没有配套的 Secret，没有应用 ID，不需要任何额外参数。

它的权限边界也得说清楚：这串密钥代表你的账号身份，所有通过它发出的请求都会计入你账号的调用统计。如果你把这串密钥分享给别人，或者写进一个公开仓库，别人用掉你的配额你是不知情的。平台侧对调用频率有软性限制，正常刮削几百上千条完全不会触发，但如果你写了个循环没有间隔地猛打，可能会收到限流响应。

一个容易被忽略的细节：密钥页面上显示的字符可能带格式，从网页复制出来时首尾混进空格或换行是常事。我建议复制之后先放到终端里用echo打一遍，肉眼确认前后没有多余空白，再写进配置。这个动作花十秒，能省掉后面半小时的排查。

3.2 用cURL和Python各验证一次

验证顺序我习惯从最原始的工具开始，逐层往上封装。先 curl：

curl -s -H "Authorization: Bearer YOUR_SGDB_KEY" \ "https://www.steamgriddb.com/api/v2/search/autocomplete/hollow" \ -w "\nHTTP_STATUS:%{http_code}\n"

响应体应该是 JSON，顶层有success和data两个字段。success为 true，data是一个数组，每个元素至少带id和name。状态码 200。如果success是 false，说明业务层拒绝了请求，通常和密钥非法或参数缺失有关；如果状态码直接是 401，那就是认证头没拼对，重点检查Bearer后面那个空格和密钥本身。

curl 通了，再上脚本。Python 版本我一般写成一个小函数，把密钥从环境变量读进来：

import os import requests SGDB_KEY = os.environ.get("SGDB_API_KEY", "").strip() BASE = "https://www.steamgriddb.com/api/v2" def sgdb_get(path, params=None): if not SGDB_KEY: raise RuntimeError("SGDB_API_KEY 未设置") resp = requests.get( f"{BASE}{path}", headers={"Authorization": f"Bearer {SGDB_KEY}"}, params=params or {}, timeout=15, ) resp.raise_for_status() payload = resp.json() if not payload.get("success"): raise RuntimeError(f"业务层失败: {payload}") return payload["data"] if __name__ == "__main__": games = sgdb_get("/search/autocomplete/hollow") for g in games[:5]: print(g["id"], g["name"])

这段代码里有两个刻意的设计。一是raise_for_status()，它把 4xx 和 5xx 转成异常，避免你拿到一个错误页面还当成正常 JSON 去解析。二是不直接返回整个 payload 而是返回data，因为业务层的success判断应该收敛在这一层，上层调用方不需要关心。

3.3 图片尺寸参数与筛选条件

拿到游戏 ID 之后，就能请求各类美术资源了。四个主要端点对应四种资源：/grids/game/{id}拿网格封面，/heroes/game/{id}拿宽幅背景，/logos/game/{id}拿透明 LOGO，/icons/game/{id}拿方形图标。每个端点都支持一组查询参数，用得好能省掉大量后处理。

尺寸参数dimensions是最常用的。网格封面常见两种比例，竖版和横版，写法像600x900或460x215；宽幅背景常见1920x620这类超宽比例。不传的话接口返回全部尺寸，图量会翻好几倍，下载时间和磁盘占用都跟着涨。

风格参数styles用来筛图的视觉风格，比如去掉带文字标题的版本、只要纯图版本、只要带模糊处理的版本。mimes用来限定格式，image/png、image/jpeg、image/webp三选。还有一组内容过滤参数，用于排除特定标签的投稿图，做公开展示的产品建议把这几个都显式打开，别依赖默认值。

下面是四种资源端点的对照，方便你写配置时直接抄：

提示：请求列表接口时不要一次性把所有参数都加上。先用最少参数拿到全部结果，翻两条看看长什么样，再逐步加筛选条件。一上来就叠五个参数，结果为空的时候你根本判断不出是哪个条件把结果过滤没了。

4. IGDB的OAuth双钥匙：Client ID与Secret不是同一个东西

4.1 为什么IGDB要绕一道token

第一次接触 IGDB 认证的人，十个里有八个会问同一个问题：既然我手里已经有 Client ID 和 Secret 了，为什么不能直接拿它们请求数据？答案在 OAuth2 的设计意图里。Client ID 和 Secret 是"你是谁"的证明，权限极大，一旦泄露等于账号被接管；access_token 是"你被授权做什么"的临时凭证，有明确有效期，泄露的影响面可控。把长期凭证直接用于每一次业务请求，等于把最敏感的东西反复暴露在网络上。

所以流程是：用长期凭证换一张临时通行证，然后拿通行证去办事。通行证过期了再换一张。这个中间层还带来了额外好处——你可以在换 token 的阶段做集中限流和缓存，业务请求阶段就完全不用管认证细节。

需要澄清一个常见误解：IGDB 的数据查询接口地址和 token 发放接口地址不在同一个域名下。业务查询走api.igdb.com/v4/这一套，token 发放走的是 id 域名下的一套 OAuth 端点。这两个地址经常被写混，导致"我用 API 域名换 token 一直 404"这种问题。

4.2 换取access_token的完整请求与字段说明

token 请求是 POST，参数走查询字符串，不需要请求体，也不需要任何特殊请求头：

curl -s -X POST \ "https://id.twitch.tv/oauth2/token?client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=client_credentials"

返回的 JSON 里三个字段最关键：access_token是通行证本身，expires_in是有效期秒数（这个值很大，接近两个月），token_type固定是 bearer。没有 refresh_token——客户端凭证流程不发刷新令牌，过期了就用 Client ID 和 Secret 重新换一张，这也意味着你的 Secret 必须长期可用。

拿到 token 之后，业务请求要同时带两个头：

curl -s -X POST "https://api.igdb.com/v4/games" \ -H "Client-ID: YOUR_CLIENT_ID" \ -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ -H "Accept: application/json" \ -d 'fields name,first_release_date,cover.url; where name ~ *hollow*; limit 5;'

注意请求体用的不是 JSON，是这个平台自有的查询语法，字段之间用逗号分隔，子句之间用分号分隔。第一次写很容易下意识地塞一段 JSON 进去然后收到 400。查询语法里几个常用的子句：fields指定返回字段，where做过滤，search做模糊匹配（它和where的模糊匹配写法语义不同，前者按相关度排序，后者按条件筛选），limit限条数，sort排序。返回的封面 URL 默认带缩略图尺寸标识，需要手动替换成更大的尺寸标识，并且协议头是省略的，要补上。

下面这张表是我整理的高频字段和坑：

4.3 token缓存与续期的工程化写法

把换 token 的逻辑写死在主流程里是最常见的错误。正确做法是包一个带缓存的凭证管理类，逻辑是：内存里存 token 和过期时间戳，每次取 token 时先判断剩余时间，够用就直接返回，不够用才发起请求。判断阈值我一般设成剩余十分钟，留出余量应对时钟漂移。

import time import requests class IgdbAuth: def __init__(self, client_id, client_secret): self.client_id = client_id self.client_secret = client_secret self._token = None self._expire_at = 0 def token(self): if self._token and time.time() < self._expire_at - 600: return self._token resp = requests.post( "https://id.twitch.tv/oauth2/token", params={ "client_id": self.client_id, "client_secret": self.client_secret, "grant_type": "client_credentials", }, timeout=15, ) resp.raise_for_status() data = resp.json() self._token = data["access_token"] self._expire_at = time.time() + int(data.get("expires_in", 3600)) return self._token def headers(self): return { "Client-ID": self.client_id, "Authorization": f"Bearer {self.token()}", "Accept": "application/json", }

这段代码要在单进程内全局复用一个实例，别每次查询都新建。如果你的刮削任务是多进程并发的，缓存要放在进程外——写进一个临时文件或者本地缓存库都行，格式就是 token 加过期时间戳两行，简单可靠。

5. 密钥落盘的正确姿势：配置分层与环境变量

5.1 三层配置结构

密钥存放这件事，我踩过最疼的一次坑是把测试脚本连同密钥一起提交到了一个协作仓库，虽然五分钟内就删了，但那次之后我把配置结构整个重构了一遍。现在固定用三层：

第一层是代码里的默认值。只放非敏感项，比如接口基地址、超时秒数、重试次数、缓存目录。密钥类的一律留空字符串。

第二层是环境变量。本地开发用一个不纳入版本管理的 env 文件加载，部署环境用系统级或容器级环境变量注入。这是密钥唯一的真实来源。

第三层是运行时参数覆盖。命令行工具允许通过参数临时指定，主要给调试用，方便你快速切换多个账号的配额。参数优先级最高，但代码里要加一句日志提示"当前使用命令行覆盖的密钥"，免得日后忘了。

这个结构的好处在于，代码可以原样开源，部署时只需要注入环境变量，不需要改任何一行。反过来，如果你把密钥写死在代码里，每次换密钥都要改代码、重新提交、重新部署，麻烦且危险。

5.2 示例配置文件与加载逻辑

我一般写一个.env.example放仓库里当模板，内容只有占位符：

SGDB_API_KEY= IGDB_CLIENT_ID= IGDB_CLIENT_SECRET= CACHE_DIR=./cache REQUEST_INTERVAL=0.35

真正的.env放进忽略规则。加载逻辑用一段十行的函数搞定，不引第三方库：

import os from pathlib import Path def load_env(path=".env"): p = Path(path) if not p.exists(): return for line in p.read_text(encoding="utf-8").splitlines(): line = line.strip() if not line or line.startswith("#") or "=" not in line: continue k, v = line.split("=", 1) os.environ.setdefault(k.strip(), v.strip())

setdefault这个细节值得说一下：它保证已经存在的环境变量不会被文件里的值覆盖。部署环境注入了真实密钥，文件里的空值就不会生效，两者可以共存而不会打架。

REQUEST_INTERVAL这一项是留给限流的，两个平台的策略不同，用同一个间隔值偏保守但够用。IGDB 侧官方给的限制是按秒计的请求数上限，换算下来每个请求之间留零点几秒绝对是安全的；SteamGridDB 侧更宽松。统一取一个保守值，让两套请求共用同一个节流器，代码会简单很多。

5.3 三条不要做的事

第一条，不要把密钥写进前端代码。浏览器里能看到的任何东西都不是秘密，包括塞在构建产物里的常量、藏在注释里的值、base64 编码过的字符串。真要给网页端用，必须经过你自己的服务端代理转发，密钥只存在服务端。

第二条，不要把密钥拼进日志。排查问题时打印完整请求头确实方便，但日志会被收集、会被转发、会被人翻。我的做法是打印时对密钥做掩码，只保留前四位和后四位，中间替换成固定长度的星号。

第三条，不要一份密钥到处复用。SteamGridDB 那边没法给不同工具发不同密钥，这是平台限制，只能靠定期重置加人工管理；IGDB 那边可以给不同用途注册不同应用，刮削脚本一个、其它工具一个，出事时影响面可控。

注意：密钥重置是全局生效的。如果在多个工具里用了同一串 SteamGridDB 密钥，重置之后所有工具都会立刻失效，包括你以为已经部署好的那些。重置前先把引用清单列一遍。

6. 实测报错清单：401、403、429与空结果的排查链路

6.1 401和403的分水岭

这两个状态码经常被混着说，但它们的成因完全不同，排查方向也南辕北辙。401 是"身份没被承认"，403 是"身份被承认了但没权限"。前者几乎一定是请求头的问题，后者大概率是账号或配额的问题。

我自己遇到的 401 有四种，按出现频率排：密钥首尾带了空格或换行、认证头里Bearer和密钥之间少了空格、SteamGridDB 的密钥被误当成 IGDB 的 token 用、IGDB 的 token 已经过期但缓存里还留着。第四种最阴，因为你的缓存逻辑看着没问题，只是时钟或者续期阈值算错了。排查方法很土但有效：在发请求之前把请求头的值用repr()打一遍，不可见字符会立刻暴露成\n或\x20。

403 我遇到的主要是配额和权限两类。配额类的响应通常会在响应体里带说明文字，直接读响应体比猜快得多。权限类的一般是应用类型选错了，或者账号状态有问题。

排查链路我固定按这个顺序走，不跳步：

1. 用 curl 打一个已知可用的最小请求，确认服务端可达、状态码正常。
2. 把脚本里拼出来的请求头打印出来，逐字符和 curl 版本对比。
3. 换成另一台机器或另一个网络环境试一次，排除环境因素。
4. 在控制台重置凭证，用全新的密钥重跑第一步。

走到第三步基本能定位问题在代码还是环境。我吃过一次亏是在一个网络受限的环境里，请求全部超时，但报错被上层封装成了"认证失败"，我对着头信息查了两个小时才发现根本没连上。

6.2 429与速率预算

429 是限流响应。IGDB 侧对每秒请求数有限制，做批量刮削时很容易撞上，尤其是串行任务里没加间隔的那种。应对方式两类：一是加节流，每个请求之间固定 sleep；二是加退避，撞到 429 之后按指数增长的时间重试。

我倾向于两个都加，但节流是主力。固定间隔的写法最简单，缺点是网络抖动时可能浪费一点时间，可接受。退避只作为兜底，因为一个 429 意味着你已经超了预算，继续猛打只会让限制持续得更久。

有一个细节：重试次数必须设上限，并且不能对所有异常都重试。429 和 5xx 值得重试，401 和 403 重试多少次都是同一个结果，还会额外消耗配额。我一般设三次，间隔从一秒翻倍到四秒，超过就放弃并记录到失败清单。

6.3 请求成功但返回空数组

最让人摸不着头脑的不是报错，是状态码 200 但data是空数组。这种情况我归纳出五个成因：

第一条是我踩得最多的一类。很多作品在中文语境里有通称，但接口库里存的是英文原名或地区发行名。我的解法是让 IGDB 先跑一遍，把它返回的规范名称拿去做 SteamGridDB 的搜索词，这样两边的命名体系就对齐了。这个思路实际用下来准确率提升非常明显，值得写进流程里。

还有一类特殊情况：有些作品在 SteamGridDB 上确实没有该尺寸的投稿，但其它尺寸有。这时候不应该直接放弃匹配，而是放宽尺寸限制拿一张，本地做等比缩放。缩放会损失一点锐度，但总比留个空位强。

7. 抓回来的图怎么落地：命名、缓存与匹配准确率

7.1 文件名与目录约定

图片下载下来之后怎么命名，直接决定了后面更新和排错有多痛苦。我见过用数字序号命名的，也见过直接把原始文件名照搬的，两种在条目上千之后都是灾难。现在固定用三段式：规范化后的游戏标识、资源类型、尺寸标识，用连字符连接。标识取自 IGDB 的条目 ID，因为它稳定唯一，不会因为改名而变。

目录按资源类型分四层：网格封面、宽幅背景、透明 LOGO、方形图标。每层下面再按尺寸分子目录是过度设计，尺寸写进文件名就够了。这样的结构在脚本里可以用固定路径拼接，不用遍历查找。

命名里我特意避开了游戏名。名字里可能带空格、冒号、斜杠、非拉丁字符，跨文件系统和跨同步工具时全是雷。用数字 ID 加类型后缀，所有问题一次解决。

7.2 缓存与增量更新

全量重抓是最浪费时间的做法。一套几百条的库，每次跑脚本都从头拉一遍图，光流量就够呛，还容易撞限流。正确做法是增量：先扫本地缓存目录，对已有的条目只做一次轻量的"是否需要更新"判断。

这个判断有两个依据。一是本地文件是否存在，存在就跳过下载，只更新元数据。二是加一个版本标记，比如记录上次抓取时间，超过某个周期（我一般设三十天）才重新拉一遍该条目，用来看有没有更高质量的社区投稿出现。三十天这个值没什么科学依据，纯粹是运气感知——太短了白忙，太长了错过新图。

元数据那边的缓存策略要更激进一些。SteamGridDB 的搜索结果和图片列表变化慢，可以缓存很久；IGDB 的条目数据变化更慢，缓存一周完全没问题。我会把两边的原始响应按条目 ID 存成 JSON，调试时直接读本地文件，不用每次联网。

7.3 匹配失败的兜底策略

不管流程设计得多好，总有一批条目匹配不上。这时候的处理方式决定了整个工具好不好用。我的三层兜底：

第一层，换搜索源。如果 SteamGridDB 搜不到，把名称里的罗马数字、副标题、括号后缀去掉再搜一次。很多失败是因为名称太具体。

第二层，放宽约束。去掉尺寸和风格限制，拿一张任意规格的图，本地缩放。同时在下一次运行时把这条记录标记为"降级匹配"，方便日后人工复核。

第三层，留占位并输出待办清单。匹配失败的条目写进一个文本清单，带游戏 ID、尝试过的搜索词、失败原因。这份清单下次运行时会重新尝试。占位图用一个纯色方块加条目 ID，比留空白好，至少界面上不会出现布局塌陷。

最后再分享一个我自己用着挺顺手的小技巧：把两个平台的请求封装成同一个返回结构，字段统一成"资源类型、图片地址、宽高、来源标记"。上层逻辑只认这个结构，不关心图是从哪个接口来的。这样将来要加第三个图片源，只需要在底层多写一个适配器，上层一行都不用改。这套抽象我在几个不同项目里复用下来，扩展成本几乎为零。

这个做法在数据量上也能帮上忙。统一结构之后，你可以顺手统计每个来源的匹配成功率，跑一段时间就能看出哪个源在什么类型的游戏上更靠谱，然后针对性地调整搜索顺序。我最初的版本是先查 A 源再查 B 源，统计之后发现竖版封面 B 源命中率更高，横版背景反而 A 源更全，调整顺序之后整体成功率涨了一截。

另外提醒一点，图片下载本身也要设超时和重试。我遇到过完整跑完一轮，最后检查发现十几张图是 0 字节的情况——请求发出了、连接建立了、数据没传完就断了。后来加了"下载完校验文件大小，小于阈值就删掉重下"这一步，这类问题基本消失。校验阈值不用太精确，一张正常封面图至少几万字节，设个一万字节的下限足够拦住异常。

整套流程跑到稳定之后，我实际的感受是：密钥配置本身只占整个工作量的一小部分，真正花时间的是两套认证模型的适配、匹配策略的调优、以及各种边界情况的兜底。但这一步绕不过去，密钥配不明白，后面所有优化都无从谈起。先把两串密钥跑通、把最小请求验证过，再往上叠功能，节奏会舒服很多。