周五晚上我对着主机存储界面发了十分钟呆。想买的那款开放世界新作标注下载体积 128GB我的剩余空间是 96GB。删掉几个旧游戏腾地方是个办法可我又想留着一两个常玩的联机游戏。于是我开始在五个标签页之间来回切换官方商店页面查体积、官方博客翻画质模式说明、社区帖子看实机表现、计算器算剩余空间最后再回到主机设置里逐个核对。那一刻我产生了 AnyPS5 这个项目的雏形。它不是什么复杂的硬件方案而是一个很直接的想法能不能做一个网站输入游戏名一次就能看到“我的这台 PS5 能不能玩、是原生版本还是兼容运行、占多少空间、支持什么画质模式和帧率档位”。项目上线后有人把它当购买前的查漏工具也有做内容的朋友拿它当机型对比素材库。这篇文章就把整个项目的思路、数据结构和踩过的坑摊开来讲给同样想做数据型小项目的人一个参考。1. 项目初衷把“这台PS5能不能玩这款游戏”变成一次搜索1.1 一次临时起意的购买暴露了信息断层那次买游戏的经历之所以让我难受不是因为 96GB 和 128GB 之间的差值得纠结而是因为获取这 32GB 差额的成本实在太高了。官方商店页面大概是最权威的体积信息来源但它只告诉你“安装需要多少空间”不会告诉你这款游戏在 PS5 上是原生版还是 PS4 兼容运行更不会告诉你它有没有 120fps 模式、支不支持光线追踪。官方博客确实会发布增强版功能的说明但更新频率不固定而且散落在大量公告里没有结构化索引。社区讨论区里倒是有很多玩家实测反馈可惜都是零散帖子说法还经常互相矛盾有人说某个游戏在某个机型上锁 30 帧另一个人说开了增强模式能到 60 帧两个人谁都没贴配置条件。最后我养成了一个习惯把所有想买的游戏手抄在一个表格里每次买之前手动更新简直像在做一个只有自己用的数据库。这样的重复劳动多了以后我就想与其每次手动整理不如直接把这个“游戏信息汇总”做成一个产品。市面上不是没有游戏资料站但它们侧重的多是评分、攻略、剧情解说这类内容真正聚焦在“PS5 机型、版本、画质档位、存储占用”这组结构化数据上的几乎没有。这就是 AnyPS5 的切入点。1.2 我先回答四个问题再说功能做 AnyPS5 之前我把需求收敛成四个问题产品里所有功能都是围绕这四个问题设计的能不能玩这款游戏在我的 PS5 上是原生运行、兼容运行还是干脆玩不了。怎么玩它支持哪些画质模式是 30fps 还是 60fps有没有 120fps、有没有光线追踪、有没有手柄适配特性。占多大装完以后到底要占多少空间首日补丁算进去没有。我的机型行不行标准版、轻薄版、加强版之间体验差异到底在哪里。四个问题看起来简单真正建模之后才发现每一项都比预想复杂。比如“能不能玩”就不是一个布尔值一款 PS4 老游戏在 PS5 上通过兼容模式运行有些能稳定 60fps有些则有明显问题同一款游戏不同机型上的表现还不一样。再比如“占多大”商店页面写的体积和“实际能玩”的体积常常差一个首日补丁的量级。这些细节恰恰是这个项目的价值所在也是后面数据设计的主要难点。1.3 谁在用 AnyPS5以及功能边界项目维护到后面用户画像逐渐清晰起来我大致归纳成四类用户类型核心需求典型场景普通玩家买前查空间和画质档位犹豫要不要买某个游戏、现有空间是否够内容创作者机型对比、数据引用做对比视频或图文时需要一个权威数据源二手交易参与者认准机型差异确认对方卖的是哪个型号、配什么特性店员、社群运营快速推荐和答疑被反复问“这游戏好不好跑”时直接甩链接功能边界也很明确只做公开信息查询和整理不做任何系统层面的修改、越权或备份类功能。数据来源全部是官方商店公开条目、官方公告和玩家主动提交的实测反馈我自己再做一个审核层来保证质量。这个边界从立项第一天就定死了后续所有功能设计和数据流都没有越过去。2. 数据建模游戏、版本、机型的“三角关系”2.1 核心实体设计最初我以为建一张“游戏表”就够了游戏名、体积、是否支持 120fps、是否原生运行一列一个字段。等到整理数据时才意识到一张表根本装不下真实世界的关系。最终我把数据拆成了五个核心表游戏主表、版本表、机型表、兼容性记录表、玩家反馈表。先看主表和版本表长什么样CREATE TABLE games ( id BIGSERIAL PRIMARY KEY, slug TEXT UNIQUE NOT NULL, title_zh TEXT NOT NULL, title_en TEXT, genre TEXT[], press_release TEXT -- 发行方名称仅在公开渠道可查时填写 ); CREATE TABLE game_versions ( id BIGSERIAL PRIMARY KEY, game_id BIGINT REFERENCES games(id) ON DELETE CASCADE, version_type TEXT NOT NULL, base_size_gb NUMERIC(6,1), patch_size_gb NUMERIC(6,1), resolution_modes JSONB NOT NULL DEFAULT [], fps_modes JSONB NOT NULL DEFAULT [], supports_ray_tracing BOOLEAN, supports_haptics BOOLEAN );把“游戏”和“版本”拆开的直接原因是同一款游戏在 PS5 生态里可能有多个可运行形态。一款游戏可能既有 PS4 版也有 PS5 原生版PS4 版还能在 PS5 上兼容运行甚至有些游戏后来推出了“增强版”这种单独上架的重制版本。如果把这些形态全部塞进一行记录字段会爆炸查询语义也会混乱。分表之后每条版本记录都是独立可评价、可核对、可追溯的。机型表和兼容性记录表如下CREATE TABLE console_models ( id BIGSERIAL PRIMARY KEY, model_key TEXT UNIQUE NOT NULL, marketing_storage_gb INT NOT NULL, usable_storage_gb INT NOT NULL ); CREATE TABLE compatibility_reviews ( id BIGSERIAL PRIMARY KEY, version_id BIGINT REFERENCES game_versions(id), model_id BIGINT REFERENCES console_models(id), perf_class TEXT NOT NULL, notes TEXT, verified_by TEXT NOT NULL DEFAULT community, evidence_url TEXT, updated_at TIMESTAMPTZ );这里有一个关键决定画质模式、帧率档位这些字段用 JSONB 而不是拆成多个布尔列。原因很简单它们的取值数量不定。有的游戏只有 30fps 和 60fps 两个模式有的则有“质量模式 30fps”“性能模式 60fps”“120fps 模式 动态 1080p”“光追开/关”四种组合。用固定列会非常痛苦JSONB 正好把这部分可变结构包住查询时又能用 GIN 索引做包含判断后面检索效率也有保障。2.2 同一个游戏三个条目的场景用一款虚构游戏举例假如有一款《幻境协议》市面上存在这些版本PS4 原版数字版 55GB可在 PS5 上兼容运行但帧率不稳定。PS5 增强版60GB原生运行支持 60fps补丁后体积约 75GB。《幻境协议完整版》包含本体和扩展内容PS5 条目体积 95GB。这三个条目在游戏资料站里通常会被当成“一个游戏页面下的不同版本”处理。我在 AnyPS5 里的做法是games 表存一个主条目负责展示标题、类型、发行方信息game_versions 表存三个版本记录分别挂到主条目下。这样搜索时玩家输入“幻境协议”能看到所有版本点进版本详情又能看到各自独立的体积、画质和兼容性记录。这个拆分还有一个好处可以准确表达“免费升级”和“单独购买”的差别。有些游戏买 PS4 版可以免费升级 PS5 版也有游戏需要额外付费。版本表里加一个 upgrade_path TEXT 字段值为 free / paid / none配合 UI 上的标签展示玩家就不会被“为什么有两个条目”搞糊涂。2.3 机型差异不是布尔值是五档评价AnyPS5 目前维护的三个机型初版标准机型、轻薄版、加强版。三者的容量不同增强版在部分游戏的帧率档位和高分辨率支持上也确实有差别。但兼容运行的表现并不总是“行”或“不行”所以我把兼容性记录拆成五档perf_class含义例子native_excellent原生运行且表现优秀PS5 原生版稳定目标帧率native_boosted原生运行增强版机型有额外提升标准版 30fps增强版 60fpsbackcompat_ok兼容运行表现可接受PS4 版在 PS5 上兼容运行未锁帧但能玩backcompat_issue兼容运行存在问题明显掉帧、卡死、字幕错位unverified暂无可靠实测数据冷门旧作社区反馈稀少这个五档设计是我后来回头看最值的一笔。刚开始我也想用“支持/不支持”两个状态完事结果整理到第几十款游戏就发现很多 PS4 老游戏处在“兼容但体验不佳”的灰色地带。把档位细分出来后玩家一眼就能判断“能玩”和“能好好玩”的区别数据录入者也可以诚实地标注“没测过”不用硬着头皮给结论。2.4 容量字段标称值、补丁值与建议预留容量字段是 AnyPS5 被吐槽最多的部分所以后来我专门设计了一套规则。每个版本记录都有三个容量相关字段base_size_gb 是商店页面标称的基础体积patch_size_gb 是当前已知补丁累计体积两者相加再加 10% 的余量作为“建议预留空间”展示给用户。为什么一定要加余量因为实际安装时会涉及预留空间、存档文件、截图视频甚至一些游戏在解压安装过程中需要临时双倍空间。如果一个游戏基础体积 60GB、补丁 20GB我建议用户至少留出 88GB 再下载否则安装到一半弹出“空间不足”体验非常糟糕。这个建议值不是拍脑袋而是把 base、patch 和系统预留系数做了一次线性估算虽然不够精细但对普通玩家足够实用。便携性和透明性之间也要平衡。详情页会把三个数字分开显示让懂行的玩家自己判断有人只看基础体积有人把补丁算进去有人还额外留一份给录制视频用。我给的是建议不是替用户做决定。3. 数据从哪来抓取、清洗和人工审核的流水线3.1 数据源选型官方为主、社区为辅数据源直接决定项目可信度这里必须克制。AnyPS5 的基本原则是能用官方公开数据解决的问题不依赖二手转载。主数据源有三个官方商店公开页面提供每个游戏版本的基础体积、发售日期、平台标识这是“占多大”问题的最权威来源。官方更新公告提供增强版特性、新增画质模式、补丁说明等信息是“怎么玩”问题的主要依据。玩家实测反馈通过站内提交入口收集解决官方公告没有覆盖到的部分比如某款 PS4 老游戏在兼容模式下是否掉帧。第一版我犯过一个错误试图从某个聚合类站点批量拷贝数据。很快发现它的体积字段经常缺单位、版本信息混乱连“PS4 版”和“PS5 版”都混在一个列表里。从那以后数据源的优先级就固定成官方条目 官方公告 可追溯的玩家实测聚合站内容只作为线索不作为入库依据。3.2 抓取流程与频率抓取不是越频繁越好。官方商店页面的数据更新通常只有两种情况新游戏上架或者旧游戏发布大版本补丁。频率太高反而容易被限流。我的做法是用一个定时任务每晚检查一次“近 30 天新增或更新的游戏列表”。抓取脚本本身不复杂核心是限速和重试要写稳。用 Node.js 的 axios 加 cheerio 跑页面解析每抓一个页面之间随机等 800 到 1500 毫秒失败重试两次连续失败三次就发告警让管理员人工处理async function crawlStorePage(url) { const { data } await axios.get(url, { headers: { User-Agent: UA }, timeout: 15000, }); const $ cheerio.load(data); const title $(h1).text().trim(); const sizeRaw $(.game-size).text(); const sizeGB normalizeSize(sizeRaw); await db.query( INSERT INTO raw_game_entry (title, size_raw, size_gb, source_url, crawled_at) VALUES ($1, $2, $3, $4, NOW()), [title, sizeRaw, sizeGB, url] ); await sleep(800 Math.random() * 700); }这个环节只负责把原始数据落到 raw 表不做判断。判断永远交给清洗和人工审核层避免自动化误判污染主数据。3.3 单位换算与字段标准化清洗层最烦琐的是单位换算。商店页面里有的游戏标“55.3 GB”有的标“ 215 MB”偶尔还有“0.6 TB”这种写法。我写了一个归一化函数把所有体积统一成 GB 且保留一位小数function normalizeSize(raw) { const match String(raw).match(/([\d.])\s*(GB|MB|TB)/i); if (!match) return null; const value parseFloat(match[1]); const unit match[2].toUpperCase(); if (unit MB) return (value / 1024).toFixed(1); if (unit TB) return (value * 1024).toFixed(1); return value.toFixed(1); }除了体积分辨率标签和帧率档位也必须标准化。我定义了一套内部枚举分辨率只存“1080P 动态”“1080P 固定”“1440P 动态”“4K 动态”“4K 固定”这五类帧率只存“30 帧锁定”“30 帧可变”“60 帧锁定”“60 帧可变”“120 帧”这几类。这样筛选和对比才有意义。实际操作中我发现把“可变”和“锁定”区分开是很有必要的因为很多游戏宣传“支持 60fps”实际是动态分辨率下才能维持这个信息不写清楚就是在误导用户。3.4 人工复核与版本溯源自动化只能负责“收集”和“初步整理”最终能不能入库必须经过人工复核。我的流程是这样的所有待入库记录先进待审核队列后台页面会展示“来源链接”“原始数据”“归一化结果”管理员逐个确认。只有官方公告明确写出的增强特性才能标记为 official玩家提交的数据默认标记为 community并且必须附上可点击的证据链接比如截图或实机视频地址。这一套流程跑起来之后数据质量明显比第一版纯抓取稳定很多。我还加了一个 data_version 字段每次核改就加一。这样做的好处是一旦发现某条数据有问题可以立刻追溯是哪一次修改造成的并且前端缓存可以按版本号自动失效不会出现“改了数据库但用户看到的还是老数据”的情况。4. 后端实现搜索接口和组合筛选4.1 技术选型为什么是 Node.js 加 PostgreSQL后端选型时我认真比较过几组方案最终选了 Node.js 加 PostgreSQL加一个 Redis 做缓存。对比理由放在表格里方案优势问题Node.js PostgreSQLJSONB、GIN 索引、pg_trgm 模糊匹配迭代速度快全文检索不如专用搜索引擎Python FastAPI Elasticsearch搜索能力强架构重对一个小项目是杀鸡用牛刀Go MySQL性能好MySQL 的 JSON 查询能力弱一些开发效率不如 JS 顺手这个项目的真实查询量不大每天也就几千次根本用不上专门的搜索引擎。PostgreSQL 的 JSONB 配合 GIN 索引已经能覆盖绝大多数“包含某个帧率档位”“支持光线追踪”“体积在某个区间”这类查询。选 Node 则纯粹是个人开发效率的考虑前后端同一套语言社区生态成熟写抓取脚本也不用另起炉灶。4.2 中文搜索的坑没有空格前缀匹配失灵中文搜索是第一个让我头疼的技术点。普通数据库的 ILIKE %关键词% 在几十万行的表上会全表扫描数据量一大就慢。更重要的是用户根本不会老老实实打全名有人输入“幻境协议”有人输入“huanjing”还有人只记得“那个赛博朋克风的游戏”。这时候光靠标题匹配是远远不够的。我的方案是在 games 表上加一个数组字段 search_aliases存放所有可能的检索别名中文全名、中文缩写、英文名、拼音全拼、拼音首字母、常见错别字写法。然后给这个数组字段建 GIN 索引CREATE INDEX idx_games_aliases ON games USING GIN (search_aliases);查询时直接用数组包含操作符const aliases normalizeAliases(keyword); const rows await db.query( SELECT g.id, g.title_zh, v.version_type FROM games g JOIN game_versions v ON v.game_id g.id WHERE g.search_aliases $1::text[] ORDER BY g.search_hot DESC LIMIT 10, [aliases] );这个方案在数据量不算特别大的场景下非常稳。拼音别名看起来有点笨但实际命中率很高很多玩家确实只会用拼音输入。维护成本也没有想象中高每次审核新游戏时顺手把别名补全就行。4.3 组合筛选的索引设计筛选页是整个项目查询压力最大的地方因为玩家会同时勾选多个条件机型是增强版、原生运行、支持 120fps、体积在 90GB 以内。这些条件如果写不好很容易让数据库同时扫好几张表。我的核心思路是把最常用的过滤条件做成“前置窄化”字段。比如“是否支持 120fps”这个条件与其每次去 JSONB 数组里做包含查询不如在 game_versions 表上维护几个冗余布尔列supports_120fps、supports_ray_tracing、is_native_ps5。这些列在每次数据审核时同步更新查询走普通 B-tree 索引就能非常快WHERE v.is_native_ps5 true AND v.supports_120fps true AND (v.base_size_gb COALESCE(v.patch_size_gb, 0)) BETWEEN 0 AND 90 AND cr.model_id (SELECT id FROM console_models WHERE model_key pro)冗余字段会和源数据产生同步问题所以我特意在更新逻辑里加了约束任何版本记录一旦审核通过冗余字段必须由同一个事务更新不允许出现“审核过了但标记没刷”的状态。这是用一点点维护成本换查询效率对小项目来说是划算的。4.4 缓存策略热门查询要快冷门查询要准搜索和筛选结果做了两层缓存。第一层是 Rediskey 是“归一化后的查询参数”value 是结果列表 JSONTTL 设 5 分钟。热门词条会被反复命中冷门词条则自然淘汰。第二层是详情页缓存按 game_id 和 data_version 组合做 key这样数据更新时缓存立刻失效不会出现旧页面。这里有一个我踩过的坑第一版缓存 TTL 设了 30 分钟结果有一次管理员修改了一条体积数据用户端半小时内看到的还是旧值被反馈了好几轮。后来改成“短 TTL 加版本号失效”的组合策略TTL 只兜底版本号负责主动失效问题才彻底解决。小项目千万别迷信复杂缓存方案简单的 key 设计配合清晰的失效规则往往比引入一大堆缓存组件更可靠。5. 前端体验搜索框、筛选面板和详情页5.1 首页搜索“一个搜索框解决八成需求”AnyPS5 的首页只有一个搜索框加上热门搜索没有多余元素。这不是偷懒而是我复盘玩家行为之后的决定大多数人打开这个站脑子里已经在想某款游戏了他要的是“马上找到然后看到结果”而不是浏览首页分类。搜索框前面有一个 300ms 的 debounce避免每敲一个字母就打一次接口请求发出时用 AbortController 取消上一个未完成的请求防止快速输入时旧结果比新结果晚回来覆盖了正确内容。下拉建议里除了游戏名还会显示匹配到的是哪个别名、来源是哪个版本比如用户输入“幻境”时建议项会提示他“《幻境协议》PS5 原生版 60GB”。这样用户能在回车之前就确认自己找对了东西。5.2 筛选面板与结果列表结果页的筛选面板是全项目交互最复杂的部分。筛选条件包括机型三个型号可多选、兼容档位原生优秀/原生提升/兼容可玩等、帧率档位30/60/120/可变、光线追踪支持/不支持、体积区间可拖动区间条、版本类型原生/兼容/重制。所有筛选条件都同步到 URL 参数上比如?modelprofps120native1。这么做的好处有两个一是玩家可以把当前筛选结果复制给朋友二是浏览器后退按钮行为完全符合直觉。筛选状态变化时不整页刷新而是只重新请求列表部分避免前端状态丢失。列表卡片我做了三行核心信息左边游戏名和版本类型中间兼容档位和画质标签右边体积建议值。一眼扫下去就能判断“这游戏我能不能玩、占多大”需要更多信息的玩家再点击进详情页。这个信息密度经过多次调整最初我把太多字段放进卡片结果一张卡片比手机屏幕还长后来砍掉一半字段反而清楚很多。5.3 详情页的数据展示结构详情页解决“四个问题”里的最后两个怎么玩、我的机型行不行。页面结构分三块版本切换、兼容性矩阵、玩家反馈。版本切换用标签页把同一游戏的不同版本分开默认选中 PS5 原生版如果有就标一个“推荐”角标。兼容性矩阵是一张表格行是三个机型列是“帧率档位”“分辨率表现”“光线追踪”“手柄特性”每个格子显示该机型上的实测档位。这张表是项目的核心价值所在比单独写一段文字结论直观得多。玩家反馈放在矩阵下方。每条反馈必须包含机型、游戏版本、实测档位、一句话描述、证据链接。没有证据链接的反馈会进入待审核队列但不会立刻显示。这个机制保证了详情页的口碑可信度也让玩家觉得自己在参与建设而不是单方面获取信息。5.4 移动端的几个细节AnyPS5 的移动端流量占了一半以上这块我花的功夫不比桌面端少。分享几个实际体验中的细节筛选面板在移动端是抽屉式从底部滑出避免占用整个屏幕详情页底部有一个粘性操作栏放着“加入我的库”按钮方便用户边查边记录兼容档位的彩色角标我特意调高了对比度因为很多玩家在室外光线强的地方看手机颜色区分度不够的话根本看不到。还有一个小细节所有体积数字在移动端都做了“自动换算展示”如果小于 100GB 显示整数大于 100GB 显示一位小数超出 1024GB 则自动换成 TB 单位。这听起来很基础但很多站点在手机上显示一长串小数阅读体验非常差。6. 踩过的坑容量换算、补丁体积和地区差异6.1 825GB 标称容量的陷阱初版机型标称“825GB 存储”但玩家在主机设置里看到的可用空间大约只有 667GB。这个差异来自两个环节首先硬盘厂商按十进制计算容量1GB 等于 10 亿字节而系统按二进制计算1GB 等于 1073741824 字节单位换算就缩水了一截其次系统还要预留一部分空间给固件、缓存和系统功能。我一开始把机型表的 marketing_storage_gb 直接拿来给前端做“还能装几个游戏”的估算结果闹了笑话按 825GB 计算玩家明明已经装了大半系统却提示还有大量剩余。后来我改成单独维护 usable_storage_gb 字段并且在详情页的“装不装得下”计算器里默认使用可用空间而不是标称空间。这个陷阱让我意识到做数据产品字段的物理含义必须和用户看到的现实保持一致不能直接把厂商参数搬到 UI 上。6.2 首日补丁让数据快速失真一款游戏商店页面标着 60GB玩家装完一看占了 82GB于是来吐槽数据不准。原因就是首日补丁。大作发售后一到三天内通常会推出补丁修复内容从几百 MB 到一二十 GB 不等商店页面的基础体积根本不会跟着更新。我的应对方法是把“基础体积”和“补丁体积”分开记录并且在录入规则里写明补丁体积必须在官方更新日志中能查到才允许填写查不到的暂不记录。审核流程里还有个不成文的规定新游戏上架一周内必须复查一次补丁体积。这一周是首日补丁集中发布的时间窗口错过就很容易让数据长期失真。6.3 港服、日服、美服的数据对不上项目支持多个地区的数据之后很快发现同一个游戏在不同服务器的页面数据并不一致。有的地区版本是独占的有的地区版本补丁更新节奏不同还有的语言包体积差异很大。刚开始我用“通用一条数据”覆盖所有地区结果日本玩家反馈“体积对不上”欧美玩家也反馈“语言包标注错误”。修正方案是给每条版本记录加一个 region 标签默认展示本地服务器数据同时允许玩家切换区域查看对应数据。这个改动增加了数据量但换来的是准确性。对于区域性差异特别大的游戏详情页会显示“其他地区版本数据可能不同”的提示引导玩家切到自己的区域再看。6.4 众包纠错与信任问题众包反馈是数据持续更新的重要动力但也是被滥用的入口。有人故意提交错误的帧率档位有人为了黑某个游戏频繁举报它“有问题”。第一版反馈功能上线后后台收到一堆没证据的“修正”大部分是情绪输出。现在的机制是反馈必须附证据链接纯文字描述直接进低优先级队列同一个版本如果有超过三条互相矛盾的反馈人工审核时会要求提交者补充实机截图或视频审核通过后反馈对应记录会自动带上“已核对”标记并显示核对时间。规则收紧后后台的有效反馈比例高了很多。这件事给我的经验是众包不是“只要有人提交就行”必须让每个参与者为自己的结论负责平台要做的是提供一个可查证的流程而不是无脑相信所有人。AnyPS5 做到现在我最大的体会是数据项目里真正的门槛从来不是写代码而是把数据的采集、校验、更新和解释讲清楚。技术方案可以换代码可以重构但“每个数字背后都有出处、每个结论都能被考证”这个原则一旦松动项目也就失去了存在的意义。如果后续还有精力扩展我会优先做“根据我已有游戏库推荐还能装什么”的能力把这份结构化数据真正用起来。不过在那之前把基础数据持续喂准永远比加一个新功能更重要。