AnyPS5：PS5游戏库管理与比价工具的设计与实现

如果你也和我一样，手里同时躺着实体盘、数字版、会免领过的游戏、订阅库里“借来”的一堆作品，那你迟早会撞上同一个问题：我到底拥有哪些游戏？哪个版本才是我真正想要的？现在哪个区服买最划算？去年年底我终于决定把这些账算清楚，结果光是整理一份清单就花了两个晚上。更要命的是，这份清单只活了一周——商店活动每周都在变，我记录价格的速度根本追不上打折的速度。在被反复折磨之后，我动手做了一个叫 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 / PS5+PS4 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 某赛车竞速游戏,豪华版,港服,PS5+PS4,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 目前还缺几个我明确知道有价值、但暂时没排期的功能。第一个是奖杯进度追踪，官方没有开放接口，社区有非官方的查询方式，但稳定性存疑，我不想为了这个功能破坏现有系统的简单性。第二个是多人协作，做成家庭内网共享后，同住的人可以用自己的视角标记“这个游戏我也在玩”，不过这又会引出账号体系，复杂度会明显上升，暂时搁置。第三个是移动端适配，现在只是勉强能用的响应式布局，真正舒服的使用体验还需要针对小屏专门调几版。

如果你也想复刻一个类似的东西，我最真诚的建议是：先把数据模型想清楚，再动手写代码。这个项目的复杂度几乎全部集中在“一个游戏版本到底由哪些属性唯一确定”这个问题上，这个问题一旦想通，后面的功能都是水到渠成。千万不要一上来就追求界面华丽或者算法高级，先把“能帮我把游戏库管明白”这个基本承诺兑现，其他都是锦上添花。