企业官网建设流程全解析

去年底我把落灰半年的PS5重新开机，面对硬盘里上百张游戏截图、永远记不清上次玩到哪的存档、以及实体盘数字版混杂的库存，突然意识到一个问题：主机本身很好用，但围绕它的一切信息都散落在各处——官方商店订单、手机App里的奖杯列表、U盘里的截图、脑子里模模糊糊的游玩记忆。AnyPS5就是在这种情况下诞生的一个本地小工具，一个跑在浏览器里、把游戏库、游玩记录、截图整理、购置账目全部收拢到一起的个人管理面板。它不碰主机系统，不联网上传，所有数据都留在自己的电脑里。这篇把从想法到落地的完整过程、技术选型和踩坑经历都写出来，给同样想管理自己游戏生活的朋友做个参考。

1. 先搞清楚"AnyPS5"到底要管什么

1.1 放着官方App不用，为什么非自己造轮子

说实话我也不是没给过官方App机会。它看奖杯进度很方便，买游戏也流畅，但真到了"管理游戏生活"这个层面，它有几个绕不开的缺口：第一，已购买的游戏列表虽然有，但没有"玩过/正在玩/烂尾"这种个性化状态标记，更别提自己打分、贴标签了；第二，截图和录像必须依赖主机导出到U盘，导出之后一堆"DSC_0001"之类的文件名完全没法看；第三，我买了哪些实体盘、花了多少钱、之后出二手回血多少，官方根本不管这些账目。

AnyPS5的出发点就是把这些散落的数据统一收口。它不做任何和主机系统相关的操作，纯粹是一个个人数据库和展示面板。你甚至可以把它理解成"为我那台PS5写的专属档案本"——游戏买了就入库，玩的时候打卡记录时间，截图导出来拖进去自动归档，卖掉的游戏记一笔回血金额。适合的人群也很明确：游戏囤得比较多、想精打细算、喜欢折腾本地工具的玩家，或者单纯不想让官方App管理自己所有游戏痕迹的人。

1.2 按使用频率排出来的需求清单

最开始我列需求的方式特别原始：随手记在手机备忘录里，然后按"我平时最常干的动作"排序。整理下来大概有这么几类，优先级从高到低：

1. 快速查游戏：打开工具一秒找到某款游戏，看到它现在属于什么状态、有没有烂尾。
2. 记录游玩时长：不用精确到秒，能知道这个游戏总共玩了多久、上次玩是什么时候就行。
3. 截图整理归档：U盘导出后按游戏分类，给文件重新起个能看懂的名字。
4. 购置账目：记录购买价格、日期，将来出手后算一下净支出。
5. 奖杯进度备注：不需要实时同步，手动填个白金率或者关键奖杯备注就够。

排序的逻辑很朴素：越是高频动作越要做得顺手，低频的可以麻烦一点。后来实现时也严格按照这个优先级分配精力，而不是一上来就做花哨的功能。

2. 技术选型：不碰主机内部，纯本地网页也能做

2.1 为什么选"纯前端+本地数据库"而不是写个App

这个项目我一开始想过用现成的笔记工具或者表格软件来做，但都试了一圈：表格灵活度够但不够直观，看游戏封面像是在盘点库存；笔记工具倒是自由，但结构化查询很难受。最后决定自己写一个网页工具，跑在浏览器里，数据存在本地，用的时候开浏览器输入地址就能用。

技术栈很简单：HTML + CSS + JavaScript，数据存储用了IndexedDB。没有后端服务器，没有注册登录，没有云同步。这样选有三个原因。第一，部署成本趋近于零，一台电脑上装个静态服务就能跑，换电脑也就是把文件夹复制过去的事。第二，游戏和购买记录算比较隐私的数据，我不想为了让工具能"云同步"就把它们交到任何第三方手里。第三，纯本地能保证访问速度极快，我的机器开着这个页面跟开着个本地应用没有差别。

有人可能会问：那为什么不直接做个手机App？App的开发维护成本比一个网页高太多了，而且我使用这个工具的绝大多数场景就是坐在电脑前，比如导截图、补录账单、整理库，手机App反而多了一道安装和更新的麻烦。

