企业官网建设流程全解析

先交代一下背景。我是个游戏库存控，平时最大的爱好就是逛各个商店页面和评分站，看看最近有什么值得入手的PS5游戏。可时间一长，我发现自己每天至少要在五六个不同站点之间来回切换——想确认口碑得去媒体评分站，想比价格得看商店页面，想核对发售日期又要翻新闻帖，偶尔还会因为两个站点的评分口径不一样，白白纠结半天。于是某天晚上，我给自己提了一个需求：能不能做一个工具，输入一个游戏名，就能一次性查出它的基本资料、媒体评分、用户评分、当前价格和发售状态？这就是 AnyPS5 项目的最开始。

我把这个项目定位成一个纯个人向的PS5游戏信息聚合与检索工具，不追求替代任何平台，也不做商业用途，只解决"我自己的信息焦虑"。整个开发过程从爬虫选型、数据清洗、存储设计到最后的Web化封装，前前后后花了将近三周。这篇文章不打算写成教程，而是想把我踩过的坑、做过的取舍、以及最终沉淀下来的方案如实讲一遍，给同样想折腾本地游戏数据库的朋友留个参考。

1. 立项动机：被割裂的信息源逼出来的自建工具

1.1 每天重复五遍的"查游戏"操作

买PS5游戏这件事，看着简单，实际很折腾。你看到一个游戏预告，心里的第一反应通常是：这游戏到底行不行？现在多少钱？什么时候能玩到？我的习惯是先查媒体均分，再翻用户短评，然后去商店看定价，最后再去社区确认一下这游戏首发有没有翻车。每个环节对应一个不同站点，每个站点的搜索结果排序逻辑还不一样，有些站你搜中文名能出结果，有些站必须输入英文原名，输错一个字母就啥也搜不到。

这种情况偶尔碰上还能忍，但如果你是新游戏密集发售的那几个月，几乎每天晚上都要重复这套流程。我算过一笔账，平均查一款游戏大概要花十五分钟，其中大部分时间浪费在"切换页面—重新输入—对比口径"上。时间长了，我就在想：与其天天做这些手工劳动，不如花点时间把信息聚合起来，以后一个搜索框全部搞定。

1.2 明确项目边界：只做聚合，不做判断

立项之前我特意给自己划了几条红线。第一，不采集破解或涉及灰色领域的内容，只抓公开的商店信息、公开的评分数据和公开发售状态；第二，不做"一键比价跳转购买"这类可能触及平台协议的功能，至少个人版不做；第三，任何评分数据必须标注来源和采集时间，我不能也不应该替用户"计算"一个所谓综合分。想清楚这些之后，AnyPS5 的产品形态就很简单了：一个能搜游戏、能看资料、能记价格变化的本地数据库工具。

1.3 只是给自己用？不，顺手做成了可扩展的小框架

最开始我确实只打算写个脚本跑一次，将这些信息揉进一个JSON文件里就算了。但实际抓了几百款游戏之后就发现，如果只是静态存储，数据很快会过期——评分会变、价格会跳、发售状态会更新。所以我把整个项目重新设计成"数据采集层 + 存储层 + 查询层"的三段式结构，采集层可以单独调度，存储层负责去重和归档历史，查询层只管给前端或者接口吐数据。这个决定在后面扩展新游戏的时候帮了大忙。

2. 数据源选型与爬虫架构：AnyPS5 的地基

2.1 我最终选定的抓取方案

数据源是整个项目最敏感也最关键的部分。我的原则是优先选结构比较规整、对爬虫相对友好的公开页面，尽量少碰有明显反爬对抗的站点。最终定下来四类数据源：官方商店的公开游戏页面、两家主流的媒体评分聚合站、一个社区用户评分板块、以及发行商官网的发售日期公告。每类源只抓自己最擅长的字段，比如评分站只抓分数和评论数，商店页面只抓定价和语言支持，日期公告只抓发售状态，这样每个源的责任边界很清晰。

