企业官网建设流程全解析

AnyPS5，这个名字是某天晚上我从沙发上爬起来，对着那排越堆越高的游戏碟盒随口起的。Any PS5，直译过来就是"随便一台 PS5 上的任何游戏"——因为我当时面临的问题很简单：游戏库已经多到让我选择困难，而真正想玩的却总是那两三个。如果你也有几十上百款游戏躺在库里，却每天打开商店翻来翻去最后默默退出，那这个项目的思路或许对你有参考价值。

AnyPS5 本质上是一个部署在你自己电脑上的私人游戏库管理工具，帮玩家把实体盘、数字版、会员游戏、试玩版归拢到同一套数据库里，然后用标签、状态、进度日志和随机推荐，解决"今天玩什么"和"上次玩到哪"这两个最实际的问题。它最适合两类人：一类是库存量大、追求掌控感的收集型玩家，另一类是像我这样，做不了复杂社交评分、只想要一个安静后台记录自己游戏旅程的单机玩家。整个项目从零搭起来只需要一个能跑 Python 的环境，不依赖任何云端服务，数据完全归你所有。

下面的内容会分成几个部分展开：先说为什么会有这个项目，再拆解核心功能，然后是技术选型逻辑和完整复现过程，最后分享开发半年里踩过的坑和一些反思。你可以把它当成一个"如果我自己做，会怎么做"的完整思路。

1. 从"游戏太多"到"AnyPS5"：这个项目的起点

1.1 游戏库失控时的真实体验

很多人以为"库大"是富余，其实库大带来的是一种低强度的焦虑。我的游戏主要来自四个渠道：实体光盘、数字商店、会员赠送和定期更新的试玩版。每个渠道一个入口，每个入口一套查找逻辑，甚至每个入口的"拥有状态"都不一样——有的买了没下载，有的下好了没打开，有的打开过一次然后永远躺在内容库列表里。

我一度把想玩的游戏记在手机备忘录里，结果备忘录本身也变成了一个新的"库"，里面的条目和实际库存对不上，越记越乱。真正的问题不是"没有游戏玩"，而是"我没有一个属于自己的、统一的视角来看我的游戏"。商店首页的推荐算法是给所有玩家看的，它不知道我玩到一半的某个作品、不知道我明确说过"这个月不想碰恐怖游戏"、更不知道我其实很想回去把某个老游戏重新捡起来。

AnyPS5 就是为了补上这个视角而出现的。它不试图替代商店，也不试图给游戏打分排名，只做一件很朴素的事：把"我有什么游戏"和"我玩到哪了"变成我自己维护的一组数据。

1.2 为什么不做现成的App，偏要自己写

市面上其实有不少游戏管理类应用，移动端和网页端都有，功能看起来眼花缭乱。但它们解决的问题和我解决的问题不太一样。一般来说，这些应用默认了三个前提：玩家有社交需求，想和朋友对比收藏；玩家有成就收集需求，想看奖杯和全成就进度；玩家愿意把数据托管到云端服务上。

这三个前提我都不太符合。单纯想记录的话，开一个 Excel 表格也能做，不必写一个项目。自己做的理由不是技术炫技，而是想要一个"规则完全由我定义"的后台：我可以随手加一个字段记录"这游戏是哪个朋友送的"，也可以临时把某个游戏打上"等 DLC 出了再玩"的标签，这不需要向任何人申请功能。

还有一个很现实的原因是隐私。把整个游戏库、游玩日志、个人评价交给第三方服务，等于把生活习惯的一部分托管给了别人。就算服务条款写得很清楚，我也总会担心有一天平台改版、数据导出困难，或者干脆关停。自己写的工具没有这些风险，数据库就是一个文件，想备份就复制一份，想迁移就拷走，任何时候都掌控在自己手里。

1.3 AnyPS5 的核心定位：本地、私人、无社交压力

所以在设计初期，我给 AnyPS5 划了几条明确的边界：

• 不碰成就、奖杯和任何排行体系，游戏库里只有我自己的记录
• 不自动抓取商店库存，所有条目以"我认为我有"为准
• 数据只存在本地 SQLite 文件里，没有任何账号和云端依赖
• 游戏状态由我自己手动更新，系统只提供辅助，不做判断

