1. 从碎片化到一个入口AnyPS5到底解决了什么如果你也是个PS5玩家大概率经历过这种状态主机上装着好几个互不相通的应用手机里关注着好几个资讯号奖杯进度散落在不同平台遇到游戏史低折扣全靠缘分才能刷到。我用了大半年PS5之后突然意识到一个很现实的问题——游戏主机本来是为了让人省心的结果我的时间反而被管理游戏这件事吃掉了。这就是我折腾AnyPS5的起点。它的定位说起来不复杂做一个把PSN账号状态、游戏库、奖杯、折扣通知、系统资讯全部汇总到一个界面的辅助工具相当于给PS5玩家准备了一个自建的中枢面板。我最终跑通的版本不只是能看数据还能做到三件很实用的事跨区商店的价格追踪、折扣到达心仪价位时主动推送到手机、以及好友联机状态的快速查看。适合什么人来参考这篇记录首先是觉得自己游戏库已经多到买了不记得玩的玩家其次是打算用业余时间练手做个人项目的开发者还有就是单纯看不惯官方应用体验、想自己掌控数据的折腾党。这篇内容里我会把我从选型到落地踩过的真实坑全部放出来你可以直接当一份可复现的实操笔记来用。那个版本我起名叫AnyPS5意思就是任何一台PS5都能接入。它不修改主机系统、不碰固件、不涉及破解类操作全部基于官方公开的认证流程和接口能力实现。这个边界我在项目一开始就划得很清楚——做的是辅助层工具不是替代层工具这样后期省掉了非常多的麻烦。2. 核心架构拆解核心模块之间的关系2.1 账号认证模块OAuth流程接入整个项目最关键的模块就是认证。PSN账号体系走的是标准OAuth 2.0授权码模式需要一个客户端标识和密钥来申请访问令牌。这里有个容易踩的坑官方开发者后台申请的客户端在首次登录时可能要求额外验证所以我最后选用的是社区方案里一套公开可用的客户端凭据配合设备码授权流程完成登录。设备码流程比想象中要顺畅第一步程序在终端里输出一个短链接和一个设备码第二步我在电脑或手机浏览器里打开链接用PSN账号登录并输入设备码第三步网页提示授权成功后程序这边会自动拿到访问令牌并刷新令牌。整个过程不需要在主机上做任何操作非常干净。拿到令牌只是第一步。PSN的接口会把玩家的账号信息、游戏库条目、奖杯列表分散在不同域名下所以认证模块之后必须有一个统一的令牌管理服务负责定时刷新访问令牌、把令牌安全地转发给其他子模块。我在项目里直接用了一个独立的容器来跑这个服务其他模块通过内部网络调用不直接暴露到公网。提示设备码授权拿到的刷新令牌默认有效期较长但如果你在PSN账号页主动撤销了设备授权令牌会立即失效程序里要做对应的错误捕获否则整个面板会静默瘫痪。2.2 数据聚合层拉取、归一化、缓存认证搞定之后真正开始干活的是数据聚合层。PSN官方接口的响应格式在不同地区之间并不完全一致比如日服账号和港服账号返回的游戏标题字段名就有差异更别说是美服机器。如果代码里硬编码字段名上线第一天就会被数据教做人。我的做法是先定义一套统一的内部数据模型把游戏分为已拥有已购买未下载入库会免试玩版/Demo四个状态然后用适配器模式写各地区的转换器将差异字段归一化到这套模型上。归一化完成后统一写入本地数据库后续所有查询只走数据库不再频繁请求远程接口。缓存策略上我实际上手后觉得比较合理的节奏是游戏库信息6小时拉取一次因为购买行为不算高频奖杯列表24小时同步一次除非用户手动触发强制刷新价格信息按不同地区设置5到15分钟不等的轮询间隔避免被限流。这样跑下来的压力非常小普通家用主机当服务器都完全扛得住。2.3 通知与前端主动推送和快速查看数据聚合得再全如果不能主动触达用户价值就打了一半折扣。通知模块我设计了两条通道一条是Telegram机器人推送适合在手机端收到你愿望单里的游戏降价了这种消息另一条是Webhook方便接入到自己的其他自动化流程里。前端部分我没有做大而全的后台界面而是做了一个轻量级的移动端适配页面。首页展示账号状态、最近同步时间、愿望单数量第二页是游戏库支持按状态筛选和搜索第三页是价格趋势图。为了加载速度页面完全是静态资源加少量接口调用不引入重型前端框架直接服务端渲染出初始HTML后续需要更新时再局部刷新。3. 为什么这样选型技术决策背后的实际理由3.1 模块化部署而不是单体应用一开始我也纠结过就这点功能是不是写成一个小型单体程序更省事但后来我列了一下需求清单发现事情没那么简单——认证服务要常驻数据同步要定时通知推送要事件驱动前端要响应请求这几个任务的运行模式和生命周期都不一样硬塞在一个进程里会导致一个模块挂了全部停摆。最后用了Docker Compose把项目分成四个容器认证服务、同步调度器、通知服务、前端网关。这样做最大的好处是每个模块都可以独立排查日志、独立重启、独立升级。我中间有一次因为前端页面改版导致网关容器崩溃其他三个容器完全不受影响那个体验对我来说就是选型正确的证明。3.2 轻量数据库降低心智负担数据量最大的是价格趋势表一天存几千条记录一年下来百万级。这个量级用重型数据库属于杀鸡用牛刀。我选了SQLite加WAL模式单文件部署、零运维成本实际跑下来读写完全没压力。有朋友问我为什么不用MySQL或者PostgreSQL我的回答是个人项目的第一优先级是能少管一件事就少管一件事。等数据量大到SQLite撑不住的时候项目本身早就长成另一个规模了到那时再迁移也不迟。盲目在最开始就背一个数据库服务的运维包袱反而是最常见的项目夭折原因。3.3 关于要不要上K8s的自我劝退很多项目到了容器化这一步就开始按捺不住想上Kubernetes。我当时也认真评估了一下结论是坚决不上。K8s解决的是一堆主机、弹性伸缩、服务编排的问题而我的需求就是在一台小主机上跑四个容器docker compose up -d 一条命令就能解决。上了一套编排系统之后随之而来的是网络插件、存储类、Ingress控制器这一大串概念。对一个个人工具项目来说这些复杂度带来的不是收益而是负担。复杂度本身没有罪复杂度超过需求才是问题。4. 从零到可用的完整落地过程4.1 第一步环境准备与初始化宿主机我用的是一台淘汰下来的小主机装的Debian稳定版4GB内存、双核CPU跑这套系统绰绰有余。先把系统基础工具补齐然后安装Docker和Compose插件。初始化时有两个小细节可以省很多事一是给这台机器设置静态内网IP避免后续重启后IP漂移导致端口映射失效二是把时间同步打开因为令牌签发和接口请求都依赖准确时间时钟偏移会导致认证直接失败。4.2 第二步编写认证模块和首次登录取令牌认证模块是基础也是流程里最容易让人卡住的地方。我按设备码授权规范实现了一个状态机等待用户输入设备码、轮询授权结果、拿到访问令牌、刷新令牌持久化、定时预刷新。首次运行时会输出类似这样的提示请访问以下地址完成授权 https://www.playstation.com/... 设备码XXXX-XXXX 等待授权中...按照提示操作完成后程序会返回账号昵称、头像、当前在线状态。到这一步就说明认证链路通了可以把令牌交给数据聚合层了。我建议第一次跑通之后不要急着配置全部功能先只拉一次游戏库数据确认接口字段没问题再继续扩展。4.3 第三步同步调度器的定时任务配置同步调度器我用了简单的Cron表达式配置。三个任务分别对应游戏库、奖杯、价格信息的同步频率。考虑到可能有人还在用机械硬盘存数据我在设计时把所有写库操作都做了批量合并减少I/O次数。定时任务跑起来之后日志输出大致是这样[同步] 游戏库更新完成新增 2 款剔除 0 款耗时 1.8s [同步] 奖杯列表同步完成最近奖杯XXX稀有度稀有 [价格] 港服《XXX》检测到价格变化HK$398 - HK$238看到类似日志时说明整个链路已经通了。同步调度器是整个系统里最不需要聪明的模块保持简单反而是优点。我见过有人在同步模块里加了一堆重试和补偿逻辑最后复杂到出问题都不知道从哪排查。4.4 第四步通知服务的打通与调试通知服务主要做两件事按预设条件过滤价格变化数据生成可读的消息推送到手机。我的触发条件比较直接价格降幅达到20%以上或者在愿望单里低于我设定的心理价位。Telegram机器人的创建很简单关键是消息格式要做得让人愿意看。我建议推送内容包含游戏名、当前价格、历史最低价、降价幅度和商店链接。还设计了一个低频汇总模式避免愿望单里多个游戏同时降价时刷屏轰炸。注意通知消息里不要带HTML标签或过长的特殊字符有些聊天客户端的渲染会对格式异常敏感纯文本加上简单的换行和加粗标记反而是最兼容的方案。4.5 第五步前端静态页面的设计取舍前端页面是整个项目的面子但它不能抢戏。我给自己的要求是三秒内能打开、一眼能看到关键信息、手机上操作不别扭。页面骨架就是一个纯HTML模板加少量JavaScript。数据通过前端网关的只读接口拉取网关再把请求转发给内部的数据查询服务。列表页面做了虚拟滚动几千款游戏的库翻起来也不卡。价格趋势图用了轻量绘图库画一条折线就够不需要花哨的仪表盘效果。5. 部署和日常使用中踩过的三个坑5.1 坑一官方接口的限流比预期更严格第一次全量同步游戏库时因为没做节流结果连续触发了接口限流整个IP段的访问暂时被服务端拒绝。排查的时候看日志还不是报超时而是直接返回了状态码429。这个问题其实可以在设计阶段就规避的——所有远程接口调用都必须外加统一的限速器默认每秒不超过两个请求。修复办法是给同步器加了一个简单的令牌桶限流。之后把全量同步的请求均匀打散到60秒窗口内再没触发过限流。如果要给后来者一个最优先的建议那就是把所有外部HTTP请求都收敛到一个带限速逻辑的客户端对象里去不要散落在各模块里各写各的。5.2 坑二跨区价格数据的坑比想象中深做价格追踪的时候原本想着同一个游戏在各区商店比个价很简单结果被现实教育了。有些游戏在日服和美服是同一个SKU编号但港服可能转成了另一个编号还有的是豪华版包含的内容完全不同直接拉出来的价格根本没法横向比。我加了一个商品归一化的步骤先按游戏的全球唯一标识归组再在组内对比各地区的标准版价格。归组规则里打了几个补丁比如英文名去掉空格和大小写差异、部分副标题单独拆分。最终比价结果才达到了可以放心参考的程度。这个模块如果当初不认真打磨出来的价格建议会误导人甚至建议去一个更贵的区买游戏。5.3 坑三令牌静默过期导致的假活状态有一个阶段面板看起来一切正常但所有数据都停留在几天前日志也没有明显的报错。排查了很久才发现是刷新令牌在某个时刻失效了系统没有侦测到失效仍然继续按旧令牌去请求接口服务端返回401后同步器把它当成暂时性错误跳过了。这个坑暴露了我在设计时忽略的一个点令牌失效不是异常它是生命周期中的正常状态。后来我在认证服务里专门加了对401响应的全局拦截只要收到认证相关错误码立即触发重新授权流程并通过通知服务提醒我令牌已过期请重新扫码。从那之后再也没出现过这种假活状态。6. 项目复盘做个人项目时真正重要的事整个AnyPS5从动手到基本稳定大概花了两周左右的业余时间。回看这个过程我最大的体会是个人项目失败最常见的理由不是能力不够而是范围失控。我最初列的需求清单里还有好友动态流、游戏时长排行榜、截图自动备份这类功能。还好在开工前做了减法把每个功能都问了一遍没有它我会死吗最后保留下来的就是上面介绍的四块能力。事实证明能把一个核心链路跑通跑稳比堆十个半成品功能要强得多。另外想分享一个关于代码组织的经验所有模块之间不要共享内部数据库表模块间通信全部走服务接口。这样做会损失一点性能但换来的是每个模块可以独立演进、独立测试。对我这种一个人维护的项目来说长期可维护性比短期性能重要太多了。如果让我重新做一遍我会把前端部分再往薄里做直接输出只读JSON页面让用户自己折腾。毕竟这个项目的核心价值在数据整合和触达提醒界面只是顺便送的过度投入在界面上反而是浪费精力。这套工具我现在还在日常使用每天推送的降价信息和跨服比价结果帮我在买游戏这件事上省了不少钱和时间。项目源码我整理成了一个私有仓库配置文件都做了模板化处理如果有同样折腾的朋友感兴趣也可以基于这套思路自己搭一套。
1. 从碎片化到一个入口AnyPS5到底解决了什么如果你也是个PS5玩家大概率经历过这种状态主机上装着好几个互不相通的应用手机里关注着好几个资讯号奖杯进度散落在不同平台遇到游戏史低折扣全靠缘分才能刷到。我用了大半年PS5之后突然意识到一个很现实的问题——游戏主机本来是为了让人省心的结果我的时间反而被管理游戏这件事吃掉了。这就是我折腾AnyPS5的起点。它的定位说起来不复杂做一个把PSN账号状态、游戏库、奖杯、折扣通知、系统资讯全部汇总到一个界面的辅助工具相当于给PS5玩家准备了一个自建的中枢面板。我最终跑通的版本不只是能看数据还能做到三件很实用的事跨区商店的价格追踪、折扣到达心仪价位时主动推送到手机、以及好友联机状态的快速查看。适合什么人来参考这篇记录首先是觉得自己游戏库已经多到买了不记得玩的玩家其次是打算用业余时间练手做个人项目的开发者还有就是单纯看不惯官方应用体验、想自己掌控数据的折腾党。这篇内容里我会把我从选型到落地踩过的真实坑全部放出来你可以直接当一份可复现的实操笔记来用。那个版本我起名叫AnyPS5意思就是任何一台PS5都能接入。它不修改主机系统、不碰固件、不涉及破解类操作全部基于官方公开的认证流程和接口能力实现。这个边界我在项目一开始就划得很清楚——做的是辅助层工具不是替代层工具这样后期省掉了非常多的麻烦。2. 核心架构拆解核心模块之间的关系2.1 账号认证模块OAuth流程接入整个项目最关键的模块就是认证。PSN账号体系走的是标准OAuth 2.0授权码模式需要一个客户端标识和密钥来申请访问令牌。这里有个容易踩的坑官方开发者后台申请的客户端在首次登录时可能要求额外验证所以我最后选用的是社区方案里一套公开可用的客户端凭据配合设备码授权流程完成登录。设备码流程比想象中要顺畅第一步程序在终端里输出一个短链接和一个设备码第二步我在电脑或手机浏览器里打开链接用PSN账号登录并输入设备码第三步网页提示授权成功后程序这边会自动拿到访问令牌并刷新令牌。整个过程不需要在主机上做任何操作非常干净。拿到令牌只是第一步。PSN的接口会把玩家的账号信息、游戏库条目、奖杯列表分散在不同域名下所以认证模块之后必须有一个统一的令牌管理服务负责定时刷新访问令牌、把令牌安全地转发给其他子模块。我在项目里直接用了一个独立的容器来跑这个服务其他模块通过内部网络调用不直接暴露到公网。提示设备码授权拿到的刷新令牌默认有效期较长但如果你在PSN账号页主动撤销了设备授权令牌会立即失效程序里要做对应的错误捕获否则整个面板会静默瘫痪。2.2 数据聚合层拉取、归一化、缓存认证搞定之后真正开始干活的是数据聚合层。PSN官方接口的响应格式在不同地区之间并不完全一致比如日服账号和港服账号返回的游戏标题字段名就有差异更别说是美服机器。如果代码里硬编码字段名上线第一天就会被数据教做人。我的做法是先定义一套统一的内部数据模型把游戏分为已拥有已购买未下载入库会免试玩版/Demo四个状态然后用适配器模式写各地区的转换器将差异字段归一化到这套模型上。归一化完成后统一写入本地数据库后续所有查询只走数据库不再频繁请求远程接口。缓存策略上我实际上手后觉得比较合理的节奏是游戏库信息6小时拉取一次因为购买行为不算高频奖杯列表24小时同步一次除非用户手动触发强制刷新价格信息按不同地区设置5到15分钟不等的轮询间隔避免被限流。这样跑下来的压力非常小普通家用主机当服务器都完全扛得住。2.3 通知与前端主动推送和快速查看数据聚合得再全如果不能主动触达用户价值就打了一半折扣。通知模块我设计了两条通道一条是Telegram机器人推送适合在手机端收到你愿望单里的游戏降价了这种消息另一条是Webhook方便接入到自己的其他自动化流程里。前端部分我没有做大而全的后台界面而是做了一个轻量级的移动端适配页面。首页展示账号状态、最近同步时间、愿望单数量第二页是游戏库支持按状态筛选和搜索第三页是价格趋势图。为了加载速度页面完全是静态资源加少量接口调用不引入重型前端框架直接服务端渲染出初始HTML后续需要更新时再局部刷新。3. 为什么这样选型技术决策背后的实际理由3.1 模块化部署而不是单体应用一开始我也纠结过就这点功能是不是写成一个小型单体程序更省事但后来我列了一下需求清单发现事情没那么简单——认证服务要常驻数据同步要定时通知推送要事件驱动前端要响应请求这几个任务的运行模式和生命周期都不一样硬塞在一个进程里会导致一个模块挂了全部停摆。最后用了Docker Compose把项目分成四个容器认证服务、同步调度器、通知服务、前端网关。这样做最大的好处是每个模块都可以独立排查日志、独立重启、独立升级。我中间有一次因为前端页面改版导致网关容器崩溃其他三个容器完全不受影响那个体验对我来说就是选型正确的证明。3.2 轻量数据库降低心智负担数据量最大的是价格趋势表一天存几千条记录一年下来百万级。这个量级用重型数据库属于杀鸡用牛刀。我选了SQLite加WAL模式单文件部署、零运维成本实际跑下来读写完全没压力。有朋友问我为什么不用MySQL或者PostgreSQL我的回答是个人项目的第一优先级是能少管一件事就少管一件事。等数据量大到SQLite撑不住的时候项目本身早就长成另一个规模了到那时再迁移也不迟。盲目在最开始就背一个数据库服务的运维包袱反而是最常见的项目夭折原因。3.3 关于要不要上K8s的自我劝退很多项目到了容器化这一步就开始按捺不住想上Kubernetes。我当时也认真评估了一下结论是坚决不上。K8s解决的是一堆主机、弹性伸缩、服务编排的问题而我的需求就是在一台小主机上跑四个容器docker compose up -d 一条命令就能解决。上了一套编排系统之后随之而来的是网络插件、存储类、Ingress控制器这一大串概念。对一个个人工具项目来说这些复杂度带来的不是收益而是负担。复杂度本身没有罪复杂度超过需求才是问题。4. 从零到可用的完整落地过程4.1 第一步环境准备与初始化宿主机我用的是一台淘汰下来的小主机装的Debian稳定版4GB内存、双核CPU跑这套系统绰绰有余。先把系统基础工具补齐然后安装Docker和Compose插件。初始化时有两个小细节可以省很多事一是给这台机器设置静态内网IP避免后续重启后IP漂移导致端口映射失效二是把时间同步打开因为令牌签发和接口请求都依赖准确时间时钟偏移会导致认证直接失败。4.2 第二步编写认证模块和首次登录取令牌认证模块是基础也是流程里最容易让人卡住的地方。我按设备码授权规范实现了一个状态机等待用户输入设备码、轮询授权结果、拿到访问令牌、刷新令牌持久化、定时预刷新。首次运行时会输出类似这样的提示请访问以下地址完成授权 https://www.playstation.com/... 设备码XXXX-XXXX 等待授权中...按照提示操作完成后程序会返回账号昵称、头像、当前在线状态。到这一步就说明认证链路通了可以把令牌交给数据聚合层了。我建议第一次跑通之后不要急着配置全部功能先只拉一次游戏库数据确认接口字段没问题再继续扩展。4.3 第三步同步调度器的定时任务配置同步调度器我用了简单的Cron表达式配置。三个任务分别对应游戏库、奖杯、价格信息的同步频率。考虑到可能有人还在用机械硬盘存数据我在设计时把所有写库操作都做了批量合并减少I/O次数。定时任务跑起来之后日志输出大致是这样[同步] 游戏库更新完成新增 2 款剔除 0 款耗时 1.8s [同步] 奖杯列表同步完成最近奖杯XXX稀有度稀有 [价格] 港服《XXX》检测到价格变化HK$398 - HK$238看到类似日志时说明整个链路已经通了。同步调度器是整个系统里最不需要聪明的模块保持简单反而是优点。我见过有人在同步模块里加了一堆重试和补偿逻辑最后复杂到出问题都不知道从哪排查。4.4 第四步通知服务的打通与调试通知服务主要做两件事按预设条件过滤价格变化数据生成可读的消息推送到手机。我的触发条件比较直接价格降幅达到20%以上或者在愿望单里低于我设定的心理价位。Telegram机器人的创建很简单关键是消息格式要做得让人愿意看。我建议推送内容包含游戏名、当前价格、历史最低价、降价幅度和商店链接。还设计了一个低频汇总模式避免愿望单里多个游戏同时降价时刷屏轰炸。注意通知消息里不要带HTML标签或过长的特殊字符有些聊天客户端的渲染会对格式异常敏感纯文本加上简单的换行和加粗标记反而是最兼容的方案。4.5 第五步前端静态页面的设计取舍前端页面是整个项目的面子但它不能抢戏。我给自己的要求是三秒内能打开、一眼能看到关键信息、手机上操作不别扭。页面骨架就是一个纯HTML模板加少量JavaScript。数据通过前端网关的只读接口拉取网关再把请求转发给内部的数据查询服务。列表页面做了虚拟滚动几千款游戏的库翻起来也不卡。价格趋势图用了轻量绘图库画一条折线就够不需要花哨的仪表盘效果。5. 部署和日常使用中踩过的三个坑5.1 坑一官方接口的限流比预期更严格第一次全量同步游戏库时因为没做节流结果连续触发了接口限流整个IP段的访问暂时被服务端拒绝。排查的时候看日志还不是报超时而是直接返回了状态码429。这个问题其实可以在设计阶段就规避的——所有远程接口调用都必须外加统一的限速器默认每秒不超过两个请求。修复办法是给同步器加了一个简单的令牌桶限流。之后把全量同步的请求均匀打散到60秒窗口内再没触发过限流。如果要给后来者一个最优先的建议那就是把所有外部HTTP请求都收敛到一个带限速逻辑的客户端对象里去不要散落在各模块里各写各的。5.2 坑二跨区价格数据的坑比想象中深做价格追踪的时候原本想着同一个游戏在各区商店比个价很简单结果被现实教育了。有些游戏在日服和美服是同一个SKU编号但港服可能转成了另一个编号还有的是豪华版包含的内容完全不同直接拉出来的价格根本没法横向比。我加了一个商品归一化的步骤先按游戏的全球唯一标识归组再在组内对比各地区的标准版价格。归组规则里打了几个补丁比如英文名去掉空格和大小写差异、部分副标题单独拆分。最终比价结果才达到了可以放心参考的程度。这个模块如果当初不认真打磨出来的价格建议会误导人甚至建议去一个更贵的区买游戏。5.3 坑三令牌静默过期导致的假活状态有一个阶段面板看起来一切正常但所有数据都停留在几天前日志也没有明显的报错。排查了很久才发现是刷新令牌在某个时刻失效了系统没有侦测到失效仍然继续按旧令牌去请求接口服务端返回401后同步器把它当成暂时性错误跳过了。这个坑暴露了我在设计时忽略的一个点令牌失效不是异常它是生命周期中的正常状态。后来我在认证服务里专门加了对401响应的全局拦截只要收到认证相关错误码立即触发重新授权流程并通过通知服务提醒我令牌已过期请重新扫码。从那之后再也没出现过这种假活状态。6. 项目复盘做个人项目时真正重要的事整个AnyPS5从动手到基本稳定大概花了两周左右的业余时间。回看这个过程我最大的体会是个人项目失败最常见的理由不是能力不够而是范围失控。我最初列的需求清单里还有好友动态流、游戏时长排行榜、截图自动备份这类功能。还好在开工前做了减法把每个功能都问了一遍没有它我会死吗最后保留下来的就是上面介绍的四块能力。事实证明能把一个核心链路跑通跑稳比堆十个半成品功能要强得多。另外想分享一个关于代码组织的经验所有模块之间不要共享内部数据库表模块间通信全部走服务接口。这样做会损失一点性能但换来的是每个模块可以独立演进、独立测试。对我这种一个人维护的项目来说长期可维护性比短期性能重要太多了。如果让我重新做一遍我会把前端部分再往薄里做直接输出只读JSON页面让用户自己折腾。毕竟这个项目的核心价值在数据整合和触达提醒界面只是顺便送的过度投入在界面上反而是浪费精力。这套工具我现在还在日常使用每天推送的降价信息和跨服比价结果帮我在买游戏这件事上省了不少钱和时间。项目源码我整理成了一个私有仓库配置文件都做了模板化处理如果有同样折腾的朋友感兴趣也可以基于这套思路自己搭一套。
