SteamGridDB与IGDB API密钥配置：游戏库刮削与封面优化指南

做游戏库整理这块的人大多经历过同一个阶段元数据刮削器跑完一遍游戏的标题、年份、简介都对上了可封面还是那张分辨率低得可怜、四周带黑边的官方图背景图干脆是空的。这时候你去翻刮削器的日志通常能看到两条被忽略的配置项——SteamGridDB和IGDB。前者是社区共建的封面图库后者是结构化的游戏元数据库两者配合起来基本能把一个本地游戏库从“能玩”拉到“看着舒服”。这篇内容就是围绕这两个服务的 API 密钥配置展开的从前期的账号准备、密钥申请到接进刮削工具的填法、参数调优、常见报错排查我会按实际操作的顺序讲一遍。适合自己搭媒体服务器、玩模拟器前端、或者用 HTPC 整理游戏墙的朋友也适合只是想让自己的游戏库封面别那么糊的普通玩家。不需要你会写代码但懂一点命令行会让你少走不少弯路。1. 这两个服务到底能给你什么在动手申请密钥之前得先搞清楚它们各自负责什么。很多人一上来就两个都申请结果配置的时候发现某个功能没生效回头排查半天其实是把两个服务的职责搞混了。我见过最常见的误解是以为 IGDB 能提供高清竖版封面以为 SteamGridDB 能提供发售日期和厂商信息。事实刚好相反这两者是一个互补关系。1.1 定位差异一个管“正确”一个管“好看”IGDB的核心价值在于结构化元数据。它能给你游戏的准确名称、别名、首发日期、平台列表、开发商、类型标签、简介文本以及一组官方封面和截图。它的数据来源偏官方和数据库式字段规整、可查询、可筛选适合用来做“这条记录到底是不是我要的那个游戏”的判断。但它的图片资源是有天花板的——官方封面通常只有一种构图宣传图数量也有限而且分辨率档位固定翻来覆去就那几档。SteamGridDB反过来它的核心价值在于视觉资源的丰富度。它是一个社区上传型图库同一个游戏可能有几十上百张竖版封面、横版海报、透明 Logo、方形图标、宽幅 Hero 背景图。风格从官方复刻到极简、从像素风到电影感甚至还有各种主题化重制。它的元数据能力很弱你拿它查游戏基本只能靠名字模糊搜索但你要的是“好看的图”它给的量级是 IGDB 的几十倍。所以实际配置的逻辑应该是用 IGDB 保证这条游戏记录是对的用 SteamGridDB 保证它好看。刮削工具大多也是这么设计的——先用 IGDB或内置数据库做匹配匹配成功拿到唯一 ID再拿这个 ID 去 SteamGridDB 拉图。你在配置界面看到两个密钥输入框原因就在这里。1.2 为什么绕不开自己申请密钥这两个服务都不提供“公共匿名密钥”也就是你没法直接调用必须自己注册账号、自己生成一把密钥。这个设计不是刁难人主要是为了限流归因和滥用防护。社区图库的带宽成本不低如果有人写个脚本把全站的图刷一遍服务器扛不住所以每家都要求请求带上身份标识超了就掐。对普通用户来说这件事的实际影响是密钥是跟你的账号绑定的配额也是你一个人用的。这反而是好事你不用担心别人把公共额度用光导致自己刮削失败。代价是你得走一遍注册流程而且有些服务的密钥是长期有效的有些是短期 Token 需要定时刷新这个差异在后面会详细讲也是新手最容易翻车的地方。另外一个常被忽略的点是密钥的敏感程度。它本质上是一把能代表你账号去请求数据的凭证。如果泄露别人可以用你的额度刷图严重的话可能触发风控导致你的账号被限制。所以从申请那一刻起就应该按“密码”的级别对待它不要直接硬编码在会公开的配置文件里也不要随手贴到群里或者截图里。1.3 密钥形态与调用方式对比把两者的差异列成一张表会清楚很多我在配置之前一般都会先画这么一张对照表因为后面填配置、写脚本、排查问题全靠它。对比项SteamGridDBIGDB凭证形态一把长期有效的 API KeyClient ID Client Secret需换取 Access Token有效期长期除非手动吊销Token 约 60 天过期需重新换取请求头写法Authorization: Bearer KeyClient-ID: ID加Authorization: Bearer Token双头请求方式基本是 GET基本是 POST请求体里写查询语句查询语法URL 路径加参数专用查询语句字段用逗号分隔主要产出竖版封面、横版海报、Logo、图标、Hero 图名称、日期、平台、厂商、简介、官方封面与截图限流粒度按时间窗口计次按每秒请求数计次图片尺寸控制请求参数指定分辨率与风格替换图片 URL 中的尺寸档位标识看这张表你就明白为什么两者的配置步骤完全不一样了。SteamGridDB 属于“拿到钥匙就能开门”的类型一次配置长期有效IGDB 属于“先拿介绍信换临时通行证”的类型中间多了一层换取 Token 的动作而且这个 Token 会过期。很多人配完 IGDB 用了两个月突然刮削全失败八成就是 Token 到期了但工具没做自动刷新。提示如果你用的刮削工具在 IGDB 配置项里只让你填 Client ID 和 Client Secret说明它内部帮你做了 Token 换取和刷新如果它让你直接填一个 Access Token那你就要自己盯着过期时间。这两种情况在排查思路上完全不同配置前先确认清楚。2. 申请流程从注册到第一次成功请求这一段我把两个服务的申请流程按实际操作顺序走一遍。流程本身不复杂但有几个地方容易卡住邮箱验证收不到、应用信息填不对、拿到的凭证搞混了是 ID 还是 Secret。我会把每一步的意图说清楚这样即使界面改版了你也能自己判断该点哪里。2.1 SteamGridDB三分钟拿到一把长期密钥第一步是注册账号。访问它的主站右上角注册填邮箱、用户名、密码收验证邮件点确认。这一步没什么坑唯一的建议是用你长期在用的邮箱因为这个账号以后可能要用来管理密钥、查看配额用临时邮箱后面会麻烦。登录之后进入个人设置区域找到应用管理通常叫 Applications 或者 API Keys 之类的入口。这个页面会列出你已经生成的密钥第一次进来是空的。点新建会让你填一个名字这个名字随便起但建议起得有辨识度比如“家里媒体库刮削”或者“笔记本上的前端配置”。原因很简单万一哪天你觉得密钥可能泄露了要吊销一堆叫“key1”“key2”的条目你根本分不清哪把在用在哪台机器上。提交之后页面会显示一串字符这就是你的 API Key。这里有个关键细节部分平台只在生成的那一刻完整显示一次之后只显示前后几位。所以拿到之后立刻复制到你的密码管理器里别关掉页面才想起来。我有一次就是手快点了刷新结果只能吊销重生成白白浪费一次操作。关于配额它的限制是按时间窗口计次的正常刮削几十上百个游戏完全够用。真正会触发限制的是你写脚本遍历整个图库那种场景需要自己加延时。日常使用不用担心。注意SteamGridDB 的密钥是长期有效的没有过期时间。这既是方便也是风险——意味着一旦泄露它会一直有效直到你手动吊销。所以定期检查一下应用列表里有没有不认识的条目是个好习惯。2.2 IGDB两步走先拿 Client 凭证再换 TokenIGDB 的流程多一层因为它的鉴权走的是 OAuth 的客户端凭证模式。你需要先在它所属的账号平台的开发者控制台注册一个“应用”拿到 Client ID 和 Client Secret然后用这两个东西去换一个短期的 Access Token最后拿 Token 去请求数据。第一步用你的账号登录 IGDB 官网在 API 相关的页面会有一个引导入口跳转到开发者控制台。如果你找不到入口直接在 IGDB 的 API 文档页往下翻那里一定有注册链接——官方文档不会让你卡在这一步。第二步在开发者控制台里创建应用。这一步是新手最容易出问题的地方因为表单里要填的东西看着挺正式应用名称、用途说明、分类、 Redirect URI 之类的。我的经验是应用名称填个能认出来的比如“本地游戏库元数据同步”别填测试什么的有些平台对名称有审核。用途说明用一两句话写清楚你是在做个人项目的元数据整理不要写得太夸张。分类选与个人工具、数据查询相关的选项。Redirect URI如果你只是做服务端到服务端的凭证模式调用这一项随便填一个合法的地址占位就行因为客户端凭证模式根本不会走回调。但表单通常必填填http://localhost这类就行。创建成功后页面会给你Client ID和Client Secret。这两个东西长得很像都是一串字符但作用完全不同千万别填反了。我见过有人把 Secret 填到 ID 的位置结果一直报鉴权失败排查了半天以为是网络问题。记住Client ID 是公开的身份标识可以出现在请求头里Client Secret 是密码只能出现在换取 Token 的请求体里绝对不能放在前端代码或者公开的配置文件里。第三步用这两个凭证去换 Access Token。这是一个 POST 请求参数是固定的三件套client_id、client_secret、grant_type其中 grant_type 固定填client_credentials。请求成功后会返回一个 JSON里面有 access_token 和 expires_in单位是秒。expires_in 通常在五百万秒左右换算下来差不多 60 天。# 换取 Access Token 的请求域名与路径以官方文档为准这里用变量占位 curl -X POST https://${AUTH_HOST}/oauth2/token \ -d client_id${IGDB_CLIENT_ID} \ -d client_secret${IGDB_CLIENT_SECRET} \ -d grant_typeclient_credentials返回大概长这样{ access_token: abcdefghijklmnopqrstuvwxyz123456, expires_in: 5184000, token_type: bearer }拿到 access_token 之后请求 IGDB 数据接口时请求头里要同时带Client-ID和Authorization: Bearer两个字段。少一个都不行少 Client-ID 会报缺少客户端标识少 Authorization 会报未授权。这也是很多人配了半天不成功的原因——他们以为跟 SteamGridDB 一样只要一个 Bearer 就够了。2.3 第一次验证请求怎么写密钥拿到手别急着往刮削工具里填先在命令行里跑一个最小请求确认这把钥匙本身是通的。这一步能帮你把“密钥问题”和“工具配置问题”彻底分开后面排查会省很多时间。SteamGridDB 的验证请求最简单一次搜索就行export SGDB_KEY你刚才生成的密钥 # 按名字搜索游戏拿候选列表 curl -s -H Authorization: Bearer ${SGDB_KEY} \ https://www.steamgriddb.com/api/v2/search/autocomplete/Celeste | head -c 800如果返回的 JSON 里success是 true并且data数组里有内容说明密钥没问题。如果返回 401那是密钥错了或者没带对头如果返回 403多半是账号还没完成邮箱验证或者被限制了。拿到搜索结果的游戏 ID 之后就可以直接拉图# 拉竖版封面指定分辨率和风格 curl -s -H Authorization: Bearer ${SGDB_KEY} \ https://www.steamgriddb.com/api/v2/grids/game/12345?dimensions600x900typesstaticnsfwfalsehumorfalse \ | head -c 1200IGDB 的验证要分两步先换 Token再查数据# 第一步换 Token把结果里的 access_token 存到变量 export IGDB_TOKEN$(curl -s -X POST https://${AUTH_HOST}/oauth2/token \ -d client_id${IGDB_CLIENT_ID} \ -d client_secret${IGDB_CLIENT_SECRET} \ -d grant_typeclient_credentials \ | grep -o access_token:[^]* | cut -d -f4) # 第二步查游戏数据 curl -s -X POST https://api.igdb.com/v4/games \ -H Client-ID: ${IGDB_CLIENT_ID} \ -H Authorization: Bearer ${IGDB_TOKEN} \ -H Accept: application/json \ -d fields name, first_release_date, cover.url, artworks.url; where name Celeste; limit 3;这两条都跑通说明你的凭证链路是完整的接下来往工具里填就只是照抄的事。我强烈建议把这两条命令存到一个小脚本里以后每次换机器、换工具、或者怀疑密钥有问题跑一遍就能确认。3. 接进刮削工具配置位置与参数调优密钥通了接下来是接到你的刮削端上。不同的工具界面差异很大但底层要做的事情就那几件把凭证存进去、选好图片规格、控制请求节奏。这一段我按“填哪里—怎么管 Token—怎么调参数—怎么存本地”的顺序讲。3.1 刮削端里密钥填在哪大部分支持这两个服务的工具配置入口都在“元数据源”或者“刮削器”相关的设置页里。你会看到类似“启用 IGDB”“SteamGridDB API Key”这样的选项。填写时注意几点第一区分字段类型。IGDB 通常会要求你填 Client ID 和 Client Secret 两个框有的工具还会额外要求你填一个 Access Token这种情况下它可能不做自动刷新。SteamGridDB 一般只有一个 API Key 框。填之前先看清楚标签别把 Secret 塞进 ID 的框。第二保存后要重启或重新加载配置。很多工具读取配置是在启动时一次性加载的你在界面里填完不重启刮削器用的还是旧配置然后你会以为密钥没生效。我踩过这个坑来回检查了十几分钟密钥最后发现只是没重启。第三注意工具的配置存储位置。有些工具把密钥明文写在配置文件里有些会加密。如果是前者记得给配置文件设好权限别让它被同步到公开的云盘目录。常见配置形态需要填的字段注意事项只填 SteamGridDB Key一个 API Key最省事但只能用社区图元数据要靠内置库只填 IGDB ID Secret两个字段工具内部负责换 Token省心但看不到 Token 状态IGDB ID Secret Token三个字段手动管理 Token过期需自己更新两个服务都启用三个到四个字段推荐组合元数据准确且图好看3.2 Token 生命周期管理与自动刷新这是整篇内容里最值钱的一段因为 IGDB 的 Token 过期是最高频的“突然不能用”原因。前面说过Token 的有效期大约是 60 天。如果你的工具支持自动刷新那它会自己在快过期时重新换取你基本不用管。但如果工具是让你手填 Token 的那你就得自己搞一套刷新机制。最土但最可靠的办法是写一个小脚本每次刮削前先跑一遍换 Token把新 Token 写进配置文件或者环境变量。这样虽然每次都多一次请求但绝对不会因为过期而失败。如果你是用脚本自己调接口推荐的做法是把 Token 和它的过期时间一起缓存起来每次用之前判断一下剩余时间快过期了才去换。这样既不会每次都换浪费请求也不会用过期 Token。下面这个 Python 片段是这种思路的简化版import os, time, json, requests TOKEN_FILE os.path.expanduser(~/.cache/igdb_token.json) def get_token(): # 先看本地缓存 if os.path.exists(TOKEN_FILE): with open(TOKEN_FILE) as f: cache json.load(f) # 留 1 小时余量避免边界情况 if cache[expire_at] - time.time() 3600: return cache[token] # 缓存失效或快过期重新换取 resp requests.post( fhttps://{os.environ[AUTH_HOST]}/oauth2/token, data{ client_id: os.environ[IGDB_CLIENT_ID], client_secret: os.environ[IGDB_CLIENT_SECRET], grant_type: client_credentials, }, timeout15, ) resp.raise_for_status() payload resp.json() cache { token: payload[access_token], expire_at: time.time() payload[expires_in], } os.makedirs(os.path.dirname(TOKEN_FILE), exist_okTrue) with open(TOKEN_FILE, w) as f: json.dump(cache, f) # 缓存文件权限收紧 os.chmod(TOKEN_FILE, 0o600) return cache[token]这段代码里有两个细节值得说。一是余量我用的是 1 小时因为如果你的脚本跑在半夜可能刚好卡在过期前一分钟留点余量比较稳。二是文件权限 0o600缓存文件里存的是能代表你身份的 Token不能让同机器的其他用户读到。注意不要在多台机器上同时高频换取 Token。有些平台对同一组 Client 凭证的换取频率有限制你十台机器各换一次可能就被掐了。多机场景下最好共享一个缓存或者各自用独立的应用凭证。3.3 图片规格参数分辨率、风格、过滤条件SteamGridDB 的请求参数是这个服务最灵活的地方也是调优空间最大的地方。同样的游戏参数配得好出来的封面整齐划一配得不好一半竖版一半横版看着很乱。先说尺寸。常用的几种规格用途推荐尺寸说明竖版封面最常用600x900大多数前端和媒体库的主封面竖版封面小图342x482列表、缩略图场景横版海报920x430详情页顶部横幅、背景横版海报小460x215卡片式布局方形图标512x512启动器图标、分类图标Logo透明底不限通常是透明 PNG叠在背景上用关键点是同一批刮削要保持规格一致。你如果混用 600x900 和 512x768前端显示时就会出现高度不齐、留白不均的问题。我的做法是全库统一 600x900 竖版加 920x430 横版其他规格只在个别游戏缺图时兜底。再说风格过滤。SteamGridDB 的图有很多标签请求时可以按标签筛选。常见的几个styles控制视觉风格比如是否带 Logo、是否极简、是否有材质效果。types区分静态图和动态图静态图兼容性最好。nsfw成人内容过滤个人自用库建议关掉不然某些游戏的搜索结果会很尴尬。humor恶搞类图片看个人喜好。epilepsy闪烁动画相关过滤主要是给动态图用的。我的建议是第一次刮削时把过滤条件收紧只拿静态、非成人、非恶搞的图得到一个干净的基线库。等库里跑完了再针对个别游戏手动换图。反过来做——先全放开再往回删——工作量大得多。IGDB 那边的图片参数少一些主要是替换图片 URL 里的尺寸档位。它返回的封面 URL 形如.../t_thumb/xxxx.jpg把t_thumb换成t_cover_big或t_1080p就能拿到更大的图。这个技巧很实用因为很多工具默认只取缩略图显示出来很糊你手动改一下档位就能解决。t_thumb - 极小的缩略图只适合列表 t_cover_small - 小封面 t_cover_big - 大封面日常够用 t_720p - 720p 截图档 t_1080p - 1080p 截图档 t_original - 原始尺寸体积最大3.4 本地缓存与命名规范刮削一次几百个游戏如果每次都去线上拉图一是慢二是容易触发限流三是万一哪天服务抽风你的库就全空了。所以一定要做本地缓存把下载下来的图存在本地只在缺图时才联网。缓存目录我一般按“资源类型/游戏标识/文件名”三级来组织library/ covers/ 12345/ grid-600x900-01.webp 67890/ grid-600x900-01.webp heroes/ 12345/ hero-1920x620-01.webp logos/ 12345/ logo-01.png meta/ 12345.json用游戏 ID 做目录名的好处是不会因为游戏改名而失效。文件名里带上尺寸和序号方便同一游戏存多张备选图。meta目录存一下刮削到的元数据快照这样即使离线也能看到基本信息。格式方面优先选WebP。同样的视觉质量下体积比 PNG 小很多几百个游戏的封面库体积差异会很可观。但如果你的前端对 WebP 支持不好退回 PNG 或 JPEG 也行JPEG 建议质量参数给到 90 以上不然封面边缘会有明显的块状噪点。提示下载图片时记得检查响应头里的Content-Type。有些图库返回的图实际是 WebP 但扩展名标的是 jpg如果你的程序按扩展名判断格式后续处理可能出错。4. 报错排查实录与限流策略配置这一类服务出问题基本都是固定的几种。我把踩过的、以及帮别人排查过的整理成了一张速查表再挑几个典型的展开讲。4.1 状态码速查表现象可能原因排查动作401 Unauthorized密钥错误、Token 过期、请求头格式不对检查 Bearer 后面是否多空格、Token 是否过期403 Forbidden账号未验证、权限不足、被风控登录账号看状态确认邮箱已验证404 Not Found游戏 ID 不存在、接口路径写错先用搜索接口确认 ID429 Too Many Requests触发限流降低并发加延时重试返回 200 但 data 为空查询条件过严、游戏名匹配不上放宽过滤条件或改用模糊搜索图片下载 403图片直链有防盗链、Referer 校验带正常的请求头再下载工具报“无效配置”但命令行能通工具不支持该鉴权方式看工具版本或改用其支持的字段组合4.2 401 的三种典型情况和判断方法401 是最常见的报错但它有三个完全不同的原因得分开判断。第一种是密钥本身错了。判断方法很简单用命令行跑一次最小请求如果命令行也报 401那就是密钥问题。检查有没有复制时多带了空格、换行或者把 Client Secret 当成 ID 用了。第二种是 Token 过期。特征是之前一直能用某天突然全挂。判断方法是看这个 Token 是什么时候换的算一下距离现在多久。如果接近 60 天基本可以确定。解决办法是重新换一次 Token。第三种是请求头格式问题。这个最隐蔽因为密钥是对的、Token 也是新的但请求就是不通。常见错误包括Bearer和 Token 之间用了多个空格、把Authorization写成Auth、IGDB 只带了 Bearer 没带 Client-ID。我建议这种时候把完整请求打印出来逐字符看肉眼比对往往比猜快。4.3 图片下载了但显示不出来这个问题的表现是刮削日志显示下载成功文件确实生成了但前端加载时是空白或者白块。原因通常有三类。第一类是格式不匹配。文件扩展名是 jpg实际内容是 WebP某些老前端不认。解决办法是用文件头判断真实格式或者统一转成 PNG。第二类是图片尺寸超限。有些前端对超大图有硬性限制比如宽度超过 4000 像素直接不渲染。SteamGridDB 上有一些用户上传的超大原图指定尺寸参数时会返回接近原图的版本。解决办法是在请求时就锁定尺寸别让服务返回“原图”。第三类是权限问题。文件下载下来了但运行刮削器的进程和运行前端的进程不是同一个用户后者读不到文件。Linux 上这种情况很常见检查一下目录权限和所属用户组。4.4 批量刮削怎么不触发限流限流是批量操作绕不开的。两个服务的限制粒度不一样应对策略也不同。SteamGridDB 是按时间窗口计次的。批量刮削时的稳妥做法是串行请求加固定延时。我一般设置每个请求之间间隔 300 到 500 毫秒几百个游戏跑下来也就几分钟完全能接受。不要去追求并发省下来的那点时间不值得冒着被限流的风险。IGDB 是按每秒请求数算的公开的阈值通常是每秒 4 次。如果你要查几百个游戏建议控制在一秒 3 次以内留点余量。更聪明的做法是批量查询——IGDB 的查询语句支持一次传多个条件你可以把几十个游戏名拼成一条查询一次拿回来比分几十次查效率高得多也不容易触发限流。fields name, cover.url, first_release_date; where name (Celeste, Hades, Cuphead, Dead Cells); limit 50;这条查询一次就返回四个游戏的信息只消耗一次请求额度。批量刮削的核心优化就是尽可能用这种合并查询而不是傻乎乎地一个游戏一条请求。注意合并查询里的游戏名必须精确匹配写错一个字就查不到。所以稳妥流程是先用模糊搜索拿到准确的英文名再用准确名去做合并查询。4.5 匹配错游戏的处理思路有些游戏名字重复或者有多部作品自动匹配很容易认错。典型场景是同名重制版、带副标题的续作、以及各种地区版本差异。表现是封面明显不对比如你刮的是一个横版动作游戏结果给了一张赛车游戏的图。遇到这种情况别硬改自动匹配规则而是用唯一标识锁定。先在 IGDB 或者 SteamGridDB 里手动搜一次找到正确的 ID然后在刮削工具的映射配置里把这个本地文件夹或文件名直接绑到那个 ID 上。大部分工具都支持这种手动覆盖配置一次之后就不会再错。如果工具不支持 ID 绑定退而求其次的办法是修改本地游戏名使其唯一。比如把“某某游戏”改成“某某游戏 重制版”让搜索能区分开。这个方法土的但有效缺点是改完名字你的文件夹列表看着不如原来干净。5. 长期维护的几条个人习惯密钥配好只是开始这套东西是要长期用的。下面几条是我用了几年下来形成的习惯谈不上多高明但确实帮我省了不少事。5.1 密钥的分级保管我把这两类凭证分成三个存放层级各有各的用途。第一层是密码管理器存原始凭证——SteamGridDB 的 Key、IGDB 的 Client ID 和 Secret。这是唯一的“真相来源”任何时候需要核对或者重新配置都从这里取。密码管理器有加密、有备份、有访问记录比任何临时文件都可靠。第二层是环境变量文件也就是脚本和工具读取的那一份。它放在不参与版本控制的目录里权限设成只有自己能读。这个文件里的值是密码管理器里的副本需要轮换时两边一起改。第三层是工具内的配置也就是刮削器界面里填的那一份。这一层尽量少改动因为改一次就要重新验证。只有当凭证轮换时才动它。分三层的意义在于任何一层出问题你都能快速定位到是哪个环节。而且轮换凭证的时候你有明确的清单知道要去改哪些地方不会漏掉。5.2 定期做一次“断网演练”这个习惯听起来有点多余但真的救过我一次。具体做法是把网络断开或者临时改一下 DNS 让它解析不到然后启动你的游戏库前端看看能不能正常显示封面和元数据。如果一切正常说明你的本地缓存是完整的、路径是对的、前端不依赖实时请求。如果有大片空白那说明某些资源没有落到本地或者前端配置里开启了实时拉取。我之所以重视这个是因为有一次我把缓存目录换了个位置忘了同步迁移结果某天网络波动的时候就发现一大半封面加载不出来——平时网络好的时候前端偷偷去线上拉图把问题掩盖了。断网演练能提前暴露这种隐患。5.3 一个关于工作量分配的经验最后分享一个我在这个项目上的实际体感前期花在配置上的两小时能省掉后面反复整理封面的二十小时。很多人包括早期的我的做法是先用默认配置跑一遍看到封面不满意手动一张张换。结果换了五十个游戏之后发现其实换个参数重新刮一遍就能全解决手动换的那些功夫全白费了。所以我的建议是第一次刮削之前先花点时间做三件事把尺寸统一了、把过滤条件收紧了、把缓存目录规划好。这三个决定一旦定下来后面基本不用再动。真正需要手动处理的只会是那些图库里资源特别少的冷门游戏比例大概在百分之五以内这个量级是可以接受的。再补充一个小技巧如果你发现某个游戏的自动匹配总是给出不理想的图与其反复调参数不如去确认它到底有没有在 IGDB 里被正确识别。很多时候问题不在图库而在于这条游戏的元数据本身就匹配错了导致后续所有拉图请求都是基于错误的 ID。先修元数据再谈封面顺序不能反。