这几条边界看起来好像限制了工具的能力，实际上它们保住了 AnyPS5 的核心理念：去掉"应该玩什么"的外部压力。很多管理工具做的好看，但用起来像在上班打卡，因为你总觉得有指标要完成。AnyPS5 恰恰相反，它的目标只有一个——让玩家在选择游戏的瞬间更轻松，而不是让管理游戏本身变成新的负担。有了这个定位，后面的功能设计和技术选型就有了参照物，很多纠结的决策都变得简单了。

2. 核心功能拆解：陪伴型游戏管理器的边界

2.1 入库：实体、数字、试玩、会员的归一化

游戏库管理的第一步是入库。但如果入库这一步就需要填十几个字段，那这个工具大概率会在用了一周后被你遗忘。我的原则是：最少字段完成入库，额外信息全部可选。

AnyPS5 的核心入库字段只有五个：游戏名称、平台、来源、发行年份、备注。这里的"来源"用统一枚举区分：

归一化处理的重点在于：无论这个游戏是怎么到我手里的，它在系统里都只是"一条库存记录"，后续的标签、进度、推荐逻辑不会因为来源不同而产生差异。这样做的直接好处是，我可以一次性筛选出"所有会员来源里还没玩过的动作类游戏"，而不需要在不同入口之间来回切换。来源字段本质上是一个筛选维度，而不是身份证明，这一点对后续体验影响很大。

2.2 进度追踪：记录状态和心情，而不只是时长

传统游戏统计工具特别喜欢记录"游玩小时数"，对很多人来说这确实有吸引力，但它也有副作用——一旦开始记录精确时长，你就会不自觉地产生"这周玩得不够多"的焦虑，记录行为本身会从乐趣变成 KPI。AnyPS5 的进度追踪刻意弱化了这个方向。

每一条游戏记录只有四类状态：

• unplayed（未开始）
• playing（进行中）
• paused（搁置了，但以后可能回来）
• finished / dropped（封盘或放弃）

每次想更新进度，只需要追加一条日志，包含三个信息：本次游玩的大致时长段（30分钟以内、1-3小时、一个下午这样的档位）、当下的印象分（1-5分）、一句随便写的备注。备注可以是"卡在第三关 boss 心态崩了"，也可以是"结局演出很棒，缓一缓"。这些内容不会出现在任何排行榜上，它们只是给未来的自己看的。

日志采用追加模式，不覆盖过去，所以你可以完整地看到一款游戏从第一天的"惊艳"到第二周的"有点腻"是怎么变化的。状态字段反而可以通过最新一条日志自动推导出来，不需要手动维护。这套设计让记录动作保持在十几秒以内，是我能坚持使用半年的重要原因。

2.3 标签、状态、愿望单：让系统替你分类

标签是游戏库管理的第二层分类。和固定字段不同，标签允许你随心情创建，不需要任何审批。我自己的常用标签大概是这样：题材（开放世界、肉鸽、恐怖）、节奏（短流程、长线、适合碎片时间）、情绪（治愈、压抑、爽快），偶尔还会有"和某位朋友联机""冲刺白金"这样的临时标签。

AnyPS5 给标签设计了一个简单规则：标签可以多对多，可以随时改，但不做自动标签推导。市面上很多工具试图通过 AI 识别游戏类型并自动打标，看起来很智能，但结果经常不准，反而要花时间纠正。手动打标签虽然慢，但每次打标签本身就是一次思考——你会回忆起这个游戏带给你的感觉，这反而加深了对库的掌控感。

愿望单是独立于游戏库的一张表。它记录的不是已经拥有的游戏，而是"未来可能会买"的候选者。任何游戏库管理工具都容易让人陷入一个误区：只管理已有的东西，却不管理自己想要的东西。愿望单补上了这一环，配合下面的点名功能，形成了一个完整的决策链：愿望单里看到感兴趣的 → 有折扣时买下 → 入库 → 玩完后打标签 → 根据体验回头修改愿望单里的偏好。

2.4 点名功能：随机推荐和一局制

"今天玩什么"是 AnyPS5 里使用频率最高的功能，我把这个功能叫作"点名"。它的逻辑非常简单：系统从符合筛选条件的游戏里随机挑选几个，显示在首页。

