那台旧 PS5 被我放在储物柜里大半年后重新翻出来，第一件事不是开机看游戏，而是想找一段三年前的剪辑素材。结果在截图列表里翻了二十分钟，还是靠时间盲猜才找到。当时我就特别想有一个东西，能把这台机器上的截图、录像、存储状态、后台下载进度统一拉到一个我可以随时翻的界面里来。这类需求其实很普通，但官方能力始终缺一块。AnyPS5 就是我针对这个缺口写的自用小项目：通过局域网把任意一台 PS5 识别成统一数据节点，集中汇总存储状态、媒体文件和下载队列，不依赖云、不折腾系统，解掉“机器多了之后数据散落各主机”的麻烦。
这个项目不适用于想改存档、搞越狱、绕过验证的人，它没有任何灰色能力。它解决的是很日常的问题：你有多台 PS5，或者你只是单纯不想每次翻录像都要对着遥控器上下按。你希望数据能在需要的时候被自动整理好，好到“只要打开一个网页就能翻到所有机器上最近拍的片段”。下面我从需求拆解、核心协议、具体实现、踩坑记录四个部分把整个项目讲透。
1. 需求拆解：为什么官方 App 满足不了多主机场景
1.1 多主机家庭的真实碎片
大多数官方 App 的设计逻辑是围绕“账号”转的。你登录之后看到的是自己的游戏库、商店、通知，这些信息很完整，但当你家里有客厅主力机、卧室备用机，或者你偶尔会带着主机去朋友家联机时，真正需要回答的问题会变成这样：
- 客厅那台机器的剩余空间还够不够装下一个 80GB 的大型游戏？
- 卧室那台机器有没有把昨晚的游戏补丁下载完？
- 我上周在朋友家录的那段四人联机视频，现在还在那台机器上吗？怎么把它导出到我的 NAS 里？
- 系统固件是不是更新到一半卡住了？
这些问题全都是“机器维度”的，而不是“账号维度”的。官方 App 不是不能查，而是路径太长：你要先开机、切换用户、进设置、看存储、再去媒体库，还要用手机一个个挑着下载，效率很低。如果机器不在身边，甚至还要先远程唤醒。
1.2 为什么“NAS + 手动导出”的方案不够爽
最开始我试过最笨的办法：定期把 U 盘插到 PS5 上，把截图和录像手动复制到 NAS。这个方法不是不行，但坚持不下来。原因有几个：一是 U 盘插拔动作本身很反人类，主机往往放在电视柜深处；二是手动复制出来的文件命名混乱，系统给的是类似“20250214_203400000”这种名字，不整理根本不知道是哪款游戏；三是容易漏，换了机器之后就很容易忘记上一次导到哪。
AnyPS5 的核心思路不是做一个花哨的控制面板，而是把“导出 + 归档”变成一个无人值守的增量同步过程。抓住“状态读取”和“媒体归档”这两个低频但稳定的能力，剩下的花活都不要。
1.3 项目边界：什么坚决不做
在立项的时候，我给自己定了几条原则：
- 不做任何绕过加密、修改系统、盗取会话的行为；
- 不做存档修改，不碰任何可以让玩家免费获得付费内容的路径；
- 不依赖公共云中转，所有数据只在局域网流动；
- 不做跨公网暴露，连端口转发都不要开。
原因很简单：涉及主机的私有接口本身就比较脆弱，一旦使用不当，轻则功能失效，重则可能带来账户安全隐患。做一个自我管理的工具，前提是控制好风险半径。把一个数据归档需求做成纯本地方案，逻辑上最安全，维护上也最省心。
2. 核心细节解析与实操要点
2.1 设备发现：让“任意一台 PS5”都出现在同一个列表里
AnyPS5 第一个要解决的是“如何找到机器”。家里如果只有一台机器，你可以手动填 IP，这没问题。可一旦有两台、三台，或者机器开启了 DHCP 导致地址频繁变化，就必须做一个自动发现机制。
实际用下来的方案分三步：
- 客户端在当前局域网段做端口探测（常见管理端口），识别出候选设备；
- 对候选设备发送一个轻量握手请求，能返回正确的机器标识才认定为主机；
- 用户确认屏幕上显示的名称与验证信息。
这里有几个很容易踩的坑。第一个是过滤条件不能做得太死。我第一版按主机名前缀匹配，结果把隔壁房间的电视盒子、智能音箱全部扫进来了，因为它们的设备名也能匹配部分关键词。后来改成“先探测端口，再握手，再核对能力字段”，误报率才降下来。
第二个坑是主机的休眠策略。机器进入待机后，网络唤醒通道不一定稳定，扫描结果时有时无。处理办法是把“唤醒”和“发现”两步分开：先扫，拿不到就尝试发送网络唤醒包，再等 10 到 15 秒重新扫描。
兼容性方面，不同地区版本的主机显示名、语言字段、单位格式都可能有差异。比如存储容量在不同固件上可能是 GB 也可能带小数，中文界面和英文界面的很多字段描述完全不同。所以我在解析的时候坚持一个原则：所有内部逻辑只认机器标识和设备编号，不认本地化文本；本地化文本只在页面上给人看。
2.2 存储状态读出来的粒度与单位
很多人在做状态展示时只看一个“剩余空间 XGB”，但这个数据其实不够用。PS5 的存储分为内部存储、USB 扩展存储（可以运行游戏）和普通外接存储（只能放媒体），三者对玩家的意义完全不一样。
实操中我把存储信息拆成了这样几个维度：
| 维度 | 说明 | 判断意义 |
|---|---|---|
| 内置存储 | 系统、存档和部分游戏所在盘 | 空间吃紧会直接卡游戏安装 |
| 扩展游戏盘 | USB 接口的扩展硬盘，可以装游戏 | 游戏库越大越需要关注 |
| 媒体存储 | U 盘等非游戏存储 | 截图视频的导出目标 |
| 系统版本 | 固件版本号，决定功能可用范围 | 部分接口在老版本上字段不一致 |
单位换算也值得单独说。很多设备返回的字段是以十进制字节为单位，玩家习惯的是“GB”。如果你在代码里直接用“除以 1024”的二进制换算，显示出来的数字会偏小，看着难受。我在工具里统一保留了原始字节值，只在展示层做一次格式化，这样既不会丢失精度，也不会因为前后端各换算一次导致数据对不上。
另一个经验是描述剩余空间时，不要只显示“还剩 300GB”，最好把“预计还能装下几个大型游戏”也计算出来。按当前市面上常见大作的口径，一个作品约 60 到 80GB，我就用 70GB 作为单游戏预估占用，顺便提示“按当前剩余空间约可再安装 4 个大型游戏”。这个信息在买新游戏前非常直观。
2.3 截图和录屏的归档流水线
这是整个项目里我个人用得最多的功能。流程不复杂：先列目录、拿时间戳、做增量比对，然后把新文件拉回来重命名归档。
归档目录结构我最终定为：
archive/ {机器标识}/ {游戏标题}/ {YYYYMMDD}/ {HHMMSS}_{原始文件名}.jpg用机器标识而不是机器名，是为了避免 IP 变化导致数据目录拆散；用游戏标题做二级目录，是出于找素材的可读性；时间目录则让所有数据天然按天组织，翻老素材时非常快。
传输策略是文件大小加修改时间双重校验。一开始我也想先算全量哈希，但实测下来一个几万文件的媒体库，全量哈希要跑很久，而实际增量通常只有几十个文件，性价比太低。所以先用“大小 + mtime”做粗略过滤，再对疑似文件单独做一次大小比对，大部分场景下已经足够。
并发下载控制在 2 到 4 个。刚开始我把并发拉到 8，确实快，但把主机端的响应服务拖得很慢，甚至出现某些文件下载超时。后来限制并发数，同时把大文件（比如长录像）拆成单独的后台任务，整体稳定性高了很多。
这里必须强调：这个工具永远不会主动删除主机上的源文件。它的设计哲学是“只增量拉取、不清理”，因为删数据这件事风险太高，一旦误删，没有任何找回手段。玩家想清理素材，自己到机器上手动操作就好。
2.4 后台下载任务和系统更新进度
PS5 的后台下载不只有游戏本体一个类型。常见的有游戏下载、补丁更新、预载内容、应用安装、系统更新等。这几种任务混在一个列表里时，如果只做统一的百分比展示，会误导人。
我在实现时的做法是：
- 先把任务按类型分开：游戏下载、内容补丁、系统固件、其他；
- 再按状态区分：排队、下载中、暂停、已完成、失败；
- 最后才计算进度百分比。
进度计算也不能只看“已下载 / 总大小”这一个公式。有些任务的总大小是动态变化的（比如补丁下载时先获取元数据再更新总量），如果拿旧数据和新数据直接除，会出现进度回退的奇怪现象。我的做法是每次刷新时记录“字节数和总大小”两个值，如果本次总大小小于上次记录的总大小，就重新拉取任务元数据，而不是直接更新 UI 里的进度条。
刷新频率也做过调优：下载队列这种实时变化的数据，我用 10 秒轮询；存储状态是低频数据，30 秒到 1 分钟刷一次就够了；媒体列表索引 5 分钟一次。这样既让页面看起来“活”着，也不会给主机造成无意义的负担。
2.5 安全与认证：不给局域网留后门
连接的安全设计是整个项目最不能省的部分。PS5 的私有接口在握手时会要求校验设备信息，整个过程本质上就是一次互认。
我实现的简化版握手流程是：
- 扫描到候选设备后，客户端生成随机会话标识；
- 主机屏幕上显示一段验证码，用户输入到 AnyPS5 界面；
- 客户端用验证码换取一个短期会话令牌；
- 后续请求都带着会话令牌，并在固定时间后自动过期。
会话令牌我会存在本地 SQLite 数据库里，但不会明文打印到日志中。同时这个工具只监听本机回环地址加局域网地址，绝不绑定公网接口。任何从外网访问的请求都直接拒绝。
有一些人可能会觉得加上 HTTPS 证书校验是多此一举。但根据我自己的实操经验，如果局域网内有其他设备监听，一套校验能极大降低中间人风险。至少做一件事：把主机首次握手时返回的证书指纹记录下来，后续请求比对指纹，如果变了就提示用户确认，而不是直接接受。
3. 实操过程与核心环节实现
3.1 技术选型与目录结构
这个项目我用了 Python 3 + FastAPI 做后端，前端是一个不带构建工具的静态单页。没有数据库依赖，直接用 SQLite 存索引。选型的原因很简单：Python 写起来快，requests、cryptography 都是现成的，SQLite 对几万条媒体索引的支撑完全够用。前端也不需要高交互，一个卡片式仪表盘足矣。
项目目录结构：
anyps5/ app.py # 主服务入口 discover.py # 局域网发现与握手 collector.py # 媒体归档与增量同步 models.py # SQLite 数据表定义 config.example.yaml # 示例配置 frontend/ index.html # 单页面板 app.js data/ archive.db # 本地索引3.2 发现与认证流程
发现模块核心步骤可以用以下片段表达：
def scan_network(segment: str, port: int): candidates = [] for ip in make_hosts(segment): if is_port_open(ip, port, timeout=0.5): handshake = try_handshake(ip, port) if handshake and handshake.get("device_type") == "ps5": candidates.append({ "ip": ip, "console_id": handshake["console_id"], "firmware": handshake["firmware"], }) return candidates这里的注意点是端口探测的超时不能设太大。局域网内机器不多，0.5 秒足够；如果用默认 3 秒，扫完一个 /24 网段可能要几分钟，体验很差。握手次数也要做限流，连续失败超过 5 次就跳过这台设备，避免把主机服务打挂。
认证阶段的核心是等待用户输入主机上显示的验证码。这块我没有尝试自动化，因为自动化读取验证码需要额外权限，安全性反而降低。人工输入是不可替代的环节，不仅简单，而且可靠。
3.3 媒体增量同步的核心循环
媒体同步是整个项目逻辑最重的一部分。
def sync_media(device, last_cursor): media_list = device.list_media(since=last_cursor) for item in media_list: dest = build_archive_path(device.console_id, item) if not should_skip(item, dest): device.download(item.uri, dest) record_item(item, dest)should_skip的逻辑是检查目标目录里是不是已经存在“大小一致”的同名文件。如果存在就跳过，不存在才拉取。这里我不会一见到同名文件就直接跳过，因为同一天里完全可能录制两个同样大小的片段。所以文件名里必须带上原始媒体 ID 或时间戳，确保唯一性。
下载完成后会用 SQLite 记录一条索引，包含机器标识、游戏标题、日期、本地路径、原始文件名、大小、拉取时间。后续页面上的搜索、筛选都是基于这张表，而不是每次实时扫目录。
对于比较大的录像文件，我增加了一个“仅拉缩略图预览”的选项。缩略图体积小，拉回来后可以立即在页面里铺开浏览，真正需要原片时再触发完整下载。这样体验上会把“找到 10 分钟前录的片段”缩短到几秒。
3.4 前端展示与刷新策略
前端我做成了最直观的仪表盘布局：
- 顶部是设备总览卡片，显示每台主机的型号、系统版本、存储剩余空间、网络状态；
- 中部是最近媒体流，按时间倒序排，缩略图做懒加载；
- 底部是下载任务列表，实时更新进度和速度。
为了避免页面频繁刷新的闪烁问题，数据请求分成了几条独立轮询线：下载任务每 10 秒刷新，存储状态每 30 秒刷新，媒体列表每 5 分钟刷新。每次请求都在后台做，不阻塞界面操作。
另外我加了一个手动刷新按钮，专门用于“刚在机器上录了新视频，想立刻看到”的场景。这个功能非常实用，不然每次录完还要等 5 分钟轮询，急性子根本受不了。
3.5 测试参数与超时控制
给主机做请求，超时要特别讲究。连接超时设 3 秒，读超时设 15 秒；但下载大视频时要放宽到 120 秒。因为大文件传输中如果读超时设得过短，很容易被误判成连接失败。
重试策略用指数退避：第一次失败等 1 秒，第二次等 2 秒，第三次等 4 秒，最多重试 5 次，之后放弃并把任务标记为“失败”。这个策略在局域网偶发抖动时非常稳定，既不会频繁误报，也不会一直卡着不结束。
我在测试时故意模拟了这些异常：主机待机、主机重启、网线松动、DHCP 地址变更、文件正在被写入。每一次都要确认页面能给出正确状态提示，而不是白屏或者转圈。尤其中途断网后重新连接，会话令牌必须能自动续签，否则就得让用户重新输入验证码，体验很差。
4. 常见问题与排查技巧实录
4.1 问题速查表
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| 扫不到设备 | 不在同一网段，或路由器开了 AP 隔离 | 先把手机和主机连到同一 Wi-Fi，关掉访客网络/设备隔离；或固定主机 IP |
| 握手超时 | 主机处于待机状态 | 开启网络待机选项，先发送唤醒包再等 15 秒重新扫描 |
| 证书指纹变化 | 主机固件更新或本地服务证书重建 | 更新指纹库，重新执行一次人工确认 |
| 媒体列表为空 | 当前用户没有媒体内容，或未切换对应登录账号 | 确认机器上已登录有内容的用户；检查分享/同步设置 |
| 下载中断 | 大文件读超时或并发过高 | 增加读超时时间，降低并发数到 2 至 4 |
| 存储空间数值对不上 | 旧索引脏数据，或中间换算过单位 | 删除对应机器标识的历史记录后重新建立索引 |
| 任务进度条回退 | 任务总大小动态变化 | 刷新时重新获取任务元数据，不要沿用旧总大小 |
4.2 两条独家避坑
第一，第一天千万别急着做前端界面。先把“机器原始 JSON 转储”做成一个调试页，把所有拿到手的字段原样打印出来。因为这些私有接口的字段并不会永远稳定，只有当你清楚知道字段长什么样、什么时候会缺失，才能真正写好解析代码。先看数据再建 UI，能少走很多弯路。
第二，测试文件大小一定用贴近真实场景的参数。很多人喜欢写个 5MB 的小文件来验证下载流程，但这种测试根本没有意义。一台主机上随便一个 4K 视频就是几百 MB，真正的瓶颈在网络吞吐、磁盘写入和超时控制上。建议至少用一段 3 分钟长度的 4K 视频（大约 300MB）做稳定性测试，这样才能暴露你在小文件测试里完全看不到的问题。
顺便给一个粗略的容量参考：假设你每天录 10 段 3 分钟左右的 4K 片段，一天就是 3GB 左右，一个月接近 90GB。如果归档目标是 NAS，这个量级很轻松；如果归档目标是主机内置存储，就需要定期清理导入后的原片。AnyPS5 不做自动删除，但我会在页面里统计“每周预计新增”这个指标，提醒你尽快转移素材。
我在实际使用中最大的体会是：这类工具最重要的不是技术多高深，而是让数据的流向足够稳定、可预期。AnyPS5 做到现在，我最常用的其实只有一个功能——每天早上自动把昨天分散在几台主机上的片段归到对应游戏目录里。当你在大屏上回顾一周素材时，那种“不需要被数据追着跑”的感觉，才是这个工具真正值钱的地方。如果你也想折腾，建议从小切口开始，先搞定一台机器的状态读取，再慢慢扩展到多台，最后再考虑自动化归档，这样调试负担会小很多。