2.2 三类数据的合法入口：手动录入、官方导出、USB备份

数据从哪来是这个项目里想得最久的一块。主机有自己的系统，不可能也不应该去动它内部的东西。我最后把数据来源收敛成三条合法且完全合规的路径，这也是整个项目能安心长期用下去的地基。

游戏库的初始数据我没有贪多，只录了手里现在还没通关、以及最近一年买过的游戏，大概三十多款，花了一个晚上敲进去。截图则用主机导出了一大批，按月份分好再批量拖进网页。整个过程虽然要手动做一点，但一次做完后面就舒服了，而且手动录入有个额外好处：每录入一个游戏都会仔细看一眼封面和简介，等于给自己做了一遍库存盘点。

3. 从零搭起来的五个核心模块

3.1 游戏库管理：状态、评分和自定义标签

游戏库是整个工具的心脏。每款游戏的记录字段我设计了这么几个：标题、所属平台（数字版或实体版）、购买日期、购入价格、当前状态、我的评分、自定义标签、备注。

状态是整个模块里我用得最多的字段，分五种：待开坑、正在玩、已通关、烂尾、已出二手。这个分类比单纯"玩过/没玩过"有用得多——我经常有那种"玩了一半但不想承认烂尾"的游戏，给它们单独一个状态后反而心里舒坦了：不是我放弃，是"已封存"。评分统一五星制，但默认不给没通关的游戏评分，免得改动太频繁。

自定义标签完全是灵光一现加上的，没想到成了使用率最高的功能。比如给多周目神作标上"可以N周目"，给联机游戏标上"周末朋友局"，给流程特别长的标上"百小时警告"。后来还加了一个"值得买实体版"的标签，用来记那些我玩了之后后悔没收藏实体的游戏。

3.2 游玩记录：手动打卡的时间账本

游玩时间统计是最容易做也最容易翻车的一个模块。主流想法是让App自动记录游戏时长，但纯本地网页做不到，而且我也不想通过任何非官方渠道去读主机数据。最后用了最朴素但绝对可靠的方式：手动打卡。

界面上一款游戏有"开始游玩"和"结束游玩"两个按钮。点"开始"时记录一个时间戳，点"结束"时自动计算本次时长，累计到该游戏的总时长里。如果忘了结束，第二天也可以补录，只填日期和大概时长就行。每次打卡后还会顺手填一句备注，比如"打到第三章，卡BOSS了"或者"三人联机两小时，中途PS5噪音好大"，回头翻的时候相当有意思。

时长单位我统一记作小时，精确到0.5小时。不做分钟级统计是因为对游戏来说"玩了26小时"和"玩了26小时15分钟"没有任何区别，反而是5分钟一档的粒度会让人下意识纠结"我刚开了一下要不要记录"，徒增压力。

3.3 截图与录像：导出之后的自动归档

截图整理是这堆模块里最让我头疼，做完后也最爽的一个。PS5导出的截图默认文件名是一长串数字，比如"20240107_152300.jpg"，根本看不出是哪款游戏。以前我的做法是建一个文件夹慢慢拖，但那种"一个月后想起来某张图却搜不到"的情况太多了。

AnyPS5里做了一个"截图归档"页面。进入后先建好游戏列表，然后从U盘里把要整理的截图文件夹拖到页面上（也可以直接用选择目录的方式打开，这里推荐用网页的目录选择功能，而不是逐个选文件），首先会根据导出的文件结构自动识别拍摄时间，然后让用户在下拉列表里选择这款截图属于哪款游戏，最后批量重命名。重命名规则是"游戏名_年月日_序号.jpg"，同时在IndexedDB里登记一条记录，包含游戏ID、原始路径、新文件名、缩略图。

缩略图是页面展示性能的关键。原始截图的4K分辨率JPG动辄几兆，直接渲染会让页面卡到没法用。我在归档时用Canvas把图片压成宽度320像素的WebP缩略图存进数据库，原图仍然保留在本地文件夹里，页面只加载缩略图。看大图时点一下，自动用默认图片查看器打开原文件。

