最近我把游戏相关的一堆零散信息从脑子里和表格里拎了出来整合成一个跑在局域网里的本地资料库小工具代号AnyPS5。起因特别朴素每次想开一个新游戏我都得先花几分钟去回忆这台主机还剩多少空间、某张光盘到底通关没有、存档上次备份是什么时候——答案经常是“忘了”。这几个问题看着小积累起来就是开电脑前先犯难的心理负担。AnyPS5 就是把“游戏库”这件事变成一张能查账的表让你不用反复开机翻设置。这中间没有任何复杂操作它是一个本地优先的 Web 应用数据库文件就是一个普通文件我随时可以把它复制出来当成备份。整个过程没有什么高深技术但几个关键设计让我用得很顺手下面把这套思路和踩过的坑都整理出来给同样想“把游戏库管起来”的人一个参考。1. 最初的痛点存储空间和游戏记录两本烂账1.1 为什么需要这样一个本地工具先说存储。这台主机内置硬盘听起来容量不小但装上几个大型游戏后你会发现剩余空间掉得飞快。大量数字版游戏下载完就躺在库里不玩的也占着位置删了又怕哪天想回去刷一刷光盘版表面上“不占网络下载”但插进去一样要完整安装安装体积并不比数字版小多少。我持续在这种“删了怕后悔不删没空间”的状态里拉扯。更让人头疼的是游戏记录。买过什么、玩到哪了、通关了哪些原来都靠记忆。可实际上我经常打开游戏列表看到一堆熟悉又陌生的封面心里想的是“这游戏我玩过吗玩到第几章了”还有一种情况是朋友推荐游戏时我根本想不起来自己库里有没有类似的没玩完。这种信息断层最终会转化成两个后果要么重复购买要么在游戏库选择上不断犹豫。1.2 从痛点清单到功能改造于是我把需求先写成了一个极简清单能登记每个游戏的基础信息标题、类型、数字版/光盘版、安装体积、当前状态。能记录游玩历史哪一天玩过、玩了多久、有没有通关。能追踪存档备份上次备份是什么时候、备份到哪个设备。能预估存储空间当前一共占了多少、如果再装一个游戏还剩多少。这些需求看起来很简单但“简单”恰恰是本地小工具的优势。我不需要账号、不需要会员、不需要一个运营团队维护的服务器。所有数据我自己掌控界面只为自己服务。AnyPS5 的核心价值不是提供什么惊天功能而是把过去散落在各处、只能靠回忆的信息变成随时可查、可统计、可提醒的本地资产。2. 技术选型我为什么坚定选择本地优先方案2.1 架构形态一个跑在局域网里的轻量 Web 应用动手之前我其实也纠结过要不要做一个小程序要不要接一个在线游戏资料库后来全部否掉了。小程序意味着要把数据放到别人的平台在线资料库又涉及接口稳定性和网络依赖一个周末写的小工具不应该承担这些外部风险。最终我选择了最朴素的方案一个轻量级后端服务搭配一个嵌入式数据库前端用常见框架搭了个简单界面整个服务跑在书房里的一台常开小主机上。手机、电脑只要在同一局域网内打开浏览器就能访问数据不出家门。这个架构给到了我三个很实际的收益断网可用家里的网络再怎么抽风工具照常使用。备份简单数据库就是一个文件复制走就是一次完整备份。隐私干净没有第三方服务器没有用户行为统计游戏库是我自己的资料。有人会觉得这不够“现代”但我自己越来越相信一个道理个人工具最重要的是可控而不是酷炫。云端方案确实适合需要多人协作、多设备实时同步的场景但对我来说只是为了管理一个主机游戏库本地优先是更轻、更稳的路径。2.2 技术栈取舍与替代方案对比为了不给自己挖太多坑我刻意把技术栈往“少而熟”上收敛。后端选择了我平时写脚本最顺手的语言和轻量框架只有一个服务进程和一个数据库文件前端也是一套表单加列表页没有引入复杂的状态管理库。这里我把几个常见组合拿出来对比一下方便你按自己的习惯调整方案数据存储上手难度适合场景轻量后端 嵌入式数据库单文件数据库低个人本地工具、单机局域网访问重型全栈框架 独立数据库服务独立数据库服务中高多人协作、复杂权限、长期迭代纯前端 浏览器本地存储浏览器 IndexedDB/localStorage低极简录入但跨设备麻烦云端应用云端数据库中多端实时同步但依赖运营方我给自己的结论是嵌入式的单文件数据库已经能覆盖 99% 的功能需求额外再上服务端数据库纯属自找麻烦。如果你不熟悉这层生态换成另一个脚本语言加嵌入式数据库的组合也完全成立逻辑是一样的数据文件本地存放服务只负责读写和简单统计。选型这件事重点不是追新而是知道约束条件在哪。3. 数据库设计与核心功能拆解3.1 四张表把游戏生命周期串起来AnyPS5 的数据结构最终收敛成四张表对应一个游戏从“进入视野”到“长期管理”的完整过程。核心的games表存的是游戏本体信息每次买新游戏或拆新光盘就是往里插一行play_sessions表记录每一次游玩而不是笼统地只存一个总时长backup_runs表登记存档备份行为日期由系统自动生成storage_devices表则用来记录主机内置硬盘和扩展硬盘的容量与剩余空间。下面是建表时的核心定义省略掉与主题无关的字段CREATE TABLE games ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, region TEXT, kind TEXT CHECK(kind IN (disc, digital)), install_size_gb REAL, size_factor REAL DEFAULT 1.15, installed_flag INTEGER DEFAULT 0, completion_status TEXT DEFAULT unplayed, cover_path TEXT, created_at TEXT DEFAULT (datetime(now)), updated_at TEXT ); CREATE TABLE play_sessions ( id INTEGER PRIMARY KEY AUTOINCREMENT, game_id INTEGER NOT NULL REFERENCES games(id), started_at TEXT NOT NULL, minutes INTEGER, note TEXT ); CREATE TABLE backup_runs ( id INTEGER PRIMARY KEY AUTOINCREMENT, game_id INTEGER NOT NULL REFERENCES games(id), backup_date TEXT NOT NULL, target_device TEXT, note TEXT ); CREATE TABLE storage_devices ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, total_gb REAL, free_gb REAL, kind TEXT, active_flag INTEGER DEFAULT 1 );为什么把“游玩记录”单独拆出来而不是在游戏表里直接累加分钟数因为追加记录才能保留时间维度。我可以回看某段时间玩了多少游戏、哪个游戏占了最多精力甚至可以知道“最近一周是不是又进入收集式游戏循环了”。这种统计需求在直接在games表上更新字段是做不出来的。同理备份记录也单独存只留一个“最近备份日期”字段的话审计和提醒逻辑都会变得别扭。3.2 游戏录入与资料导入的处理细节录入方式我做了两层。第一层是手动表单适合新买的游戏填标题、类型、安装体积、当前状态第二层是批量导入我维护了一个本地静态资料文件里面是常用游戏的基础信息导入时按标题匹配匹配不到的保留为草稿状态等有空手动补齐。当时一度想去接一个在线游戏资料库接口被两个现实问题劝退了一是很多游戏的安装体积会随补丁变化资料库数据未必及时二是接口有调用频率限制个人工具不值得为这个反复处理限流。比较关键的字段是install_size_gb和size_factor。前者记录该游戏在“当前版本”下的安装体积后者是我给每个游戏预留的额外系数。为什么要预留因为一款游戏从发售到后期更新体积大概率只涨不跌首日补丁、语言包、免费赛季内容都要占空间。我习惯在录入时直接按“标称下载体积 × 1.15”来估算给未来更新留一点余量总比实际撞上“差几 GB 装不下”要好。3.3 常用查询当前安装总量和预计剩余空间工具做好后我最高频使用的其实就两类查询。第一类是看当前安装的游戏到底占了多少 GB按从大到小排序方便决定先卸载谁。SQL 写出来是这样SELECT title, install_size_gb * size_factor AS estimated_size FROM games WHERE installed_flag 1 ORDER BY estimated_size DESC;第二类是“我想装一个新游戏装了之后还剩多少”。这种查询本质上就是把当前所有已安装游戏的估算体积加起来再用存储设备当前的剩余空间去减。你可以在界面里先选中一个待安装游戏看到“预计安装后剩余 XX GB”的提示。它不一定百分百精确但能极大减少“点下载才发现空间不够”的挫败感。SELECT (SELECT free_gb FROM storage_devices WHERE active_flag 1 ORDER BY id LIMIT 1) AS current_free_gb, (SELECT SUM(install_size_gb * size_factor) FROM games WHERE installed_flag 1) AS installed_gb;数据库层的价值就在这里一旦数据结构稳定很多以前需要靠“感觉”判断的问题现在一条 SQL 就有答案。4. 存储空间计算逻辑别被厂商标称容量骗了4.1 标称容量到实际可用容量的演化刚开始我用这个工具时在storage_devices表里填了一个“667GB”的数字当作内置硬盘容量。有朋友看到后问我主机不是说是 825GB 吗为什么只填了三分之二这其实正是存储管理最容易踩的第一个坑。厂商标称的“825GB”是十进制的销售话术而操作系统内部通常按二进制计算容量两边单位不一样。大致换算过程是这样的825.6 GB × 1,000,000,000字节÷ 1,073,741,824 ≈ 768.4 GiB 768.4 GiB - 约 101 GiB系统保留区≈ 667.2 GiB换句话说你看到的 667GB 不是“少了”而是十进制换算加上系统保留空间之后真正能用于安装游戏和存放资料的用户可用容量。系统需要预留空间给它的镜像、临时交换区和长期运行的数据这部分用户碰不到也不应该去动。所以AnyPS5 里填写的所有“可用空间”都应当以主机界面显示的实际剩余为准而不是用标称容量做减法。4.2 给游戏标注“安装体积”的实战模型有了“实际可用容量”这个口径还要解决另一个问题游戏商店页面显示的体积和真实安装后的体积往往是两回事。同一个游戏可能页面标着 60GB完整安装之后因为高清材质包和后续补丁涨到 75GB。所以我给自己定了一个比较保守但好用的模型预计安装占用 MAX(基础安装体积, 已累计的更新/扩展包体积) × 1.151.15并不是什么官方系数而是我根据多个游戏实际安装前后对比得出的经验值。实际操作中数字版游戏我优先看商店标注的下载体积添加 10% 到 15% 的余量光盘版则按“完整安装所需空间”录入而不是看光盘盒上的宣传体积。这套模型最大的意义是宁可高估不要低估。低估的结果是工具告诉你“还能装”实际却反复安装失败体验非常糟糕高估的代价不过是你提前清理了几个暂时不玩的游戏没有任何损失。在界面上我还会把“估算值”和“上次人工复核时间”并列展示。任何时候只要你发现某个游戏的安装体积明显变了就手动去资料库里改一次系统会把复核时间刷新这样每条数据的可信程度一目了然。5. 存档备份提醒用定时任务把习惯落地5.1 官方备份机制和我的提醒思路先明确一点AnyPS5 不会去碰游戏存档文件本身也不会用任何旁路手段尝试自动读写主机内部数据。存档备份这件事平台本身已提供了官方途径——你既可以把存档复制到 USB 存储设备也可以利用系统自带的网络存档功能。我的做法是在官方机制之外补上一个“什么时候该备份”的提醒层。这个提醒层不碰存档数据只负责记录备份行为和生成提示天然的合规且稳定。人才是这个流程里最容易出问题的环节。官方提供了备份入口不代表玩家真的会定期去点。很多时候想起来要备份了已经是重打了十几个小时之后。AnyPS5 的思路很简单每次手动备份完就在工具里点一下“登记本次备份”这一笔操作会写入backup_runs表。之后定时任务会周期性地扫这张表找出距上次备份时间超过阈值的游戏然后在界面上提示你该去插 U 盘或者检查一次网络备份了。5.2 具体实现本地定时任务与通知定时任务我用了一个很常见的调度方式每周日晚固定时间执行一次检查。核心逻辑大概长这样const rule 0 22 * * 0; // 每周日 22:00 schedule(rule, async () { const overdue getOverdueBackups(30); for (const row of overdue) { notify({ title: 《${row.title}》该备份了, message: 上次备份${row.last_backup || 从未备份}, }); } }); function getOverdueBackups(thresholdDays) { return db.prepare( SELECT g.title, MAX(b.backup_date) AS last_backup FROM games g LEFT JOIN backup_runs b ON b.game_id g.id WHERE g.completion_status ! abandoned GROUP BY g.id HAVING last_backup IS NULL OR julianday(now) - julianday(last_backup) ? ).all(thresholdDays); }关键在HAVING那一段如果一个游戏从来没有备份过last_backup IS NULL它一定会被扫出来如果上次备份太老超过阈值也会触发提醒。这样不漏掉新游戏也更符合“长期维护”的节奏。通知方式我没有做得很复杂就是浏览器通知加一个醒目的首页卡片毕竟工具是给自己用的能看见就够了。5.3 为什么我没有做“自动复制存档”有人可能会问既然都记录备份了为什么不干脆自动把存档复制到某个目录这里要明确一个边界主机平台对游戏存档访问没有开放可编程接口。任何想绕过这个限制去自动读写存档的文件本质上是走灰色路径既有不稳定风险也可能违反平台规则。我做的工具价值应该是“帮助你更好地使用官方功能”而不是去挑战平台边界。所以在 AnyPS5 里备份模块的定位始终是“提醒员”和“记录员”。它提醒你该备份了也帮你记住上一次是哪天、备份到哪个设备。真正打开系统菜单、插上 U 盘、确认备份成功这几步仍然是你自己手工完成的。这看起来没那么“自动化”但换来的是长期稳定和零风险放在个人小工具里非常划算。6. 踩坑记录三个意料之外的问题6.1 游戏中文名的排序问题第一个让我挠头的坑是游戏名排序。在默认情况下数据库对字符串排序是按 Unicode 码位来的英文标题问题不大但中文标题简直是按“字”的二进制顺序在排毫无拼音规律可言。第一次打开游戏列表我看到了一个按笔画和编码混合排列的名单视觉上就像乱序。解决办法是单独加一个sort_key字段。英文游戏直接用小写标题作为排序键中文游戏则在导入时生成一个拼音首字母键或者由我手工维护一小张映射表。查询时统一ORDER BY sort_key列表顺序就正常了。这个字段不用追求完美只要保证同类语言下的顺序符合直觉即可毕竟这个工具服务的不是我一个人的强迫症。6.2 跨平台路径分隔符的陷阱第二个坑来自文件路径。我最初是在 Windows 上填写备份目标路径习惯性地写了D:\PS5Backup结果程序读出来的字符串自己看着都奇怪怎么多了一个反斜杠。其实就是因为反斜杠在某些场景里会被当作转义符处理数据进到数据库之前已经被改了一次。从那之后我给自己定了一条规矩数据库内部只保存正斜杠路径展示到界面时再根据操作系统做一次转换。写个简单的归一化函数就能解决function normalizePath(p) { return p.replace(/\\/g, /); }这样换系统、换设备都不容易踩路径坑。很多个人工具的路径问题最后其实是格式不统一造成的统一存储格式比在每一处都小心翼翼转义更可靠。6.3 安装体积的数据口径问题第三个坑是前面提过的数据口径。我一开始从静态资料里导入了很多游戏的安装体积当时觉得挺齐全结果几个月后对照实际主机界面发现好几个游戏的估算占位已经明显低于真实安装体积。原因也不复杂游戏更新了大型补丁加了新语言包或者出了需要下载内容的版本。这件事让我意识到静态资料库可以省去录入成本但必须有时效性概念。于是我给所有容量记录加了last_verified_at超过三十天就把对应记录在界面上标黄提示“该复核了”。复核很简单去主机设置里看一眼实际安装体积改一下数字顺手点掉标黄。这比追求一个永远精准的数据集要现实得多也与个人工具的定位更匹配。7. 还能往哪走一点后续想法与实在体会7.1 可以想的扩展方向这个小工具目前已经够我日常使用但后续也没少想可以怎么折腾。如果物理光盘收集比较多可以给录入页面加一个条码扫描入口扫一下外盒条码再匹配本地资料库省掉输标题的麻烦如果常年在书房和客厅之间切换可以把 Web 服务包装成一个适合移动端浏览器访问的页面也就是做一层响应式改造如果希望每周都能看到自己玩了多久可以加一个简单的游玩周报页从play_sessions表里按周聚合数据。另外现在很多主机游戏都有多语言版本、不同销售区域和不同版本号。如果有闲心还可以为每个游戏加一个“版本别名”表用来处理跨区购买、年度版、完全版这些容易重复计算的特殊情况。这些想法都不难难的是保持数据更新习惯。工具毕竟只是工具使用者的维护节奏决定了它会不会废掉。7.2 我个人实操后的几句真心话AnyPS5 运行了一两个月之后我最大的感受是这类工具的价值不在于界面多漂亮、技术多前沿而在于你每一次做决定时都能有一个可信的数据依据。过去我想删一个游戏得先开机进设置再翻文件夹列表回忆半天现在打开工具按安装体积排个序哪些是“吃空间又没进度”的一眼就能看清。最后分享一个让我觉得特别值的小技巧每次买了新游戏或者拆了新光盘别等“有空再录”立刻录。录一条只需要不到一分钟但一旦拖到第二天大概率就忘了。时间久了你会发现真正让工具发挥作用的不是某一次大版本更新而是每天顺手记录的那几秒。这台主机可以陪你很久游戏库也一样值得一份清爽的台账。