技术上我用了 Python 的httpx做异步请求，加上parsel做 HTML 解析。没有上 Selenium 这类重型浏览器方案，因为大部分目标页面是服务端渲染的，普通的 HTTP 请求加上合理的请求头就能拿到完整内容。异步爬虫的好处是几百个页面的抓取可以在几分钟内完成，但代价是要自己控制并发，一个不留神就会触发对方的风控，后面会单独讲这块。

# 示例：异步抓取某个游戏详情页 import httpx from parsel import Selector async def fetch_game_page(session, url): resp = await session.get(url, headers=HEADERS) resp.raise_for_status() sel = Selector(text=resp.text) return { "title": sel.css("h1::text").get(), "score": sel.css(".score::text").get(), "release_date": sel.css(".release-date::text").get(), }

2.2 为什么不用现成的游戏数据库API

有人可能会问，市面上已经有不少现成的游戏数据库接口，为什么还要自己爬？我实际调研过，主要卡在三个问题上。第一，覆盖范围不均，冷门独立游戏和日系游戏的数据明显偏少，而这两类恰恰是我最常搜的；第二，接口的评分数据通常只有单一来源，没法满足我对比多个口径的需求；第三，很多接口返回的字段里，中文名称、中文版发售日这种本地化信息严重缺失。综合看下来，自己爬虽然前期工作量大，但数据完全在我的掌控里，清洗和扩充都方便，后续维护成本反而更低。

2.3 数据清洗里的三个关键动作

爬虫写完只是第一步，真正花时间的是数据清洗。我踩过的坑基本都集中在这个环节，总结下来有三个动作特别重要。

第一个动作是字段归一化。不同站点的日期格式、价格单位、语言标识完全不一样，意大利语区的日期写法是"日/月/年"，英语区是"月/日/年"，如果直接照单全收，存进数据库之后排序都是错的。我写了一套统一的格式转换函数，把所有日期转成 ISO 8601，所有价格统一存数字和货币代码两个字段，语言列表统一转成标准代码表。

第二个动作是标题别名映射。同一个游戏，商店页面用英文名，社区用中文名，评分站又用缩写，这三者如果不在入库时关联起来，后面搜索就废了。我的做法是建立一张别名表，把"官方标题""中文惯用名""常见缩写""系列编号"分开存，查询时统一走这张表。

第三个动作是空值处理策略。评分站还没出分的游戏、商店还没公布价格的游戏，这些字段抓回来是空的。我一开始直接留 NULL，后来发现过滤和排序时频繁出问题，干脆规定所有空值必须带一个"未公布"的状态标记，这样查询逻辑可以显式处理，而不是靠猜。

3. 搜索、对比与提醒：三个核心功能的实现思路

3.1 模糊搜索与中英文别名

AnyPS5 的主界面就是一个搜索框，这个搜索框决定了用户对工具的第一印象。我第一个版本用的是 SQLite 自带的LIKE '%关键词%'，结果搜"老头环"这种社区俗称完全没反应，因为数据库里根本没有这个别名。后来我引入了两层策略：第一层是精确命中别名表，第二层是 FTS5 全文索引。

全文索引的好处是支持分词和前缀匹配，英文游戏名搜前几个字母就能出来，中文名也支持按关键词匹配。实际用下来，最理想的体验是把别名表优先匹配放在前面，因为游戏这种实体是有主键的，别名命中之后直接返回主记录，体验非常干脆。

3.2 评分口径归一化：怎么比才不算"作弊"

做评分对比的时候我纠结了很久。媒体评分满分是100，用户评分满分是10，有些社区的推荐指数又是百分比，如果只是简单换算，数值上看着对，实际上掩盖了不同人群的评分习惯差异。我最后采用的方案是：所有原始分照常展示，不做换算；对比视图里只做"位次对比"，也就是把每个游戏在各自数据源里的百分位排名算出来，再做横向比较。

这么做的好处是诚实。媒体分85和用户分8.5本来就不是同一个参照系，强行归一化成百分制会给人"两者可比"的错误暗示。百分位排名至少反映的是"这个游戏在同类评分中的地位"，比直接算术换算要科学一点。

