先交代一下背景。我是个游戏库存控平时最大的爱好就是逛各个商店页面和评分站看看最近有什么值得入手的PS5游戏。可时间一长我发现自己每天至少要在五六个不同站点之间来回切换——想确认口碑得去媒体评分站想比价格得看商店页面想核对发售日期又要翻新闻帖偶尔还会因为两个站点的评分口径不一样白白纠结半天。于是某天晚上我给自己提了一个需求能不能做一个工具输入一个游戏名就能一次性查出它的基本资料、媒体评分、用户评分、当前价格和发售状态这就是 AnyPS5 项目的最开始。我把这个项目定位成一个纯个人向的PS5游戏信息聚合与检索工具不追求替代任何平台也不做商业用途只解决我自己的信息焦虑。整个开发过程从爬虫选型、数据清洗、存储设计到最后的Web化封装前前后后花了将近三周。这篇文章不打算写成教程而是想把我踩过的坑、做过的取舍、以及最终沉淀下来的方案如实讲一遍给同样想折腾本地游戏数据库的朋友留个参考。1. 立项动机被割裂的信息源逼出来的自建工具1.1 每天重复五遍的查游戏操作买PS5游戏这件事看着简单实际很折腾。你看到一个游戏预告心里的第一反应通常是这游戏到底行不行现在多少钱什么时候能玩到我的习惯是先查媒体均分再翻用户短评然后去商店看定价最后再去社区确认一下这游戏首发有没有翻车。每个环节对应一个不同站点每个站点的搜索结果排序逻辑还不一样有些站你搜中文名能出结果有些站必须输入英文原名输错一个字母就啥也搜不到。这种情况偶尔碰上还能忍但如果你是新游戏密集发售的那几个月几乎每天晚上都要重复这套流程。我算过一笔账平均查一款游戏大概要花十五分钟其中大部分时间浪费在切换页面—重新输入—对比口径上。时间长了我就在想与其天天做这些手工劳动不如花点时间把信息聚合起来以后一个搜索框全部搞定。1.2 明确项目边界只做聚合不做判断立项之前我特意给自己划了几条红线。第一不采集破解或涉及灰色领域的内容只抓公开的商店信息、公开的评分数据和公开发售状态第二不做一键比价跳转购买这类可能触及平台协议的功能至少个人版不做第三任何评分数据必须标注来源和采集时间我不能也不应该替用户计算一个所谓综合分。想清楚这些之后AnyPS5 的产品形态就很简单了一个能搜游戏、能看资料、能记价格变化的本地数据库工具。1.3 只是给自己用不顺手做成了可扩展的小框架最开始我确实只打算写个脚本跑一次将这些信息揉进一个JSON文件里就算了。但实际抓了几百款游戏之后就发现如果只是静态存储数据很快会过期——评分会变、价格会跳、发售状态会更新。所以我把整个项目重新设计成数据采集层 存储层 查询层的三段式结构采集层可以单独调度存储层负责去重和归档历史查询层只管给前端或者接口吐数据。这个决定在后面扩展新游戏的时候帮了大忙。2. 数据源选型与爬虫架构AnyPS5 的地基2.1 我最终选定的抓取方案数据源是整个项目最敏感也最关键的部分。我的原则是优先选结构比较规整、对爬虫相对友好的公开页面尽量少碰有明显反爬对抗的站点。最终定下来四类数据源官方商店的公开游戏页面、两家主流的媒体评分聚合站、一个社区用户评分板块、以及发行商官网的发售日期公告。每类源只抓自己最擅长的字段比如评分站只抓分数和评论数商店页面只抓定价和语言支持日期公告只抓发售状态这样每个源的责任边界很清晰。技术上我用了 Python 的httpx做异步请求加上parsel做 HTML 解析。没有上 Selenium 这类重型浏览器方案因为大部分目标页面是服务端渲染的普通的 HTTP 请求加上合理的请求头就能拿到完整内容。异步爬虫的好处是几百个页面的抓取可以在几分钟内完成但代价是要自己控制并发一个不留神就会触发对方的风控后面会单独讲这块。# 示例异步抓取某个游戏详情页 import httpx from parsel import Selector async def fetch_game_page(session, url): resp await session.get(url, headersHEADERS) resp.raise_for_status() sel Selector(textresp.text) return { title: sel.css(h1::text).get(), score: sel.css(.score::text).get(), release_date: sel.css(.release-date::text).get(), }2.2 为什么不用现成的游戏数据库API有人可能会问市面上已经有不少现成的游戏数据库接口为什么还要自己爬我实际调研过主要卡在三个问题上。第一覆盖范围不均冷门独立游戏和日系游戏的数据明显偏少而这两类恰恰是我最常搜的第二接口的评分数据通常只有单一来源没法满足我对比多个口径的需求第三很多接口返回的字段里中文名称、中文版发售日这种本地化信息严重缺失。综合看下来自己爬虽然前期工作量大但数据完全在我的掌控里清洗和扩充都方便后续维护成本反而更低。2.3 数据清洗里的三个关键动作爬虫写完只是第一步真正花时间的是数据清洗。我踩过的坑基本都集中在这个环节总结下来有三个动作特别重要。第一个动作是字段归一化。不同站点的日期格式、价格单位、语言标识完全不一样意大利语区的日期写法是日/月/年英语区是月/日/年如果直接照单全收存进数据库之后排序都是错的。我写了一套统一的格式转换函数把所有日期转成 ISO 8601所有价格统一存数字和货币代码两个字段语言列表统一转成标准代码表。第二个动作是标题别名映射。同一个游戏商店页面用英文名社区用中文名评分站又用缩写这三者如果不在入库时关联起来后面搜索就废了。我的做法是建立一张别名表把官方标题中文惯用名常见缩写系列编号分开存查询时统一走这张表。第三个动作是空值处理策略。评分站还没出分的游戏、商店还没公布价格的游戏这些字段抓回来是空的。我一开始直接留 NULL后来发现过滤和排序时频繁出问题干脆规定所有空值必须带一个未公布的状态标记这样查询逻辑可以显式处理而不是靠猜。3. 搜索、对比与提醒三个核心功能的实现思路3.1 模糊搜索与中英文别名AnyPS5 的主界面就是一个搜索框这个搜索框决定了用户对工具的第一印象。我第一个版本用的是 SQLite 自带的LIKE %关键词%结果搜老头环这种社区俗称完全没反应因为数据库里根本没有这个别名。后来我引入了两层策略第一层是精确命中别名表第二层是 FTS5 全文索引。全文索引的好处是支持分词和前缀匹配英文游戏名搜前几个字母就能出来中文名也支持按关键词匹配。实际用下来最理想的体验是把别名表优先匹配放在前面因为游戏这种实体是有主键的别名命中之后直接返回主记录体验非常干脆。3.2 评分口径归一化怎么比才不算作弊做评分对比的时候我纠结了很久。媒体评分满分是100用户评分满分是10有些社区的推荐指数又是百分比如果只是简单换算数值上看着对实际上掩盖了不同人群的评分习惯差异。我最后采用的方案是所有原始分照常展示不做换算对比视图里只做位次对比也就是把每个游戏在各自数据源里的百分位排名算出来再做横向比较。这么做的好处是诚实。媒体分85和用户分8.5本来就不是同一个参照系强行归一化成百分制会给人两者可比的错误暗示。百分位排名至少反映的是这个游戏在同类评分中的地位比直接算术换算要科学一点。3.3 价格历史与心愿单提醒收集价格数据是最容易让人上瘾的功能因为游戏打折活动经常出现昨天还是原价今天突然半价的情况。我给价格设计了一张独立的历史表每次采集时如果发现当前价格和历史表里最新一条不一致就插入一条新记录这样自然形成价格曲线。心愿单功能则是在本地跑一个定时任务每天检查一次心愿单里的游戏价格如果低于设定的阈值就推送一条桌面通知。这个功能技术上很简单难的是定时任务的频率把握。我试过每小时查一次结果一天能收到好几条无意义的变化通知后来改成每天早上九点检查一次只在跨天价格变化时才通知清净多了。核心原则是提醒功能要克制否则用户会直接把通知关掉。4. 存储层设计让几万条数据依然搜得快4.1 表结构设计的取舍游戏数据有个特点字段多但字段之间的关系相对简单。我最初打算用一个大宽表把一百多个字段全塞进去后来发现维护成本太高加一个新数据源就要改表结构。最终我拆成了五张核心表游戏主表、游戏别名表、评分表、价格历史表、发售状态表。游戏主表只存固定不变的元数据比如标题、发行商、类型、语言支持评分表按数据源拆行一游戏多源就是多行价格历史表按时间拆行做走势分析非常方便。这种主表瘦身、附属表扩展的做法某种意义上模仿了列式存储的思路虽然对单机工具来说有点过度设计但好处是后续加新数据源真的不用动主表结构。4.2 索引与全文检索的配置细节查询性能方面我最开始没建任何索引数据量到两千条的时候搜索就开始卡了。后来按查询习惯建了几个关键索引游戏主表的标题字段、别名表的别名文本、价格历史表的游戏ID和日期组合索引。全文检索用的是 FTS5 虚拟表同步维护一张独立的搜索索引表这样主表可以做其他操作而不会被全文索引拖慢。这里有个细节容易被忽略FTS5 的 tokenizer 对中日韩文本的处理默认并不理想。我的方案是给中文标题加一个额外的拼音字段配合trigramtokenizer这样中文输入和英文缩写都能搜到实测召回率提升非常明显。4.3 增量更新策略全量重爬是下策一开始我的更新策略很粗暴每周全量重爬一遍简单但效率低。后来数据量一上来全量重爬要跑一个多小时而且容易触发对方限流。我改成增量更新游戏主表只在有新游戏名单时追加评分表每天只抓那些发售日期在最近三个月内的游戏价格表则是全量扫一遍但只判断当前价与最新历史价是否一致不一致才写新记录。这种分层更新策略的收益在长尾数据上特别明显。老游戏评分早就不变了每天重抓纯属浪费新游戏的评分和价格则处于高频变动期需要更频繁地观察。把握好这个节奏之后整个采集任务的耗时从一小时降到了不到十分钟。5. 实测踩坑记录编码、重复数据与评分口径5.1 编码问题藏在页面里的隐形杀手爬虫最经典的坑就是编码。某个欧洲区商店页面HTML 里声明的是 UTF-8但实际正文里混着 Latin-1 编码的特殊字符用httpx默认逻辑解析重音字符全部乱码。这个问题排查了很久最后发现问题出在响应头里的charset声明和页面内嵌的meta charset冲突。我的解决办法是优先信任 HTTP 响应头的编码但如果检测到替换字符就回退用页面内嵌声明重新解码一次。这类问题用一句话总结就是永远不要假设页面说它是什么编码就是什么编码要以实际字节为准。5.2 一个游戏三个版本的去重难题重复数据是游戏数据库的老大难。同一个《XX传奇》存在标准版、豪华版、终极版三个条目评分站还把它们当作三个独立页面收录。如果直接入库搜索时会出现三条几乎一样的记录用户根本分不清该看哪个。我的去重方案分两步。第一步是归一化标题去掉豪华版限定版年度版这类后缀以及各种特殊符号得到一个基础标题第二步是用基础标题加发行年份做唯一键把这些版本归到同一组。主条目展示基础信息和媒体评分版本条目单独存价格和内容差异。这样搜索结果里只出现一条主记录展开后能看到所有版本的价格对比反而成了我后来最喜欢看的数据视图。5.3 评分不一致的调和策略保留差异而不是消灭差异做这个项目之前我一直以为媒体评分和用户评分应该是接近的实际抓完数据才发现有些游戏两者能差出三十分以上。一开始我很困惑甚至怀疑是自己清洗出错了后来想明白了媒体评分倾向于在相对短的时间内对游戏的整体设计品质做判断用户评分则混入了大量情绪因素包括服务器问题、价格争议、甚至版本更新的影响。两者的差异本身就是有价值的信息。所以我在详情页里做了一个分歧提示的小功能当媒体均分和用户评分的百分位排名差超过二十个百分点时会自动标注口碑存在分歧并列出两个来源各自的评论数。这个功能看似简单实际上很受用它把用户需要跨站对比才能看出来的信息变成了打开页面第一眼就能注意到的提示。6. 从命令行脚本到轻量Web应用AnyPS5 的进化路线6.1 为什么最终选择了服务端渲染数据跑通之后我最初只是用命令行输出表格但每次查个游戏都要开终端敲参数实在不够直觉。后来我盘算了一下自己的需求没有复杂交互、没有用户系统、不需要实时协作这种场景用服务端渲染的简单方案最合适。最终我选了 Python 的 FastAPI 加上一套轻量的 Jinja2 模板没有上前后端分离的重型框架。这个选择的核心逻辑是当你的主体工作是在数据层而不是交互层时引入一个完整的前端框架只会增加维护负担。服务端渲染让页面逻辑和数据查询放在同一个进程里开发效率高部署也简单一台小机器就能跑起来。6.2 接口设计里的一个小原则虽然我做了页面但后端还是顺手把查询能力抽成了 JSON 接口。设计接口时我坚持一个原则核心查询接口的参数只暴露用户真正会用的维度也就是关键词、类型、发售年份区间、评分区间、价格区间和排序方式。筛选条件太多反而会让接口难用对个人工具来说没有必要。搜索接口的响应结构我也刻意做得简单只返回 id、标题、基础评分、当前最低价和发售状态这五个摘要字段详细信息由详情接口单独返回。这样列表页的响应体很小即使是移动网络环境下打开也很快。6.3 部署与后续规划部署方面我没有折腾容器化直接在本地一台常开的迷你主机上用 systemd 托管进程数据目录放在外置存储上每天凌晨自动执行增量采集任务。这个方案足够稳定运行了大半年没出过问题。后续我最想做的两件事一是把数据导出功能做成开放格式这样即便哪天不想用 AnyPS5 了数据也能平移到别的工具二是给口碑分歧功能增加更多维度比如对比不同语言区用户对同一款游戏的偏好差异。说实话做这种个人项目的最大乐趣不在于功能多花哨而在于它每天都能帮你省下那十五分钟。写到这里回头看看这几周的经历最大的体会是做一个信息聚合工具真正难的从来不是写爬虫而是想清楚哪些数据该存、哪些数据不该混为一谈。AnyPS5 到现在也只是一个满足我个人习惯的小工具但每次更新完数据打开页面看到那些整齐的表格和曲线时我仍然会觉得当初给自己提的那个需求完成得还算不赖。