第一次实现时，我只做了"随机挑一个游戏"，但实际用起来效果并不好——随机挑出来的游戏经常不符合当下的环境，比如周末下午挑出一个半小时流程的恐怖游戏，或者睡前挑出一个容易上头的长线作品。后来我加入了两个参数：一个是"时间环境"，分为睡前、碎片、周末大块三种；另一个是"不接受标签"，可以临时排除不想碰的类型。点名时系统先按条件过滤候选集，再从里面随机选出三个，玩家只需要在这三个里挑一个，或者一个都不要，再次点名。

这其实就是所谓的"一局制"思路：不要给用户一个无限列表，那等于把所有选择压力又还给了玩家。三个选项、一个"重来"按钮，是最小可行的推荐交互。我没有引入复杂的推荐算法，因为对一个数百条记录的个人库来说，随机 + 简单过滤已经能让选择体验发生质变。

3. 技术选型为什么是 FastAPI + SQLite + 轻前端

3.1 为什么不用一套重型后端

AnyPS5 的服务对象非常明确：单个人、单台机器、低并发、跑在一台可能已经用了七八年的旧笔记本上。这意味着很多在企业级项目里理所当然的选择，在这里反而是负担。

比如引入 Docker，虽然部署更干净，但一个本地小工具还要维护镜像和容器，明显过度设计。再比如用 PostgreSQL，功能强大，但 SQLite 对单用户场景绰绰有余，而且不需要安装服务。选型的时候我给自己定了一个原则：能少一个依赖就少一个依赖，新增的任何组件必须能直接回答"它减少了维护成本还是增加了维护成本"这个问题。

最终的技术栈收敛到三层：Python 3.10 + FastAPI 作为后端，SQLite 作为数据库，前端只有一个原生 HTML 页面配上少量 JavaScript。整个项目没有构建步骤，没有打包流程，没有环境编排文件，对长期维护来说，这是最大的优点。

3.2 FastAPI 和其他选择对比

做这个项目时我其实比较过几个后端方案，结果很直白：

FastAPI 赢在两个关键点。第一是它的请求校验基于类型注解，写一个函数签名就像给接口定义了契约，参数错误会直接返回清晰提示，这帮我省掉了大量手写 if-else。第二是它自带交互式 API 文档，开发过程中我经常直接在浏览器里调试接口，不需要额外的测试工具。虽然正式使用中没人会打开这个文档页，但开发期它真的帮我节省了很多时间。

3.3 数据模型设计：三张表和一个推荐视图

AnyPS5 的数据库结构非常克制，核心只有三张表。下面是我最终定下来的表结构。

games 表，游戏库主表：

logs 表，进度日志表：

tags 表配合 game_tags 关联表实现多对多标签：

设计时我有意没有把"游戏状态"放进 games 表。因为状态如果放主表，每次更新日志都要附带改一次状态字段，很容易出现数据不一致。最终方案是：状态永远从最新一条日志推导。虽然有轻微计算成本，但对单用户几百条数据来说完全可以忽略，收益是永远不存在"日志说在玩但状态是未开始"这种矛盾。

"推荐"不需要单独建表，它只是一条带条件过滤的查库逻辑，我在代码里用几个筛选函数组合实现，后面会展开讲。

3.4 SQLite 在个人工具中的适用边界

SQLite 是个经常被低估的数据库，它甚至不是一个独立服务，只是一个 C 语言库。对 AnyPS5 这种规模的项目来说，它的表现堪称完美：

• 单文件存储，备份就是复制 .db 文件，不需要导出导入工具
• 支持事务，批量导入时能保证要么全成功要么全回滚
• 读并发能力足够，个人工具不太可能出现写冲突
• 不需要额外安装，Python 标准库自带 sqlite3

当然它也有边界。如果未来做成多人协作、每秒钟几十次写入的服务，SQLite 就不合适了。但 AnyPS5 的定位就是单用户本地工具，我就没在这个问题上纠结。唯一做的一个优化是开启 WAL（Write-Ahead Logging）模式，这样即使某次异常退出，数据库也不容易损坏，启动时恢复速度也更快。

4. 从零复现 AnyPS5 的完整过程

4.1 初始化项目结构

这个项目的目录结构特别简单，五个文件就撑起了整个工具：

