1. 为什么我决定给PS5做一个本地数据管理台
先交代一下背景。我自己算是一个主机游戏老玩家，PS5从首发折腾到现在也有几年了，游戏库越攒越多，数字版、实体盘、会免、试玩版混在一起。某个周末想找一款之前玩了一半的游戏，翻了半天商店和内容保存库，愣是想不起来它叫什么名字，只记得"封面是蓝色的""主角好像是个机器人"。这种体验来一次两次还行，次数多了真的憋屈。
当时市面上其实有现成的游戏管理App，但用下来总有几处不对味。有的是纯英文界面，中文游戏名识别一塌糊涂；有的必须绑定线上账号才能同步数据，等于把我的游戏习惯交给第三方服务；还有的只是套壳浏览器，打开慢，操作卡。我一个做后端开发的人，越想越觉得这事不该将就，干脆自己动手搓一个本地优先的游戏数据管理台。这就是这个项目的起点——它不是一个大厂产品，就是一个玩家给自己写的趁手工具。
项目做下来，核心要解决的问题分成了四块：一是把散落的游戏库信息归拢到一个本地数据库里；二是能追踪每款游戏的游玩状态，包括进度、时长、通关情况；三是做一个有实用价值的购物清单和价格记录模块，告别"等打折等到忘记"的窘境；四是最后用直观的统计面板把整个库的数据变成可视化的报告。
这个工具的技术选型也贯彻了"本地优先"的思路。后端用轻量的Node.js加上SQLite，前端直接就是原生HTML加JavaScript的静态页面，整套东西打包成一个Node进程就能跑起来。没有数据库服务器，没有云端同步，没有登录注册，所有数据都落在一台自己说了算的机器上。如果你也玩主机游戏，且对游戏数据有整理强迫症，或者单纯不想让游戏习惯被平台算法拿去分析，那这个项目的思路应该会对你有用。
我给它起名叫AnyPS5，其实多少带点自嘲——它管不了平台服务器上的任何东西，它只管好你自己这台设备上的游戏档案。
2. 游戏库数据从哪来：采集方式的取舍与落地
2.1 不能指望官方接口，数据采集要务实
很多人一听说要做游戏库管理，第一反应是"直接调PlayStation官方API不就行了"。我在动手之前也这么想过，我甚至还专门去查过平台有没有开放游戏库数据的接口。结论很现实：官方没有提供面向个人的完整游戏库查询接口，所有想从线上直接拉数据到本地的方式，都绕不开登录鉴权和反爬限制。这条路对个人项目来说代价太高，也不够稳定。
所以我在设计数据采集时换了一个思路——不追求全自动同步，而是把"录入"做成一件足够顺手的事。这个决策看起来有点"妥协"，但实际上才是真正能落地的方式。结合我自己的使用习惯，最终的数据入口做了三个层次：
第一层是手动添加。每款游戏只需要输入名称、平台、类型、入手日期这几个字段，其他信息都可以后面再补。手动录入听着麻烦，但对于核心游戏库这种量级是完全可以接受的，毕竟谁也不会一口气往库里塞几百款游戏。
第二层是批量导入。官方虽然没有开放接口，但账号的浏览记录、已购清单等数据是可以在系统里手动导出的。我做了两个导入模板，一个支持CSV文件，一个支持JSON文件，字段映射规则直接写死在代码里。玩家从系统导出数据后，稍微整理一下就能批量灌进来。
第三层是本地资料包补充。游戏封面、发行商、发售日期这类静态信息，我维护了一份可以离线更新的本地映射表。每次往库里加游戏，如果元数据缺失，工具会提示"这是一款未收录的新游戏"，然后由我手动补充资料。一个几百游戏的库里，真正需要手动补的可能就十几款，完全在可接受的范围内。
2.2 数据模型的边界：哪些该存，哪些不该存
做数据采集的时候最容易犯的错是"什么都想存"。游戏介绍的正文、奖杯的每个图标、多人的热力图……这些数据好看是好看，但存下来之后你会发现，90%的数据在日常使用中根本不会翻出来看。所以我在设计表结构的时候给自己立了一个规矩——只存会用来做筛选和统计的字段。
游戏主表最终只保留这些字段：游戏名称、别名（用于搜索）、平台、类型、发行商、发售年份、入手日期、游戏状态（待玩中/进行中/已通关/已弃坑）、个人评分、游玩时长估计、通关标记、封面路径。听起来很少，但搜索引擎和统计面板需要的信息全部覆盖了。
这里有一个值得说的设计细节：游戏状态字段。很多管理工具用的是单一"玩过/没玩过"的二元状态，但实际玩家的状态是流动的。比如一款游戏通了主线，但白金还差几个奖杯，你很难说它是"已通关"还是"进行中"。我干脆在表里加了两个独立字段，一个是completed布尔值，一个是progress_status枚举值，这样就能表达"已经通关但还在刷白金"这种复杂状态，统计的时候又能分别出报表。
2.3 批量导入时最容易翻车的编码问题
我做CSV导入的时候踩了一个很典型的坑。从平台导出来的文件，编码是UTF-8还是带BOM的UTF-8，不同地区的系统给的还不一样。直接解析的时候，带BOM的文件第一列字段名会莫名多出一个奇怪的字符，导致映射失败。这个坑在本地测试根本看不出来，一旦导入真实数据就露馅。
解决办法也很简单，解析CSV之前先检查文件头三个字节，如果是EF BB BF就直接跳过BOM标记再开始解析。就这几行代码，能让批量导入的兼容性上一个台阶。类似的还有中文名里偶尔出现的特殊空格，我在清洗数据时统一把全角空格替换成半角，再去做模糊匹配，否则"尼尔：机械纪元"和"尼尔:机械纪元"会当成两款游戏。
3. 数据层的表结构与状态流转设计
3.1 五张表撑起整个工具
整个数据层我用的是SQLite，文件就叫game_library.db。数据库一共五张表，没有外键约束，没有复杂的关联查询，每张表的职责都很单一。
游戏主表（games）负责存游戏的基本信息和状态，这是整个工具的核心。购买记录表（purchases）负责记录每款游戏的价格、渠道、入手日期，因为一款游戏可能存在多个版本或者在不同渠道买过，所以这表是一对多的关系。游玩记录表（play_sessions）负责存储每次游玩的日期和时长，为统计面板提供原始数据。价格追踪表（price_history）专门记录心仪游戏的期望价格和实时价格快照。还有一张metadata_cache表，用来缓存封面图片路径和元数据补全标记。
这个表结构我故意做得比较"朴素"。真实项目里很多人上来就设计一堆关联表、中间表，结果自己写查询的时候反而被复杂的关联关系拖累。我自己的经验是，个人工具的数据库设计要以"查询直观"为第一原则，宁可在应用层多写几行逻辑，也不要在SQL里搞花活。
3.2 状态流转：把"玩游戏"这件事拆成可跟踪的节点
状态管理是整个工具最有"游戏感"的地方。我把一款游戏从入手到弃坑的整个生命周期拆成了五个节点：想玩（游戏在库里但还没开始）、开坑（第一次启动，变成进行中）、通关（主线完成）、白金（全奖杯达成）、弃坑（搁置或放弃）。
每个节点都对应一次记录的自动或手动更新。我设置了规则：游戏第一次添加时默认状态是"想玩"；在游玩记录里手动记一次"开始游玩"后，状态自动变成"进行中"；通关操作需要在游戏详情页手动勾选，因为系统无法自动判断剧情进度；白金状态也同理，但加了时间戳记录白金日期。
这里我踩过一个设计上的小坑：最开始我用一个整数状态值（0想玩、1进行中、2通关、3白金）来表示生命周期，代码里全是魔法数字。后面想加一个"已弃坑"状态时发现，这个状态并不能简单插到线性序列里，它可能从任意节点进入。后来我改成了两个字段的组合方案：progress_status（枚举值，包括want_to_play、in_progress、completed、abandoned）加platinum_achieved（布尔值），这样既能表达线性阶段，又能表达白金这种特殊成就，还不破坏已有数据结构。
3.3 游玩时长统计：手记还是自动，我用了一个折中方案
游玩时长这个数据很敏感，因为它直接决定了统计面板里"本月玩了多久"这种核心指标。最准确的方案是让系统后台定时读取主机活动记录，但个人项目做这个的代价太大。我最终用的是手动记录加估算双轨制：
每次打开游戏详情页，可以点一个"结束本次游玩"按钮，弹窗里选本次游玩了多久（30分钟/1小时/2小时/自定义）。这个记录写入play_sessions，统计面板就按真实记录聚合。同时游戏主表里有一个"游玩时长估算"字段，如果你不想逐次记录，可以直接填写总时长，统计时会优先用真实记录，没有记录的游戏再用估算值。
用下来的感受是，刚开始会觉得逐次记录有点麻烦，但养成了习惯之后，每周日花两分钟补记一下，月底看到的统计报告会特别有成就感。而且这种"主动记录"的仪式感，某种程度上比全自动采集更让我有复盘的感觉。
4. 价格追踪与购物清单：给"等打折"画上句号
4.1 对标价逻辑的理解与实现
游戏玩家的日常少不了一句"等打折再买"。但"等打折"这个动作如果没有工具辅助，往往会变成"忘了这回事"。我在做价格追踪模块时想的是：与其做一个简单的降价提醒闹钟，不如把"想买的游戏"当成一条条的购物决策流来管理。
每个想买的游戏可以建立一个追踪条目，里面记录三样东西：心理预期的入手价、当前观察到的市场价、以及价格历史。这里的"市场价"我特意设计成支持手动更新和导入更新两种方式。手动更新就是你自己看到了某个渠道的报价，在页面上更新一下；导入更新是后面预留的可能性，比如将来你抓到了某个价格接口的数据，可以直接批量灌进来。自动化的实时爬价格在个人项目里维护成本太高，我不建议一开始就做。
这个逻辑和炒股记账很像。你不一定需要实时行情，但你需要一个可靠的账本，知道自己在什么时间点看到了什么价格，才能做出"现在是不是好价"的判断。
4.2 价格记录的数据结构和提醒规则
价格追踪的price_history表结构不复杂：游戏ID、记录日期、渠道、价格、是否达到预期价。每次更新价格时，代码会比对预期价和当前价，一旦当前价小于等于预期价，就会在该游戏的列表里打上一个"建议入手"的高亮标记。
还有一个细节是"到手价"和"标价"的区别。很多平台标价和实际结算价不一样，有会员折扣、有运费、可能还有各种各样的优惠券。我在录入价格时加了final_price字段，强制用户填"最终到手价"，避免因为标价误导做出错误的购买决策。这个字段是当时做设计时一个朋友提醒我的，后来实际操作中确实发现标价参考价值不大。
4.3 购物清单的优先级排序策略
购物清单如果只是并列摆一排，时间长了你根本不知道先买哪个。我加了一套简单的排序规则：权重 = （预期价 - 当前价）的绝对值除以预期价，再乘以游戏想要程度的系数。想要程度系数是手动设置的，1到5颗星，五星代表"出了就买"，一星代表"可有可无"。
排序结果会直接体现在清单页的默认排序里。这样一来，"降价幅度大"和"我特别想要"这两个因素会被同时考虑进去，而不是单纯看价格数字。这套排序规则一开始被朋友说是玄学，但实际用下来，它确实帮我规避了好几次"因为降价很猛就买了并不想要的游戏"的冲动消费。
5. 统计面板：把零散的记录变成看得见的报告
5.1 年度报告式的展示逻辑
数据记录得再多，如果只是躺在数据库里，那它和没记没有区别。统计面板是整个工具里最直观体现"数据价值"的部分，它的交互逻辑参考了主机的年度回顾报告——不是那种冷冰冰的表格，而是有节奏地展示关键指标。
第一个模块是"库概览"，展示游戏总数、进行中数量、已通关数量、白金数量，把它们做成一排四张卡片。第二个模块是"投入时间"，按月份聚合并展示游玩时长趋势图。第三个模块是"类型分布"，用简单的条形图展示你游玩最多的是不是角色扮演类。第四个模块是"近期动态"，按时间倒序展示最近的游玩记录和购物决策。
5.2 图表实现：不引大库，几十行代码画折线图
最开始我想过引入一个现成的图表库，但后来发现统计面板需要的图表很简单，折线图、条形图而已。找一个大而全的图表库反而引入了一堆用不上的依赖。最后我用Canvas手写了一个轻量的折线图组件，大概一百多行代码，支持月份刻度和数值范围自适应，足够统计面板使用了。
手写图表的细节有一些值得记录。比如月份标签的间隔问题，如果只有三个月数据，横坐标全挤在一起不好看；如果跨度有两年，又得考虑标签稀疏。我用的策略是动态计算刻度数：数据点数量少于等于6个就全标，多于6个就取整数步长，保证标签永远在6个以内。这些逻辑虽然不复杂，但确实是重度依赖图表库时不会注意到的东西。
5.3 一眼看出"游戏囤积症"的榜单
统计面板里我加了一个"虚拟KPI"列表——它不评判任何东西，纯粹用数据让你面对现实。比如"未通关比例"：如果比例超过70%，说明你的游戏库开始有库存积压的风险了。又比如"平均通关时长"：用实际记录的游玩数据，算出每一款通关游戏平均花了多少小时。
我开这个面板时经常被数据教育。比如我发现自己的平均通关时长是32小时，但"想玩"列表里躺着的游戏，平均剧情时长是45小时。这个落差瞬间解释了我为什么总觉得没时间玩游戏——不是没时间，是坑挖得比填得快。这个视角蛮奇特的，它不给你任何建议，但数据摆在那里，比任何时间管理建议都管用。
6. 部署方式、迁移与日常使用问题
6.1 本地跑起来：一个命令的事
整套工具打包后的运行方式非常简单。依赖安装完毕之后，一个node server.js命令就启动了服务，默认监听本机8080端口，浏览器打开就能用。数据库文件如果没有会自动创建，metadata缓存目录如果没有也会自动初始化，不存在繁琐的初始化步骤。
我把数据库文件的路径设计成可以通过环境变量覆盖，这样不同的机器可以指向不同的数据位置。比如在笔记本上跑就用默认路径，在专门的游戏主机机上跑就指向外接硬盘里的目录。这个灵活性在后期维护时特别有用，不用改代码就能迁数据库。
6.2 数据迁移和备份的心得
本地工具最怕的就是数据丢失。游戏库这种东西，重新录入一遍几百款游戏的资料，足以让任何人崩溃。我在设计时就考虑了备份方案：每次应用启动时，如果检测到数据库文件超过24小时没有备份，就自动复制一份带日期后缀的历史文件到backup目录。
这个方法有点土，但效果非常好。有一次我调整表结构时写错了一条SQL，导致数据库崩溃，回滚时就是从自动备份里恢复的。后来我又加了手动导出按钮，可以把整个游戏库导出成一个JSON文件，方便在另一台设备上初始化时快速导入。JSON导出的好处是跨平台无依赖，什么环境下都能解析。
6.3 使用半年的真实体验与改进方向
从工具完成到现在，我自己大概用了半年。先说结论：它确实改变了我管理游戏的方式。以前我的游戏决策散落在各个平台和记忆里，现在打开面板就能看到自己的游戏资产全貌。购物清单让我少买了好几款冲动游戏，统计面板也让我更清楚地看到自己的时间花在了哪里。
当然也有一些至今没有完全解决的问题。一个是移动端适配，这个工具是按照桌面浏览器设计的，手机上用体验一般，但我个人使用场景几乎都在电脑前，所以优先级一直不高。另一个是多人协作，如果家里有两个人共用一台主机，游戏库的归属逻辑就要复杂一些，目前版本只能通过"记录备注"来区分是谁在玩，体验上还是有一点粗糙。
下一步我计划做的是把价格追踪的导入接口打通，让手动维护价格的频次降下来。另外一个远期想法是给游玩记录加上"记忆随笔"功能，每款游戏通关时写一段当时的感受，相当于一个私人版的游戏编年史。这个功能其实和数据库设计无关，完全是一个情感层面的设计，我觉得等实现了会让这个工具真正变成"自己的东西"。
回看整个项目，最让我满意的地方不是技术多炫，而是它让我意识到，一个人的数字生活也是可以认真打理的。游戏库不只是列表里的一堆条目，它记录的是你在那些世界里花过的时间，以及当时为什么按下开始键。有了这个本地管理台，至少这些记忆不会被遗忘在商店的某个角落里。