3.3 价格历史与心愿单提醒

收集价格数据是最容易让人上瘾的功能，因为游戏打折活动经常出现"昨天还是原价，今天突然半价"的情况。我给价格设计了一张独立的历史表，每次采集时如果发现当前价格和历史表里最新一条不一致，就插入一条新记录，这样自然形成价格曲线。心愿单功能则是在本地跑一个定时任务，每天检查一次心愿单里的游戏价格，如果低于设定的阈值就推送一条桌面通知。

这个功能技术上很简单，难的是定时任务的频率把握。我试过每小时查一次，结果一天能收到好几条无意义的变化通知；后来改成每天早上九点检查一次，只在"跨天价格变化"时才通知，清净多了。核心原则是：提醒功能要克制，否则用户会直接把通知关掉。

4. 存储层设计：让几万条数据依然搜得快

4.1 表结构设计的取舍

游戏数据有个特点：字段多，但字段之间的关系相对简单。我最初打算用一个"大宽表"把一百多个字段全塞进去，后来发现维护成本太高，加一个新数据源就要改表结构。最终我拆成了五张核心表：游戏主表、游戏别名表、评分表、价格历史表、发售状态表。

游戏主表只存固定不变的元数据，比如标题、发行商、类型、语言支持；评分表按数据源拆行，一游戏多源就是多行；价格历史表按时间拆行，做走势分析非常方便。这种"主表瘦身、附属表扩展"的做法，某种意义上模仿了列式存储的思路，虽然对单机工具来说有点过度设计，但好处是后续加新数据源真的不用动主表结构。

4.2 索引与全文检索的配置细节

查询性能方面，我最开始没建任何索引，数据量到两千条的时候搜索就开始卡了。后来按查询习惯建了几个关键索引：游戏主表的标题字段、别名表的别名文本、价格历史表的游戏ID和日期组合索引。全文检索用的是 FTS5 虚拟表，同步维护一张独立的搜索索引表，这样主表可以做其他操作而不会被全文索引拖慢。

这里有个细节容易被忽略：FTS5 的 tokenizer 对中日韩文本的处理默认并不理想。我的方案是给中文标题加一个额外的拼音字段，配合trigramtokenizer，这样中文输入和英文缩写都能搜到，实测召回率提升非常明显。

4.3 增量更新策略：全量重爬是下策

一开始我的更新策略很粗暴，每周全量重爬一遍，简单但效率低。后来数据量一上来，全量重爬要跑一个多小时，而且容易触发对方限流。我改成增量更新：游戏主表只在有新游戏名单时追加；评分表每天只抓那些"发售日期在最近三个月内"的游戏；价格表则是全量扫一遍，但只判断当前价与最新历史价是否一致，不一致才写新记录。

这种分层更新策略的收益在长尾数据上特别明显。老游戏评分早就不变了，每天重抓纯属浪费；新游戏的评分和价格则处于高频变动期，需要更频繁地观察。把握好这个节奏之后，整个采集任务的耗时从一小时降到了不到十分钟。

5. 实测踩坑记录：编码、重复数据与评分口径

5.1 编码问题：藏在页面里的隐形杀手

爬虫最经典的坑就是编码。某个欧洲区商店页面，HTML 里声明的是 UTF-8，但实际正文里混着 Latin-1 编码的特殊字符，用httpx默认逻辑解析，重音字符全部乱码。这个问题排查了很久，最后发现问题出在响应头里的charset声明和页面内嵌的<meta charset>冲突。我的解决办法是：优先信任 HTTP 响应头的编码，但如果检测到替换字符，就回退用页面内嵌声明重新解码一次。

这类问题用一句话总结就是：永远不要假设页面说它是什么编码就是什么编码，要以实际字节为准。

5.2 一个游戏三个版本的去重难题