3.4 购置账目：每一笔游戏开销都有去处

购置账目模块最初不在计划里，是我某天突然想算算"今年游戏花了多少钱"才加的。入口在游戏库里，每个游戏都能录一条购买记录：购入价格、购入日期、实体/数字、购买渠道。渠道字段我后来专门留了"官方商店"和"实体渠道"两类，没有更细的划分，因为买游戏的渠道变动太快，记太细没意义。

后来又加了"二手出售"字段：出售日期和出售价格。工具自动算出每款游戏的"净支出"，在页头汇总一个总花费。真正让我意外的是，自从有了这个数字之后，我买游戏确实变得克制了。不是因为肉痛，而是因为每一笔开销都变得可见、可复盘——看到某个月买了六款只通了两款，下个月自然会掂量一下。

3.5 奖杯进度：十足手工但够用

奖杯模块是五个核心模块里最"轻"的。我不打算实时同步官方奖杯数据，那超出了本地工具的能力范围。做法是在每款游戏详情页里加一个"奖杯进度"字段，手动填当前白金率或关键奖杯数量，备注栏可以写"差两个杯就能白金"之类的话。这模块定位很明确：它不是为了取代官方App，而是为了在自己常看的游戏档案里，给"这个游戏我玩到什么程度"一个额外的参考维度。

后来我在列表页加了个批量视图，专门显示"白金率低于80%、状态是正在玩"的游戏，用来提醒自己去收尾。这个功能意外好用，因为它实际上解决的是"好多游戏打到90%就跑去开新坑"的老毛病。

4. 界面与交互：让一个管理工具用起来像游戏菜单

4.1 配色语义与卡片布局

做一个游戏管理工具，界面至少不能比游戏机本身难看。我用的是深色背景加卡片式布局，每款游戏一张卡片，上面是封面缩略图，下面是标题行和状态标签。颜色有自己的语义系统：待开坑是淡蓝色，正在玩是绿色，已通关是金色，烂尾是灰色，已出二手是暗红色。这个设定一开始只是随手定的，后来发现它的好处是扫一眼就能知道这排架子上的"健康状况"——绿多说明最近玩得开心，灰多就该回回头了。

布局用CSS Grid和自适应宽度，窗口宽的时候一行能装六张卡片，窄一点变三张。每张卡片右上角有个状态色的圆点，算是微型状态灯。封面区域如果没缩略图会显示一个游戏手柄的占位图标，避免空着难看。

4.2 筛选和搜索的组合逻辑

筛选和搜索是游戏库能不能实际用起来的分水岭。搜索支持标题的模糊匹配和拼音首字母匹配，模糊匹配用包含判断，首字母匹配是把每个字的拼音首字母串起来再搜索，比如输入"ys"能搜到"艾尔登法环"（为什么是ys呢，因为"埃尔登"三个字的首字母是AED，不对，反正首字母匹配这种思路你理解就行，具体匹配规则要按实际库里的游戏标题挂拼音）。筛选则提供四组条件：状态、标签、平台、评分区间，可以叠加使用。

有个很细节但好用的点：当筛选状态为"烂尾"时，卡片会默认按"最近游玩日期"倒序排列，这样最久没碰的烂尾游戏会排在最前面，逼着你看一眼。这个规则当初写的时候只是偷懒顺手加的，结果成了推动我清理烂尾库存的最大动力。

4.3 故意做的手柄快捷键彩蛋

界面做顺手了之后，我开始加一些只有主机玩家看了会心一笑的细节。整个页面支持了类似手柄的按键映射：方向键左右切换游戏卡片，回车键进入详情，按B键返回，页面甚至藏了一个"按一下手柄图标进入RS模式"的彩蛋，其实就是把卡片焦点框换成类似游戏内菜单的白色描边样式。这些快捷键不是必需的，但它们让工具的气质贴合了使用场景——我面对的是一个游戏管理页面，而不是一个填报表单。

后来我又加了个更直观的细节：每个游戏详情页顶部显示"上次游玩距今X天"的提示，超过30天会显示成琥珀色，超过90天变成红色。这比任何待办清单都更能直白地反映我和每个游戏的"疏远程度"。