anyps5/ ├── app.py # FastAPI 应用，接口都在这 ├── db.py # 数据库连接和初始化逻辑 ├── import_data.py # 从 JSON / CSV 批量导入游戏 ├── static/ │ └── index.html # 前端单页 ├── data/ │ ├── games.json # 原始数据，可导出备份 │ └── anyps5.db # SQLite 数据库文件 └── requirements.txt # 依赖清单

requirements.txt 内容：

fastapi uvicorn[standard] pydantic

这四个依赖足够了。运行方式一条命令：uvicorn app:app --host 127.0.0.1 --port 8000。默认只监听本机地址，外部设备访问不到，这也是安全上的一个有意设计——本地工具不需要暴露到局域网。

4.2 建库语句和初始化逻辑

db.py 里的初始化逻辑很直接：检查数据目录是否存在，不存在则创建一个；再执行建表语句，用CREATE TABLE IF NOT EXISTS保证多次启动不会报错。下面是核心 SQL：

CREATE TABLE IF NOT EXISTS games ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, platform TEXT NOT NULL DEFAULT 'PS5', source TEXT NOT NULL DEFAULT 'other', year INTEGER, note TEXT, created_at TEXT NOT NULL DEFAULT (datetime('now')) ); CREATE TABLE IF NOT EXISTS logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, game_id INTEGER NOT NULL REFERENCES games(id), logged_at TEXT NOT NULL DEFAULT (datetime('now')), play_segment TEXT CHECK(play_segment IN ('short','medium','long')), mood_score INTEGER CHECK(mood_score BETWEEN 1 AND 5), note TEXT ); CREATE TABLE IF NOT EXISTS tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE ); CREATE TABLE IF NOT EXISTS game_tags ( game_id INTEGER NOT NULL REFERENCES games(id), tag_id INTEGER NOT NULL REFERENCES tags(id), PRIMARY KEY (game_id, tag_id) );

sqlite3 模块的Row访问方式需要设置一下，否则查出来的数据是元组，操作起来不方便。这个问题很多 Python 新手踩过坑：

conn.row_factory = sqlite3.Row

4.3 批量导入：从 CSV / JSON 到入库

我从旧 Excel 表格迁移数据时，第一次尝试写了一个逐条插入的脚本，500 条游戏跑了接近三秒，体感很慢。后来用了executemany和事务，耗时降到 0.2 秒以内。这里把两个方案都放出来，你一看就明白差异。

慢速版：

for item in data: cursor.execute( "INSERT INTO games (title, platform, source, year, note) VALUES (?, ?, ?, ?, ?)", (item["title"], item.get("platform", "PS5"), item["source"], item.get("year"), item.get("note", "")) ) conn.commit()

批量版：

rows = [ (item["title"], item.get("platform", "PS5"), item["source"], item.get("year"), item.get("note", "")) for item in data ] cursor.executemany( "INSERT INTO games (title, platform, source, year, note) VALUES (?, ?, ?, ?, ?)", rows ) conn.commit()

导入脚本还需要处理两个事情：去重和日期清洗。去重规则我用的是"标题小写后去空格 + 平台"作为唯一键，同一个游戏既买了数字版又买了实体版不会被误判重复。日期清洗见后面的踩坑部分。

4.4 核心接口的实现逻辑

FastAPI 接口很简短，我抽四个有代表性的说一下设计意图。

新增游戏：

@app.post("/api/games") def add_game(body: GameIn): with db.connect() as conn: cur = conn.execute( "INSERT INTO games (title, platform, source, year, note) VALUES (?, ?, ?, ?, ?)", (body.title, body.platform, body.source, body.year, body.note) ) game_id = cur.lastrowid return {"id": game_id}

这里用 Pydantic 的GameIn做请求体校验，字段缺失或类型错误会自动返回 422，不用自己写解析逻辑。

追加日志：

@app.post("/api/games/{game_id}/logs") def add_log(game_id: int, body: LogIn): with db.connect() as conn: conn.execute( "INSERT INTO logs (game_id, logged_at, play_segment, mood_score, note) VALUES (?, ?, ?, ?, ?)", (game_id, body.logged_at, body.play_segment, body.mood_score, body.note) ) return {"ok": True}

