用途与实际影响
这项功能怎样使用
为什么需要它
把全部媒体无差别回灌会超过手机容量,也会把录音、缓存和不再选择的对象带回去;只有目录没有实际字节又不能恢复。
举个实际例子
我可以问:“现在这份手机恢复包能恢复多少照片和视频,还缺什么?”系统先只读核对计划、容量和实际文件;确认无误后,只有我明确要求执行才补齐缺失内容。
最后我会得到什么
先知道选中了多少照片和视频、共占多少空间、是否适合当前恢复包;再核对 G 盘里实际已有多少、还缺多少,并按选定范围补齐。预览只报缺项数量,出现同名内容冲突时才指出具体文件。电脑上有完整包,不等于手机已经写回成功。
成功时
所选内容与媒体目录一致,总量低于当前 60 GB 上限;G 盘预览检查没有缺项,大小都匹配。真正写入时还会核对文件内容,成功后才报告电脑恢复包完整,手机回写另验。
发现问题时
缺文件就报告待补数量;目标有同名但不同内容的文件时停止并指明冲突。原件或选择发生变化时重新核对计划。本人删除原件后,只移出能准确对应的恢复副本,不确定属于同一文件的内容先保留。
入口不可用时
G 盘、计划或选定原件不可用时停止恢复同步;保留已有恢复包,不用旧成功回执冒充当前。
从哪里开始
说要准备手机照片视频恢复包;真正回写时再连接手机。
需要准备什么
- 希望手机恢复的照片、视频或相册
- 随身携带的优先级与容量选择(需要时)
从开始到拿到结果
- 1
系统核对并处理
从当前保留集选出手机确实该有的照片视频,对照固定电脑包补齐或移除包内过时派生文件。
- 2
交付与接续
交回电脑包实际状态;第二次连接后才按手机真实差异回写并复核,未连接时明确停在准备完成。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
9月13日Owner回读G手机包2245项、43,010,158,632字节,低于60GB;电脑准备与真实手机回写分开关键规则与设计选择
恢复包只含按实际规则选择的照片/视频;保留的色情图片全部加入、色情视频全部排除、普通视频按需,文档与录音不加入。
录音从不进入手机最小恢复包。
60 GB 是当前产品上限。
recovery-sync 默认 dry-run。
固定包目录跟随当前清单,包外内容和 E 原件不动;用户删原件无需由 AI 代删或通知 AI。
本模块用到的名词
- Sealed plan(封印计划)
- 一组精确选定、带恢复责任的照片/视频清单;变化后必须重新验收。
- Under 60 GB
- 恢复包当前硬上限,保证新手机仍有现实可写回空间。
- Package-external file(包外文件)
- 固定 Images/Videos 受管桶以外的文件;同步保留它们。桶内已不在当前清单的文件属于过时派生项,会在执行同步时移除。
专业定义
恢复不是把整个媒体库塞回手机;它只封装照片和视频中的当前选择,并把容量、缺项和不承担范围说清。
解决什么
解决换机前临时挑选、恢复包超容量、录音与手机职责混淆、计划和实际文件分离以及同步误删。
当前怎样实现
- phone-recovery-plan.ndjson 保存当前选定照片/视频的唯一哈希、大小、源路径、目标路径和相册;总量仍须 <=60GB。
- recovery-status 只核对计划格式、计数、当前目录资格,不证明实际 G 包齐全。
- recovery-sync 默认预览现存、缺项与过时文件,--execute 才同步固定 G 包。
- 未变化文件按大小和修改时间复用;新建/变化项核对原件与落地哈希,优先使用 G 标准副本硬链接,再原子替换目标。
- 目标集合来自当前计划;只清固定 Images/Videos 桶内不再需要的派生文件,保留桶外内容,不删除 E 原件。
- 正式当前库按现存视频引用清理 G 格式变体,不保存独立退役队列。
- 现有每日任务先维护两库清单、再镜像 E→G、最后同步手机包;维护失败不会倒改已经成功的镜像结果。
执行流程
- 1
从 keeper 选择照片/视频
- 2
计算容量并生成计划
- 3
recovery-status 验计划和 catalog(目录)
- 4
recovery-sync dry-run 比较 G 实际包
- 5
按需 execute 补齐
- 6
对已有/新文件做哈希回读
- 7
重新报告
边界
- 不恢复文档、联系人、短信、聊天、账号或应用数据。
- 不把录音放进手机包。
- 不删除固定桶外的文件或 E 原件。
- 用户删除原件后,由既有任务按当前文件与计划同步退出对应恢复项。
- 不把计划存在冒充实际文件齐全,更不冒充手机已写回。
失败与恢复
- 一个新增候选会让包超过 60 GB
- 只跳过该新增项,并在 candidate-refresh receipt(执行回执) 记录 phone_skipped_capacity;保持现行封印包,不为纳入它删除未知原件。若既有/最终计划本身已经越界,status/refresh才整体失败。已明确全部纳入的色情图片若与容量发生真实冲突,须说明实际数量和处理方案,不能用自动跳过把“全部”改成抽选;当前未声明出现这一冲突。
- 计划项缺失
- dry-run 只返回 missing 聚合数;--execute 对全部缺项逐一核验 source 后补齐。需要具体路径时从已授权的 plan/目标范围另行有界查看。
- G 盘不可用
- 返回 unavailable,保留 E 原件和现有计划;不声称恢复包当前可用。
- 包外文件存在
- 保持原样并单独报告,不作为同步删除目标。
真实入口
personal_media.pyrecovery-status 与 recovery-sync
phone-recovery-plan.ndjson当前恢复计划
CLOUD_UPLOAD_RESULT.md2026-09-13当前G手机包数量、字节及独立备份Owner结果
如何验证
- CLOUD_UPLOAD_RESULT.md记录9月13日Owner读取G实物2245项、43,010,158,632字节,低于60GB;网页未重验全包字节或手机写回。
- 既有隔离回归覆盖预览/执行、变化项哈希、固定桶边界、空计划、重复运行与离线根;测试设计与当前生产包验收分开。
- 当前最终媒体状态E/G/H完成回执只证明所属备份范围,不等同手机端已恢复。
与其他模块的关系
它消费分类后的照片/视频 keeper;不拥有云端上传,也不改变本机 canonical 原件。