重复数据是游戏数据库的老大难。同一个《XX传奇》，存在标准版、豪华版、终极版三个条目，评分站还把它们当作三个独立页面收录。如果直接入库，搜索时会出现三条几乎一样的记录，用户根本分不清该看哪个。

我的去重方案分两步。第一步是归一化标题，去掉"豪华版""限定版""年度版"这类后缀以及各种特殊符号，得到一个"基础标题"；第二步是用基础标题加发行年份做唯一键，把这些版本归到同一组。主条目展示基础信息和媒体评分，版本条目单独存价格和内容差异。这样搜索结果里只出现一条主记录，展开后能看到所有版本的价格对比，反而成了我后来最喜欢看的数据视图。

5.3 评分不一致的调和策略：保留差异而不是消灭差异

做这个项目之前，我一直以为媒体评分和用户评分应该是接近的，实际抓完数据才发现，有些游戏两者能差出三十分以上。一开始我很困惑，甚至怀疑是自己清洗出错了，后来想明白了：媒体评分倾向于在相对短的时间内对游戏的整体设计品质做判断，用户评分则混入了大量情绪因素，包括服务器问题、价格争议、甚至版本更新的影响。两者的差异本身就是有价值的信息。

所以我在详情页里做了一个"分歧提示"的小功能，当媒体均分和用户评分的百分位排名差超过二十个百分点时，会自动标注"口碑存在分歧"，并列出两个来源各自的评论数。这个功能看似简单，实际上很受用，它把"用户需要跨站对比才能看出来的信息"变成了"打开页面第一眼就能注意到的提示"。

6. 从命令行脚本到轻量Web应用：AnyPS5 的进化路线

6.1 为什么最终选择了服务端渲染

数据跑通之后，我最初只是用命令行输出表格，但每次查个游戏都要开终端敲参数，实在不够直觉。后来我盘算了一下自己的需求：没有复杂交互、没有用户系统、不需要实时协作，这种场景用服务端渲染的简单方案最合适。最终我选了 Python 的 FastAPI 加上一套轻量的 Jinja2 模板，没有上前后端分离的重型框架。

这个选择的核心逻辑是：当你的主体工作是在数据层而不是交互层时，引入一个完整的前端框架只会增加维护负担。服务端渲染让页面逻辑和数据查询放在同一个进程里，开发效率高，部署也简单，一台小机器就能跑起来。

6.2 接口设计里的一个小原则

虽然我做了页面，但后端还是顺手把查询能力抽成了 JSON 接口。设计接口时我坚持一个原则：核心查询接口的参数只暴露"用户真正会用的维度"，也就是关键词、类型、发售年份区间、评分区间、价格区间和排序方式。筛选条件太多反而会让接口难用，对个人工具来说没有必要。

搜索接口的响应结构我也刻意做得简单，只返回 id、标题、基础评分、当前最低价和发售状态这五个摘要字段，详细信息由详情接口单独返回。这样列表页的响应体很小，即使是移动网络环境下打开也很快。

6.3 部署与后续规划

部署方面我没有折腾容器化，直接在本地一台常开的迷你主机上用 systemd 托管进程，数据目录放在外置存储上，每天凌晨自动执行增量采集任务。这个方案足够稳定，运行了大半年没出过问题。

后续我最想做的两件事：一是把数据导出功能做成开放格式，这样即便哪天不想用 AnyPS5 了，数据也能平移到别的工具；二是给"口碑分歧"功能增加更多维度，比如对比不同语言区用户对同一款游戏的偏好差异。说实话，做这种个人项目的最大乐趣不在于功能多花哨，而在于它每天都能帮你省下那十五分钟。

写到这里，回头看看这几周的经历，最大的体会是：做一个信息聚合工具，真正难的从来不是写爬虫，而是想清楚"哪些数据该存、哪些数据不该混为一谈"。AnyPS5 到现在也只是一个满足我个人习惯的小工具，但每次更新完数据，打开页面看到那些整齐的表格和曲线时，我仍然会觉得，当初给自己提的那个需求，完成得还算不赖。