如果你也和我一样手里同时躺着实体盘、数字版、会免领过的游戏、订阅库里“借来”的一堆作品那你迟早会撞上同一个问题我到底拥有哪些游戏哪个版本才是我真正想要的现在哪个区服买最划算去年年底我终于决定把这些账算清楚结果光是整理一份清单就花了两个晚上。更要命的是这份清单只活了一周——商店活动每周都在变我记录价格的速度根本追不上打折的速度。在被反复折磨之后我动手做了一个叫 AnyPS5 的个人项目。它不是什么颠覆性的大系统就是一个跑在自家电脑上的 PS5 游戏库管理与比价工具覆盖从游戏入库、标签筛选到价格追踪的完整流程。这篇文章我会把整个项目的设计思路、数据模型、核心算法和踩过的坑原原本本写出来。不管你是想抄作业直接部署还是只对“怎么把一个混乱的需求收敛成可落地的系统”这件事感兴趣应该都能从里面找到点有用的东西。1. 为什么做 AnyPS5游戏库越攒越乱的真实痛点1.1 线下清单、手机 App、Excel 都不够用最开始我想得很简单用 Excel 拉一张表列名无非是“游戏名、版本、平台、来源、入手价格、游玩状态”。但真正动手后才发现游戏库管理的复杂度远超一张表能承载的范围。同一款游戏可能有标准版、豪华版、终极版还有 PS4 版和 PS5 版两个条目港服、日服、美服的名称和定价完全对不上我手里的实体盘和数字版又可能来自不同账号再加上会免入库、订阅库轮换这些动态状态单纯靠 Excel 的筛选和排序根本理不清。市面上也有一些现成的游戏管理工具和游戏论坛里流行的“个人游戏库模板”但它们的共性问题很集中要么依赖云端账号授权我不想把所有游戏记录交给第三方服务要么只能记录“我买了什么”完全做不到“哪个版本才是完整版”“现在哪里更便宜”这种查询还有一些工具只支持单一区服恰好我手上有多个地区的账号数据横跨好几个商店用起来非常别扭。调研一圈之后我基本确认了一个判断我需要的是一个我自己完全掌控数据的、支持多区服多版本的个人管理系统而不是一个“别人替我决定怎么管理”的 SaaS 服务。1.2 我把“需求”收敛成了三件事做项目最怕一开始就想着“我要做一个大而全的平台”。我给自己定了个原则只解决三个最高频的场景。第一件事是入库。我得能快速把手里堆积的实体盘、数字版、会免游戏录入系统并且自动识别出“这到底是哪款游戏的哪个版本”。第二件事是筛选。每次想开一个新游戏我要能按状态、类型、容量、入手来源筛选快速回答“我现在该玩哪个”。第三件事是比价与价格追踪。我记不住每个区服的历史价格也不想每次打折都靠肉眼去刷商店页面所以系统要能记录价格快照并在跌破我设定的心理价位时提醒我。想清楚这三点之后整个项目的边界一下就清楚了。AnyPS5 不需要做社交、不需要做云同步、不需要做奖杯统计它只需要把这件“我自己一个人用”的事情做到顺手。这也直接影响了我后面的技术选型。1.3 技术选型一台旧笔记本就能跑起来的轻量服务我的使用场景是单用户、家庭网络、日常开机常驻所以没有引入重型框架最终选型是 FastAPI SQLite Vue 3整套东西跑在一台旧笔记本上。选 FastAPI 的原因很简单异步支持好、自带数据校验、生成接口文档不需要额外配置而且我只需要提供几个 JSON 接口给前端调用根本用不着上 Django 这种全家桶。SQLite 的决策是经过反复掂量的。有人可能会说“SQLite 不适合做正经项目”但在 AnyPS5 这个场景里它几乎是完美选择单文件部署、零守护进程、备份就复制一个文件读取性能在几千条游戏数据量级下完全够用。我唯一做的额外设置是开启 WAL 模式避免后面加价格快照时频繁写入导致锁等待。前端用 Vue 3 加一个轻量组件库页面只有三个核心视图游戏库列表、价格追踪页、入库编辑弹窗。没有状态管理库没有路由懒加载的过度设计组件之间靠自定义事件传数据就够用了。说实话这种“一个人用的工具”复杂度基本都在数据逻辑上不在界面上前端做得越克制后面维护越轻松。2. 数据模型与版本匹配AnyPS5 的地基2.1 为什么“游戏”和“版本”必须是两张表这是我在设计阶段踩的最重要的一个思维陷阱。一开始我只有一张games表打算一列一个游戏。结果录入第三个游戏时就发现不对劲一款作品同时有 PS5 标准版、PS5 豪华版和 PS4 版商店里它们的价格、内容、价格快照完全独立如果硬塞在同一行里要么有很多空字段要么得为每个版本单独建一行然后重复填写游戏标题。正确的做法是把“游戏”和“版本”拆成两个实体。游戏只存“这到底是个什么作品”比如中文名、英文名、系列、年份版本才存“这个可购买/可拥有的具体条目”比如所属区服、平台、版本类型、商店内容 ID、安装大小。这个拆分带来的好处是一个游戏下可以挂任意多个版本价格是挂在版本上的库里拥有的也是版本而不是抽象的游戏。后来我发现这个模型还天然解决了“会免入库”“订阅库”“实体盘”“数字版”混在一起的问题——因为它们本质上是同一个版本的不同拥有来源而不是不同的游戏。比如我既买了某部作品的数字版又在订阅库里玩过它的 PS5 版这两个记录可以同时存在互不干扰。2.2 表结构设计与入库流程最终落地的表结构比最初设计的精简了不少核心就五张表游戏表、版本表、库条目表、价格快照表外加一个标签表。下面这个精简版 DDL 基本反映了设计思路CREATE TABLE games ( id INTEGER PRIMARY KEY, slug TEXT UNIQUE, title_zh TEXT, title_en TEXT, title_other TEXT, series TEXT, release_year INTEGER ); CREATE TABLE editions ( id INTEGER PRIMARY KEY, game_id INTEGER NOT NULL REFERENCES games(id), region TEXT NOT NULL, platform TEXT NOT NULL, -- PS5 / PS4 / PS5PS4 edition_name TEXT, -- 标准版 / 豪华版 / 终极版 ps_store_code TEXT UNIQUE, -- 商店内容 ID language_type TEXT, -- 中文版 / 日英版 等 install_size_gb REAL, added_at TEXT DEFAULT (datetime(now)) ); CREATE TABLE library_items ( id INTEGER PRIMARY KEY, edition_id INTEGER NOT NULL REFERENCES editions(id), source TEXT NOT NULL, -- digital / disc / psplus / extra / trial status TEXT NOT NULL, -- backlog / playing / completed / platinum bought_price REAL, bought_date TEXT, notes TEXT ); CREATE TABLE price_snapshots ( id INTEGER PRIMARY KEY, edition_id INTEGER NOT NULL REFERENCES editions(id), price REAL NOT NULL, original_currency TEXT NOT NULL, recorded_at TEXT NOT NULL, timezone TEXT NOT NULL, UNIQUE(edition_id, recorded_at) );入库流程我设计成“先查重、再补全、后确认”三步输入一个标题后系统先在本地已有的游戏里做模糊匹配如果命中就直接展示这个游戏下已有版本没命中就先创建游戏条目再要求补充版本元数据。这样做的好处是没有把“录入”做成一道填空题而是做成了“选择与确认”实际操作速度比想象中快很多。2.3 标题归一化与模糊匹配算法标题匹配是整个项目里最容易被低估的部分。表面上“把两个名字比较一下”很简单实际上游戏标题的变体五花八门。简体中文、繁体中文、英文、日文片假名、带版本后缀、带发售年份、带“数字版”字样……如果把原始字符串拿去做精确匹配命中率大概只有六成。我的做法是分几步走。先用正则把所有标点、空格、连字符去掉再统一字母大小写然后剔除掉一批常见版本后缀词最后对剩余字符串计算相似度。这里的核心思路是先做信息压缩再做相似度比较不要拿原始字符串直接比。import re from difflib import SequenceMatcher VERSION_SUFFIXES [ standard edition, deluxe edition, ultimate edition, complete edition, remastered, 年度版, 豪华版, 终极版, 数字版, 完全版, ] def normalize_title(raw: str) - str: s raw.strip().lower() # 去标点、空格、连字符但要保留中文字符 s re.sub(r[^\w\u4e00-\u9fff], , s) for suffix in VERSION_SUFFIXES: s s.replace(suffix, ) return s def title_similarity(a: str, b: str) - float: na, nb normalize_title(a), normalize_title(b) if not na or not nb: return 0.0 return SequenceMatcher(None, na, nb).ratio()说实话SequenceMatcher的编辑距离算法效率不算高但我的数据量只有几千条入库时做一次全库扫描也就几十毫秒完全没必要上向量检索那套东西。如果你后续想把规模做得更大可以把归一化后的标题直接存成字段并加索引查重速度能再上一个台阶。3. 三件核心功能的实现细节3.1 一键入库从 CSV 到筛选清单手工一条条录入终究太慢所以第二版我开始支持批量导入。方法是从商店账号的订单记录和库里手动导出成 CSV再用一个固定格式导入。格式如下title,edition,region,platform,source,status,price,date 某开放世界动作游戏,标准版,港服,PS5,digital,backlog,398.00,2024-11-02 某赛车竞速游戏,豪华版,港服,PS5PS4,psplus,playing,0.00,2024-11-02导入时后端会逐行调用查重逻辑。对于 CSV 里的每一行先用标题找出对应游戏再用“区服 平台 版本名”定位具体版本定位不到就自动创建。为了防止误建重复版本我会在导入报告里把“新增游戏 / 新增版本 / 匹配已有版本”三类结果分开统计让用户检查一遍再提交。这套流程跑通之后我的 200 多款游戏只用了不到半小时就全部入了库。这也是 AnyPS5 第一个让我觉得“做对了”的瞬间之前我靠 Excel 整理了一大半剩下的全部移交给了自动匹配。3.2 价格快照与折扣提醒价格追踪是这个项目里最“实用”的功能也是最容易失控的功能。PS Store 没有一个稳定可靠的官方公开比价接口靠爬虫抓商店页面又脆弱且不优雅所以我选择了“社区手动快照”的方案用户可以每周手动录入一批价格也可以导入社区共享的折扣汇总表。系统只负责记录和提醒不主动去抓取任何商店数据。这样既保证数据来源可控也不会让自己陷入爬虫维护的泥潭。每个价格快照必须带三个信息价格、币种、记录时刻的时区。这一点后面会专门展开讲因为它是踩坑最深的点之一。折扣提醒的逻辑是给每个库条目设定一个“心理价位”当新快照价格低于心理价位时在首页提醒区弹出条目并把最近几次的价格变化整理成一行趋势描述比如“比上次记录便宜了 120比历史最低价高 30”。3.3 硬盘容量规划与库容提示这个功能是我临时加的但用下来反而成了使用频率最高的功能之一。PS5 的内置存储空间说大不大说小不小经常面临“删哪个游戏好”的灵魂拷问。我在版本表里增加了install_size_gb字段录入时顺手填一下有些版本甚至可以直接从商店页面复制。界面右上角会实时汇总“当前游玩中”和“待玩但没删”的条目占用总容量再对比主机剩余容量给出提示。比如显示“已安装游戏占用 412GB内置剩余 250GB你还有 6 个待玩游戏的安装包可以保留”。这个数据看起来简单但它把“游戏库管理”从虚拟的目录维护变成了和硬件容量直接挂钩的实用建议用起来非常有实感。4. 实测踩坑标题、时区与汇率的三个大坑4.1 同一款游戏的“十种名字”我最初天真地以为标题匹配做好归一化就够了直到真正跑起来才发现游戏标题的混乱程度远远超出字符串处理能解决的范畴。同一款游戏在港服和日服的英文名可能是同一个但中文译名一个是“繁体直译”、一个是“音译加副标题”欧美区还会把副标题提到主标题前面或者干脆只保留 IP 名加年份。举个我实际遇到的例子某系列动作游戏的第三部在港服叫“某系列第三部”在美服叫“某系列 III”在日服还有一套完全不同的片假名音译。这三个名字做归一化之后再算相似度得分都不到 0.5根本匹配不上。“先算相似度、再靠人肉确认”的方案在这种场景下会频繁弹确认框用起来很烦躁。我的解决方案是引入一张同义词对照表把同一游戏在不同区服的名字、中英文译名、常用缩写都登记进去。匹配时先查对照表命中就直接关联查不到才走相似度计算。每当我手动把一个新标题关联到已有游戏时系统会自动把这个对应关系写入对照表。换句话说这个表会越用越准形成一个人工维护的“区服译名词典”。提示不要让模糊匹配算法承担“理解语义”的责任。算法负责找到候选人工确认负责建立可信映射两者配合才是实用方案。4.2 折扣刷新时间和夏令时的错位价格追踪最大的坑不在价格本身而在“这条记录到底是哪个时区的哪个时刻”。我曾经在一个周末把手头某款游戏的价格记录了一遍结果周一再看趋势图发现数据点全部错位了半天原因是我记录时用了本地时间而 PS Store 区域的折扣切换时间是另一个时区。这个问题的影响是隐性的如果价格快照的时间口径不一致就完全无法判断“这次打折是从什么时候开始的”也没法和历史活动对比。我的解决办法是在price_snapshots表里强制要求timezone字段记录时刻一律用带时区信息的 ISO 8601 字符串存储展示时才转换成本地时区。另外我把每周手动记录统一安排在固定时段比如“每周四晚后”因为亚洲区商店的折扣活动基本稳定在那一天附近更新固定节奏能让快照数据在时间轴上均匀分布。如果你所在时区有夏令时切换还要额外注意datetime和date的混用问题。我的经验是数据库里一律存 UTC界面显示再转换成本地时间避免“午夜数据突然变到前一天”这种难以排查的怪问题。4.3 比价时汇率到底该怎么算比价功能的初衷是想回答“同一个游戏在哪个区服买最便宜”但一旦涉及不同币种汇率就成了绕不开的问题。港服标港币、日服标日元、美服标美元、欧服标欧元直接比数字没有意义。最开始我简单地在每次展示时调用实时汇率接口换算结果发现价格每天都在变某个游戏今天比完是港服便宜明天因为汇率波动就变成美服便宜。这种“结论不稳定”的比价没有任何决策价值。后来我改成“快照汇率”的方案每次录入价格快照时同时记录当时的汇率快照比价和趋势展示都用这条汇率换算。这样比价结果只在有新快照时才会更新不会因为外部汇率波动而产生虚假的价格差异。如果你是给自己用我的建议是不要追求“绝对真实”的比价结果而是要追求“口径一致”的比较。只要所有历史价格都按同一套汇率换算规则计算趋势和排序就是稳定可用的。汇率本身的误差在游戏比价场景下完全可以接受。5. 用了半年后的实际收益与后续扩展5.1 我的 200 多款游戏终于有了“单一事实来源”AnyPS5 跑了半年多最直观的收益是我不再需要动用大脑内存去记“我买过什么”了。想找某款游戏直接搜索想知道某个系列还差哪一部没玩筛选系列字段想趁着打折补齐库里的第几部看一眼价格趋势就知道历史最低大概是多少。更重要的是这个系统帮我养成了一个习惯每次买游戏前先查 AnyPS5再决定买不买。以前我经常会重复购买同一个游戏的多个版本——比如明明已经有 PS4 光盘版打折时又买了 PS5 数字版现在入库时一眼就能看到版本冲突和来源标注重复购买的情况基本绝迹。粗略算下来光是避免重复购买省下的钱就抵得上做这个项目投入的时间成本。还有一个意外的好处因为系统里记录了“入手时间”和“游玩状态”我可以输出一份年度的“买了多少、玩了多少、白金了多少”统计报告。虽然只是几张简单的折线图但看着自己一年的消费习惯和游戏习惯被量化有一种实实在在的“掌控感”这是单靠游戏的成就感给不了的。5.2 未来想补的方向AnyPS5 目前还缺几个我明确知道有价值、但暂时没排期的功能。第一个是奖杯进度追踪官方没有开放接口社区有非官方的查询方式但稳定性存疑我不想为了这个功能破坏现有系统的简单性。第二个是多人协作做成家庭内网共享后同住的人可以用自己的视角标记“这个游戏我也在玩”不过这又会引出账号体系复杂度会明显上升暂时搁置。第三个是移动端适配现在只是勉强能用的响应式布局真正舒服的使用体验还需要针对小屏专门调几版。如果你也想复刻一个类似的东西我最真诚的建议是先把数据模型想清楚再动手写代码。这个项目的复杂度几乎全部集中在“一个游戏版本到底由哪些属性唯一确定”这个问题上这个问题一旦想通后面的功能都是水到渠成。千万不要一上来就追求界面华丽或者算法高级先把“能帮我把游戏库管明白”这个基本承诺兑现其他都是锦上添花。