AnyPS5这个工具，最初只是我给自己做的“游戏库整理夹”。玩了不少年的玩家应该都有同一种体验：大促或者多平台买买买之后，库里越堆越多，有的听说评分高买来压箱底，有的和朋友开过两局就吃灰，还有的纯粹因为封面好看顺手加购。等到真坐下来想开新坑、或者想找个人联机，看着一屏一屏的列表反而下不去手。于是我把“整理游戏”这件事做成了一个独立的小软件，用着用着觉得可以开源，就把它打磨成了现在的AnyPS5。
它解决的核心问题很简单：把你已经拥有的、想玩的、适合和谁一起玩的游戏，用离线优先的方式统一管理起来。不搞社区、不做云端绑定、不碰账号密码，数据全部躺在本机。适合那些游戏库存量超过几十款、开始觉得“找游戏比玩游戏还累”的人，也适合想在两台电脑之间迁移游戏清单的人。下面聊聊这个项目从想法到落地的完整过程。
1. 项目缘起：当“已购清单”变成负担
1.1 存量游戏的管理成本被严重低估
我大概是过了某个临界点才意识到这件事的。起初几十款游戏时，记住自己有哪些游戏并不难，无非是“最近在玩的”“上次通关的”“一直没动的”三堆。可当库里的条目接近三位数，并且分散在实体盘和数字版之间时，记忆就开始不可靠了。经常出现的情况是：朋友问有没有某款联机游戏，我只能先翻一遍列表；想找一个特定类型的游戏时，得来回切筛选页，最后还要上网确认封面长得像不像。
这种成本被我称为“存量游戏的管理成本”。一旦超过临界点，它的优先级会悄悄超过游玩本身。我后来复盘时发现，真正的需求不是“把所有游戏信息整理得无比完整”，而是两个高频动作：第一，“我现在想玩什么”；第二，“我想玩的时候能不能少花两步找到它”。AnyPS5的初始定位就是从这里来的。
1.2 现有方案要么太重、要么留不住数据
动手之前我也试过几种常见做法。手写表格最自由，但补封面、补类型、补评分全靠手动，更新几次就懒得维护了；在线游戏库应用功能很全，但要求注册登录、把数据放在别人服务器上，一旦服务调整或者你换了平台，导出又不给力；还有些社区维基虽然资料丰富，却只是“别人的数据库”，和个人清单融合不到一起。
这些方案放在一起，问题就很清楚了。
| 方案 | 优势 | 痛点 |
|---|---|---|
| 手写表格 | 零门槛，数据完全属于自己 | 录入和维护成本高，封面、类型、玩伴关系基本无法管理 |
| 在线游戏库App | 功能丰富，资料自动补全 | 账号绑定、云端依赖、导出受限 |
| 社区维基/导航站 | 资料全、更新勤 | 和个人收藏结合弱，离网不可用 |
AnyPS5 | 离线优先、可迁移、数据本地保存 | 需要自己在第一次导入时花几分钟 |
我意识到，真正缺的不是“更大的游戏资料站”，而是“一个能装下个人选择和社交关系的本地收纳箱”。游戏资料可以从公共数据源临时拉取，但“我为什么买了它”“它适合和谁玩”“我上一次开它是什么时候”这类数据，只存在于我的脑子里和本地操作里，这些才是需要被认真记录的东西。
1.3 明确边界：我做的是“本地优先的个人游戏管家”
所以从第一版开始，AnyPS5就有几条固定的边界：不登录、不联网也能完整使用；所有数据使用本地数据库；外部数据源只做“锦上添花”，抓不到就留空，绝不阻塞操作；支持一键整体导出，换电脑后导入即可还原。这个产品定位一直沿用到正式版，每次有人建议我加“云同步”或者“好友社区”时，我都会拿这几条边界来挡回去——加了它们，AnyPS5就不再是它了。
2. 核心功能拆解：用三个高频场景驱动设计
2.1 游戏库导入与元数据补全
AnyPS5的第一个核心模块是游戏库导入。考虑过直接读取主机内置的应用数据，但很快就放弃了这个方向：一方面用户自己无法安全获取到游戏列表文件，另一方面这也碰了系统边界，容易出事。最终采用的方式极其朴素：用户主动把平台商店里的已购条目复制成文本或导出成 CSV，然后把这份“游戏标题清单”交给AnyPS5。
导入后，内部会跑一条清洗管道。第一段是标准化：把全角字符转半角、统一括号与分隔符、把大小写归拢；第二段是匹配：先做精确匹配，匹配不上的再走模糊匹配，用关键词权重和编辑距离算得分；第三段是人工确认：置信度低于阈值的条目进入“待核对”列表，由用户手动归并。
这个流程跑下来后，游戏会自动补上封面、类型、玩家人数、是否支持本地合作，以及大概是哪一年发布的。第一次导入完成时，看到几百个条目被自动归置得整整齐齐，那种“终于有人替我收拾书架”的感觉真的很解压。
2.2 愿望单与“想玩的理由”
一开始我就想做一个和普通愿望单不一样的东西：除了记游戏名，还要记录“想玩的理由”。这是有很多真实场景的——比如哥们的固定队正缺一个辅助，那我想玩的理由就是“和朋友补位”；再比如看了一段实况被某款高难度动作游戏吸引，那理由是“想挑战自己”。理由一记，愿望单就有了温度，不再是一个干巴巴的价格列表。
愿望单的状态机也很简单：想玩、已加入愿望、已购买、已通关。价格提醒被做成了一个可选插件，默认关闭。因为项目坚持离线优先，我不会默认让程序在后台到处采集价格信息。如果你愿意，可以开一个定时任务去拉公开的价格历史数据，给自己一个买入参考。但核心永远是：你因为什么想玩它。
2.3 组队场景：玩伴档案与约局计划
第三个被高频使用的场景是组队。以前想约人联机，得先知道对方有没有这款游戏，再想上次一起玩是什么时候，还要考虑时区方不方便。这些信息分散在聊天记录和记忆里，每次约局都是一次“信息考古”。
AnyPS5的玩伴档案夹解决了这个痛点。每个玩伴可以记录常驻时区、常玩类型、最近一次一起玩的日期；每款游戏可以挂一个“约局计划”，包含计划日期和备注。这样打开任意一款联机游戏，就能一眼看到“上次和谁玩的”“下次计划哪天”。对固定队玩家来说，这个模块几乎成了整个工具里使用频率最高的地方。
3. 技术选型与数据结构：离线优先是怎么落地的
3.1 从 Electron 到 Tauri：为了包体积做出的抉择
AnyPS5第一版跑在 Electron 上，说实话，开发效率真的高，前端生态里的东西都能直接用。但有个无法回避的问题：一个看起来这么轻量的桌面工具，安装包动辄上百兆，冷启动内存占用也不低。作为一个“收纳箱”性质的工具，这个体积实在不像话。
后来我对比了几个跨平台方案：
| 方案 | 包体 | 内存占用 | 开发效率 | 适合场景 |
|---|---|---|---|---|
| Electron | 大 | 较高 | 高 | 功能复杂、生态依赖多的桌面应用 |
| Tauri | 小 | 低 | 中，需要碰 Rust | 对体积和资源占用敏感的工具类应用 |
| Qt 等原生方案 | 中 | 中 | 中 | 想深度定制原生 UI、短期不换语言 |
| PWA | 取决于浏览器 | 中 | 高 | 在线场景为主，离线能力受限 |
最终把核心逻辑迁移到 Tauri。迁移成本确实有，尤其是我并不擅长 Rust，一开始光是把文件读写和数据库调用接好就花了不少时间。但换来的是安装包体积大幅下降，空闲时内存占用也肉眼可见地变低了。对AnyPS5这种工具型应用，我认为这个取舍是正确的。
3.2 SQLite 作为“唯一事实来源”的表结构设计
离线优先最重要的一点，是必须有一个明确的“唯一事实来源”。AnyPS5把这一职责交给本地 SQLite 数据库。所有界面只是它的查询视图，所有操作都通过数据层写回数据库。外部数据源的抓取结果只作为临时增强数据，不会覆盖本地已确认的内容。
核心表结构并不复杂：
CREATE TABLE games ( id INTEGER PRIMARY KEY, raw_title TEXT NOT NULL, normalized_title TEXT NOT NULL, cover_path TEXT, genres TEXT, players_support INTEGER, supports_local_coop INTEGER DEFAULT 0, release_year INTEGER, source TEXT DEFAULT 'manual' ); CREATE TABLE wishlist ( id INTEGER PRIMARY KEY, game_id INTEGER NOT NULL REFERENCES games(id), reason TEXT, status TEXT DEFAULT '想玩', max_budget REAL, added_at TEXT NOT NULL ); CREATE TABLE companions ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, timezone TEXT, preferred_genres TEXT, last_played_at TEXT, notes TEXT ); CREATE TABLE sessions ( id INTEGER PRIMARY KEY, game_id INTEGER NOT NULL REFERENCES games(id), companion_ids TEXT, plan_date TEXT, note TEXT );索引方面，games(normalized_title)和sessions(game_id)是查询热点，我会单独建索引。玩伴和约局计划虽然表不大，但联查频率也不低。整套设计的原则是：宁可写查询时拼更多的表，也不要为了“标准范式”拆出大量关联不明显的中间表。
3.3 离线不等于断网：数据同步与导入导出策略
离线优先不代表完全拒绝网络。封面图片、评分、价格这类信息，可以联网获取，但获取失败时要优雅降级。AnyPS5的策略是：所有远程数据先写进临时存储，校验通过后再进入正式展示；如果网络不可用，界面依然可以完整浏览本地清单。
导出与导入也按照同样的思路设计。导出时把 SQLite 和封面缓存打包为一个 zip 文件；导入时先解压到临时目录并做完整性校验，校验通过后再替换当前数据库，同时保留旧的库文件以防出错。这套机制看起来不复杂，但它让“换电脑”这件原本很痛苦的事变成了“导出一次、导入一次”两个动作。
3.4 封面缓存与缩略图：容易被忽略的体验细节
很多人第一次用AnyPS5时会奇怪：为什么几百款游戏有封面，但加载很快？秘密在于封面处理和缩略图缓存。游戏库封面原图往往很大，直接塞给界面渲染会造成严重卡顿。实现上，程序会在下载封面时生成一份约 300 像素宽的 JPEG 缩略图，列表只渲染缩略图，大图只在详情页按需加载。
缓存文件用内容哈希命名，比如a3f2b8c9d1e2f4.jpg，这样同一张图片绝不会重复存储。导入导出时，缩略图也会包含在备份 zip 里，即使换电脑后暂时离线，封面也不会全部消失。这件事不写进 README 没人会注意，但它直接决定了“看起来”有多流畅。
4. 开发过程中踩过的五个坑，以及我是如何填平的
4.1 标题清洗：统一格式远比想象中麻烦
第一次把真实列表导入测试时，我盯着“待核对”列表愣住了：里面躺着大量明明看上去很像，却不能自动匹配的条目。比如“某某游戏：终极版”和“某某游戏 终极版”，一个用中文冒号，一个用空格；“某某游戏 VOL. 1”和“某某游戏 Vol.1”大小写和空格又不一致；地区版本也会造成差异，一处叫“豪华版”，另一处叫“Deluxe Edition”。
后来我把清洗规则拆成几个小阶段才慢慢稳住：先做字符标准化，把全角半角、中文标点、注册商标符号全部统一；再做 token 级处理，把空格、冒号、连字符都看作分隔符；最后维护一张“通用后缀词表”，像“终极版”“年度版”“豪华版”“Vol.1”这类词在匹配时不参与权重计算。
关键技巧是保留原始标题，这一点很重要。清洗后的标题只用于匹配，永远不要把原始文本覆盖掉。这样即使某天规则改了，也不会丢掉用户最初录入的信息。
4.2 千款游戏的列表渲染：虚拟滚动救了大命
游戏库超过五百条之后，一个非常现实的问题出现了：一次性渲染所有卡片，界面直接卡成幻灯片。更别提封面图片是异步加载的，滚动时图片闪烁、空白占位，体验非常糟。
解决办法是引入虚拟列表。核心思路很简单：只渲染视口区域内能看到的那一部分卡片，上下各加一段缓冲区，滚动时动态回收和创建 DOM 节点。实测一千条游戏、每条带缩略图，DOM 节点数量稳定在四十个左右，滚动帧率终于恢复正常。
这里有一个容易踩的细节：虚拟列表要求每一项的高度是固定的，否则滚动位置会乱。我在卡片设计上强制统一了高度，标题超长就省略号截断，缩略图尺寸也统一裁剪。封面图加载失败时，用一个无图占位块兜底，防止高度被撑开。
4.3 多窗口状态同步：单向数据流治好了我的分散焦虑
AnyPS5有主窗口、详情窗口、设置窗口。早期版本里，每个窗口各自维护一份状态，结果经常出现这种诡异场景：在主窗口把一款游戏标记为“已购买”，切到详情窗口刷新后却还是“想玩”。原因很直白——两边的内存数据不同步，又没有及时重新读取数据库。
从那次教训之后，所有 UI 状态开始走固定的单向数据流：操作触发 action，action 更新中心状态，所有窗口订阅同一份状态。窗口之间不再直接通信，只通过状态层转发。这样一来，任何一处修改都会立刻反映到所有界面，状态不同步的问题彻底消失。
4.4 包体积减重：也算一次“断舍离”
Electron 版的安装包大小让人有点难堪，明明功能不重，体积却快赶上大型 IDE。第一轮减重只做常规操作：删除无用的 locale 文件、开启 asar 压缩、把静态资源中能放 CDN 的挪走，体积从接近两百兆降到了一百兆上下。
真正质的改变来自迁移到 Tauri。Rust 侧没有自带 Chromium 和 Node 运行时，安装包直接缩到原来的四分之一甚至更低，内存占用也降了一个量级。我不建议所有项目都盲目迁移，但如果你的应用是工具型、对体积和启动速度敏感，Tauri 确实值得认真考虑。
4.5 敏感数据的边界：账号凭证不进数据库
从产品设计第一天我就明确了一点：AnyPS5不读取主机账号密码，更不会绕过任何官方机制去抓取数据。用户提供的是“游戏标题清单”这种主动导出的信息，它只是文本。与之配套，本地数据库也做了可选加密，使用系统级钥匙串来保护数据库密钥。导入清单时，程序会提示用户不要在公共电脑上保留导出文件。敏感数据的边界划清楚之后，很多安全问题其实就不会发生了。
5. 实测反馈与后续规划：工具做得轻，才不会被抛弃
5.1 一轮小范围内测之后的真实数据
项目做到可用版本后，我找了几位不同系统的朋友做了一轮小范围内测，覆盖 macOS、Windows 和 Linux。测试用的样本库大概包含五百个游戏标题，第一次导入后自动匹配率约 87%，剩下的条目在“待核对”列表里手动处理了一轮，最终准确率到了 98%。启动速度在冷启动场景下基本压在 1 秒以内，虚拟滚动和大图懒加载上线后，千级库的滚动没有明显掉帧。
反馈中最有意思的一条是：能不能把整个游戏库导出成 Excel 格式。原因是一位朋友想在临时表格里做一个“年度通关统计”，我觉得这个需求很真实，就把它排进了后续功能列表。这类来自真实使用的需求，比我自己闭门想出来的任何功能都有价值。
5.2 迁移与备份：一条命令带走全部数据
备份恢复功能是好朋友反复提醒后我才痛下决心做的。最初只是导出数据库文件，后来发现封面图片散落各处，换电脑重装时依然难受。现在完整的流程是这样：
anyps5 export ./backup.zip anyps5 import ./backup.zip导出命令会把数据库、封面缩略图和配置文件一并打包，并在包里写入一个校验文件，避免压缩包中途损坏导致导入失败。导入时程序会先备份当前库，再跑临时目录校验，最后才切换正式数据。操作起来几乎无感，但安全感很足。
5.3 下一步想做的事
功能清单上排在前面的是数据看板和自定义标签。看板想做的事情很简单：按类型、按游玩状态、按年度做一个本地聚合统计，不需要上传任何数据，所有图表都在本地生成。自定义标签则会引入一套多对多的标签关系，让玩家按自己的习惯建立“肉鸽”“刷刷刷”“陪娃玩”这类私人的分类方式。
另外，清洗规则目前对欧洲地区和亚洲地区的命名差异支持还不理想，我打算把不同语言地区常见的版本词做一个更完整的词表，也欢迎有同样兴趣的人提交规则。
5.4 这不是一个“管理成瘾器”
最后聊一点个人的产品反思。做这个项目越久，我越警惕一个倾向：把工具本身做成一种“自嗨型收集游戏”。很多管理类工具做大了以后，用户不是在用工具帮助游玩，而是在用整理行为的成就感替代游玩本身。为了避免这个问题，AnyPS5刻意没有设计成就系统，也不鼓励花大量时间维护资料卡片。所有操作都围绕最核心的那几件事：记录已有什么、想玩什么、和谁玩。如果你发现自己花两小时整理清单却只玩了十分钟，那就该关掉工具去开游戏了。
项目开发到这里，聚合了很多零散的真实需求，也留了一些我并不急着填满的空白。它无关宏大叙事，只关乎每个玩家心里那个“等我有空就玩”的角落，我希望它能像一个安静的收纳架——平时不打扰，想找东西的时候永远都在。