点名推荐：

@app.get("/api/roll-call") def roll_call(env: str = "evening", exclude_tag: str = None): with db.connect() as conn: sql = """ SELECT g.* FROM games g WHERE NOT EXISTS ( SELECT 1 FROM logs l WHERE l.game_id = g.id AND l.logged_at >= date('now', '-3 days') ) """ rows = conn.execute(sql).fetchall() # 再加环境/标签过滤，随机取三个 candidates = filter_by_env_and_tags(rows, env, exclude_tag) return random.sample(candidates, min(3, len(candidates)))

点名逻辑里那个子查询的意思是：最近三天内有过游玩记录的游戏不参加点名，避免随机出来一个"昨天刚玩过"的东西。

统计接口：

@app.get("/api/stats") def stats(): counts = {} for label, sql in [ ("total", "SELECT COUNT(*) FROM games"), ("playing", "SELECT COUNT(*) FROM games WHERE id IN (SELECT game_id FROM logs GROUP BY game_id HAVING MAX(id) ...)"), ("wishlist", "SELECT COUNT(*) FROM wishlist"), ]: counts[label] = db.query(sql).fetchone()[0] return counts

4.5 前端：一个小而美的单页

前端我原本打算用 Vue 或者 React，后来想到这个项目没有构建步骤，引框架反而要维护 node_modules，就放弃了。最终用原生 HTML + CSS + 一小段 fetch 逻辑，整个页面压缩到几百行。

页面布局就三块：顶部是一个搜索框和一个"新增游戏"按钮，中间是大卡片网格，每张卡片显示游戏名、标签和最新进度状态；右下角悬浮一个"点名"按钮，这就是使用频率最高的那个功能。

新增游戏用对话框，表单字段和接口对应。保存成功后不刷新页面，用location.reload()简单粗暴地重拉数据。这个方案没有任何性能问题，因为数据量本来就小。用原生 JS 的好处是零构建、零依赖、零框架升级焦虑，任何时候打开编辑器都能直接改。

5. 开发过程中踩过的坑与教训

5.1 发售日期的"脏数据"处理

游戏发行年份是我最开始没当回事的字段，结果它在导入时给了我最大的麻烦。旧表格里的年份五花八门：有的写"2019年4月"，有的写"2019/04"-style，还有的直接填"TBD""未定""----"，甚至出现过 "1999" 这种明显是 placeholder 的值。

最初的代码只做了int(year)强转，遇到脏数据直接抛异常，整个导入中断在第三行。后来改成先清洗再入库存：

def clean_year(raw): if not raw: return None digits = re.sub(r"[^\d]", "", str(raw)) if len(digits) < 4: return None year = int(digits[:4]) if 1980 <= year <= 2035: return year return None

规则很简单：只取前四位纯数字，范围限制在 1980-2035，非法值返回NULL。年份字段允许为空比填一个错误值更好，因为排序和筛选时错误值的破坏性比空值大得多。这个经验后来也用在了其他字段上。

5.2 进度日志被覆盖：从覆盖式到追加式

早期版本的日志功能是一个"编辑最近一条记录"的设计，界面上有个下拉框，选择状态后直接 UPDATE 当前最新日志。这个设计表面上方便，实际上有严重的 bug：如果你昨天玩了某款游戏，今天打开工具想记录新进度，界面上展示的却是昨天的日志，你只需要点一下保存就会不小心把昨天的记录改掉，丢失真实数据。

我实际遇到的情况是：某天我想把一款游戏从"进行中"改成"搁置"，顺手修改了那天的日志，结果两天前的"通关纪念"记录被一起覆盖了。意识到问题后，我把所有日志改成了纯追加模式：

• 不再支持编辑或删除历史日志
• 每条日志独立保存时间戳
• 游戏状态由最新一条日志推导出来

这个改动牺牲了一点灵活性，换来了数据一致性。在个人工具里，"不能改"其实也是一种安心，你永远不用担心自己的误操作毁掉过去记录。

5.3 导入时的 N+1 问题与批量优化

前面提到批量导入从 3 秒优化到 0.2 秒，本质是消除了逐条提交事务的开销。但这还不是最隐蔽的问题。第一次写导入时，我还在循环里做了标签匹配，每条游戏插入后都要查一次标签表，查出关联标签再插入关系统——这就是典型的 N+1 查询。