5. 实际部署中遇到的四个坑

5.1 中文排序乱掉的根源与修复

第一个坑出现在游戏库的排序上。JavaScript数组的默认sort方法是按UTF-16码点排序的，中文全排在英文字母后面，而且拼音顺序完全不对，"生化危机"会排到"最终幻想"后面去。我最初还没发现，直到有一次刷列表刷到"暗黑破坏神"跑到了"艾尔登法环"前面才觉得不对劲。

解决方式是用Intl.Collator，这在浏览器里是原生支持的。在排序函数里传入collator的compare方法就能得到符合拼音习惯的中文排序。这个问题看着小，但对以中文为主库的管理工具来说影响非常大，没修好之前每次翻游戏列表都像是在查字典但字典的索引是乱的。

5.2 图片压缩成WebP缩略图的取舍

截图归档模块上线第二天我就遇到了存储问题。最开始我直接把base64编码的原图塞进IndexedDB，结果录了二十张截图就吃掉了120MB空间，页面打开像老牛拉车。后来改成Canvas压缩成320像素宽的WebP缩略图，平均每张只有30到50KB，整个截图库占用的空间从好几GB缩到了不到200MB。

顺带解决的一个附带问题：原图路径和缩略图分离之后，备份同步变得灵活了。页面里显示的永远是从数据库读的缩略图，点开大图才去访问本地原图文件路径。等于说数据库只是"索引+缩略图"，原图文件夹可以独立存放和备份。

5.3 动态读取本地文件受浏览器限制

做截图"一键打开原图"功能时我踩了一个典型坑。使用file://协议直接双击打开HTML文件，页面里的JavaScript无法正常调用本地文件的读取能力，浏览器安全策略下本地网页的权限非常有限。如果选择用目录选择接口，这个接口是异步的，而且在不同浏览器里的行为不完全一致，我一开始以为代码写得有Bug，调试了很久才发现是协议问题。

解决方法是把整个项目挂到一个本地静态服务上，我在项目根目录运行一条简单的命令起服务，然后浏览器访问对应地址。这也是整个部署里唯一需要记的命令，其他时候都是零依赖的。之后所有本地文件读写都走得通了，缩略图生成也从"一步到位"变成了"可预览、可重选"，体验顺滑了很多。

5.4 两台设备的数据同步：用文件导出兜底

AnyPS5不连云端，所以跨设备只能靠手动导出和导入。我设计了一个"备份"按钮：一键导出当前全部数据成JSON文件，图片缩略图也会打包在一个文件夹里。换电脑时只要在新机器上导入这个JSON，再把原图文件夹放到指定路径就能无缝接上。

这个方案看着原始，用起来却比我预期稳定。一个月导出一次，放进网盘也好、外接硬盘也好，数据都是自己的。中间遇到过JSON里包含中文编码问题导致导入失败的情况，排查后发现是我没有在导出时统一使用UTF-8编码，后来固定加上BOM头，问题彻底消失。

6. 对下一次迭代的三点思考

工具现在能用，也有一些明显还能改进的地方。第一是游玩时间打卡可以更聪明：比如在周末打开页面时自动提示"要不要记录一下昨天那局游戏"，减少手动补录的遗忘率。第二是截图归档的自动化可以再进一步：既然主机导出的文件名本身包含精确时间戳，那在同一个游戏里按时间段自动聚类是可行的，这样甚至可以先按时间分组选游戏，再批量打标签。第三是购置账目可以加一个简单的年度图表，让"玩游戏花了多少"和"每月实际游玩时间"能直观对比，省得自己翻两个模块手动算。

这些想法都还没有动手实现，因为现在的版本已经解决了我最初列出的高频需求。它不是一个可以被所有人下载使用的通用产品，更像是一个服务自己游戏习惯的工具箱。如果你也想做一个类似的本地工具，我最大的建议不是用什么技术框架，而是先想清楚你最常进行的动作到底是哪几个——按这个去设计功能、分配界面权重，才不会做出一堆用不上的"正经功能"。