对 500 条数据，多出来的 500 次 SELECT 其实也能接受，但对上千条数据的游戏库就会明显变慢。优化的办法是直接把标签表一次性加载到内存里，做成一个name -> id的字典，导入过程中只查内存，不再访问数据库。对于所有类似的本地工具，这个思路都通用：数据量小到能放内存的时候，就不要反复访问磁盘。

5.4 自动获取封面：看上去很美，实际是坑

我一度想让 AnyPS5 自动下载游戏封面图，这样卡片网格看起来会好看很多。当时试着调用了几个公开的游戏资料接口，结果遇到一系列问题：接口限速严格，频繁请求会被临时封禁；封面版权归发行方所有，本地引用无所谓，但批量抓取存储有合规风险；更麻烦的是接口数据经常和本地命名对不上，同一个游戏在不同地区的标题不同，匹配准确率只有七八成。

后来我彻底放弃了自动封面方案，改成手动管理：在data/covers/目录里放以游戏 ID 命名的图片文件，前端检测到对应文件就显示，没有就显示一个占位色块。这套方案虽然需要手动放图，但绝对不会出错，也不会有任何版权和限速问题。这让我意识到，在个人项目里"能跑且稳定"永远比"好看且炫酷"重要。

6. 用了半年后的反思和给后来者的建议

6.1 哪些功能高频，哪些是摆设

AnyPS5 实际使用半年后，我拉了一下自己的使用数据，结果和起初的设想有些不一样。用得最频繁的是三个功能：点名、快速追加日志、按标签筛选。特别是"点名"，几乎每次坐到主机前都会按一次，已经变成了一种仪式感。快速追加日志也符合预期，十几秒完成，记录意愿很高。

真正成了摆设的是两个功能：复杂统计报表和自动标签规则。先做出来的是一个包含周报、月报、游玩时长分布的仪表盘，UI 很漂亮，但我一次都没看过，因为我根本不需要知道"过去三十天我在动作类游戏里花了多少小时"。自动标签规则设计得更复杂，本想通过标题关键词自动打标签，结果误判太多，每次都要手动更正，后来索性关掉。这两个教训让我深刻理解了"高频入口越浅越好，低频功能越深越好"——统计不是没用，而是不该放在首页第一屏。

6.2 从"AnyPS5"到"AnyGame"的扩展方向

半年后有一个朋友问能不能拿去管理他其他平台上的游戏，甚至管理书影音。从数据模型看，把platform字段放开，再改一个名称，确实可以变成通用的"AnyGame"。但我自己实际评估后没有立刻做多平台支持，原因很简单：多平台意味着每条记录要加更多字段来区分版本、区服、跨平台存档，这会让入库表单变长，拉低使用频率。

如果真要做通用版，我建议的分层思路是：先把platform从固定值改成自由标签，而不是在主表增加一堆平台相关字段。保持游戏的公共属性（标题、年份、状态、日志）在核心表里，把平台差异丢给标签系统去承接。这个扩展方向在代码上几乎无成本，但功能边界要守好——不要试图解决所有平台的所有特有问题，否则就掉进了功能膨胀的坑。

6.3 最后想说的话

做 AnyPS5 这半年，我最大的体会是：工具的目标是服务于玩法，而不是让玩法服务于工具。过去我把大量时间花在"如何更精确地记录"上，后来发现真正有价值的是"记录之后，打开主机不再犹豫"这个结果。

如果你也想做一个类似的私人管理项目，我的建议是先在备忘录或表格里手动维护两周，验证自己是不是真的有这个需求，再动手写代码。很多项目都是"造轮子的冲动超过真实需求"，存档两周之后发现根本坚持不下来，那就不值得投入更大成本。另外，尽量克制功能范围，你能想到的每个"锦上添花"的功能，将来都会变成需要维护的代码。少做几个功能，项目反而能活得更久。

AnyPS5 现在依然跑在我的旧笔记本上，数据文件只有几百 KB，备份就是复制一个文件。它没有云同步，没有社区分享，没有任何外部依赖，但每天打开主机前，我会先按一下那个"点名"按钮——这就是这个项目存在的全部意义。