用途与实际影响
这项功能怎样使用
为什么需要它
微信图片视频很大，不必每次整包重压；直接一边读正在变化的微信目录、一边上传又可能混进不同时间的文件。先建立一份可逐文件核对的本地副本，完整时才让其他副本跟上。
举个实际例子
我问“哪些微信文件已经在 G，旧文件会不会自己又回来”：工具回报已验的当前代与前一代，只有源根可访问且完整枚举时才传播精确删除；整个盘不见了则保留旧副本，不按空库清理。
最后我会得到什么
最近一次G盘成功记录说明已保存微信数据库、图片和音视频约45.42 GB。H盘9月23日已有完成点，但早于这份新Hot；微信Drive上次任务失败且未发起该次上传，云端实际最新内容尚未联网确认。文件齐全不等于微信客户端一定能读回聊天。
正常时
本机文件完整核对后才设为当前备份，留一份前一版本；云端另从这份已验材料复制。
发现问题时
云端单次流量达到上限时报告未传完，等后续任务或明确补齐；旧本机副本仍保留。
入口不可用或证据不足时
来源磁盘读不全或目标不可达时不按空目录传播删除，也不把这次复制说成完整成功。
从哪里开始
在已接入的 AI 对话中明确提出微信原生数据备份或查询 Hot 状态；实际动作由项目已安装的微信备份任务执行。
需要准备什么
- 当前微信原件目录是否可读
- 需全量媒体还是临时只要数据库
- G 或 Drive 目标状态
从开始到拿到结果
- 1
先核对微信原件是否读得全
系统按现有清单检查应用目录和图片视频是否可读；临时只备数据库会明确缺少媒体。
- 2
先形成独立可核对副本
从受约束的同一时间点复制文件，并逐个核对内容；整份成功后才把它设为当前备份。
- 3
按源集合同步与报告
源可完整读取时传播实际删除，整根离线则保留旧副本；云端流量上限或上传未完时不报告完整成功。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
9月24日Hot回执145,544文件、45.42GB；9月23日H冷备完成但较旧，9月20日微信Drive任务失败于本地阶段，客户端恢复未验关键规则与设计选择
9月24日Hot代约45.42GB，仍采用文件级候选，不为每次增量重新压缩整个媒体库。
Hot/Local 先建立独立候选再校验切换，旧成功代保留；可复用的硬链接只来自已验备份，不能把活动原件硬链接进去。
Drive 先复制并核对当前本地成功集合，再在相同过滤范围内删除旧对象并严格复验；快照失败不进入云端写入，DbOnly 不清理已有媒体。
默认 -MaxTransfer 8G 只限制一次脚本进程；WeChatBackup-Drive-Weekly 最多可任务级重试 5 次，每次重新获得自己的单次额度，所以累计流量和云空间仍要另看。
WAL、SHM和journal继续随数据库保留。默认隐藏Hot带UseVss，只有快照真实创建并按它取数才写vss_crash_consistent；手动不带该参数明确写live_source，二者都不宣称应用一致性。
Hot 成功后原子写入并回读有界 JSON 回执；PCConfig 只在回执目标匹配且不超过 36 小时时接受微信热备前置条件。
WeChatDrive-Monitor-Hourly 仅用于首次补齐，当前已禁用；正常运行依赖 Hot 日任务和 Drive 周任务。
本模块用到的名词
- File-by-File Incremental（逐文件增量）
- 针对已压缩的多媒体大目录，按单个文件比对哈希只传变动文件，避免整包重新打包。
- Transfer Fuse（流量保险丝）
- 限制一次 Backup-WeChat 进程的传输量；它不限制多次计划任务重试的累计流量，也不保证云盘总空间够用。
- WAL Co-preservation（预写式日志伴生保全）
- SQLite WAL 模式下可能有已提交事务尚未合并进主库，因此 -wal、-shm 和 journal 不应被备份过滤；一起复制仍不保证运行中快照一致。
- Bounded Hot Receipt（有界热备回执）
- 用完整集合清单、代号、数量与全树哈希验真状态说明这次保全边界；不输出聊天正文，也不证明微信已成功登录。
专业定义
几十 GB 不反复压成整包；先复制验真，再切换当前/前一代。本人从可信原件中删除的文件可以同步退出，整根离线不会当空库。
解决什么
避免大体积微信数据阻塞配置包，也避免每次全量重传；同时防止只看任务名称或目录存在就误以为最近热备一定完成。
当前怎样实现
- Backup-WeChat.ps1 支持 -Target Hot、Local、Drive；Drive 默认上传完整原应用数据，-DbOnly 只传 db_storage，-DriveFull 可覆盖该兼容开关回到完整范围。
- -MaxTransfer 0 会关闭单次 8G 上限，只适合明确的一次性补齐并由人持续看进度；常规定时任务保持默认上限。
- wechat.hot-backup-receipt.v2 绑定完整 manifest（清单）、generation（代际）、数量/字节、sha256_full_tree 与 source_follow_verified，输出不含聊天文件名和正文；状态读取回执而非重新哈希整库。
- WeChat-Recovery.Common.ps1 负责路径规范化、目标/进程检查、复制与回滚；WAL/SHM/journal 的保留来自备份过滤规则，而不是这个恢复模块定位数据库。
- Monitor-WeChatDrive.ps1 监控云端传输状态并在无活跃进程时自动续传，通过 rclone check 闭环后自我禁用。
- tests/Assert-WeChatIncrementalIntegrity.ps1 验证 checksum 内容变化用例，并静态检查流量上限、WAL/SHM 不被过滤和 Hot 回执字段。
执行流程
- 1
微信Hot隐藏任务以当前用户Highest启动，并传入-Target Hot -UseVss；先创建受约束的时点副本，再从该副本捕获。
- 2
复制到独立候选，核对完整文件集合与 SHA-256；仅使用已验备份作为可复用字节来源。
- 3
源根仍可用且集合完整时切换当前与前一成功代，发布 v2 Hot 回执；读不完整或切换失败保留旧成功状态。
- 4
周日 20:00 唤醒 WeChatBackup-Drive-Weekly。
- 5
按远端 binding 锁定本地成功快照，复制、核对后在同过滤范围清旧并复验；不直接边读活动微信边上传。
- 6
默认传完整原应用目录；临时 -DbOnly 只传 db_storage，会失去媒体完整性。仅明确人工补齐时可用 -MaxTransfer 0 关闭单次上限。
- 7
达到单次流量上限时记录未完成，不发布全量成功；正常完成还需严格集合/内容比对，之后的任务重试仍单独累计流量。
边界
- 原应用数据采用文件级增量；源可用且集合完整时传播实际删除，源根离线、无法读全或身份不符不当作空源。
- 默认单次调用设置 8G 传输上限；任务重试的累计流量另算，-MaxTransfer 0 仅供人工看守的一次性补齐。
- -DbOnly 只是临时省流量模式，只保留 db_storage；它不能冒充包含图片、视频等媒体的完整原应用备份。
- 伴随保留SQLite WAL与SHM；VSS只证明文件系统时点，手动live_source还可能跨时刻读取。两条路线均需实际微信客户端恢复验收。
失败与恢复
- 单次上传达到 -MaxTransfer 8G 上限
- rclone 停止本轮继续传输并把非完成结果交给任务；后续任务可继续，但总云空间与累计流量仍需单独观察。
- robocopy 遇到占用、目标空间不足或其他错误并返回 8 以上
- 本轮 Hot 失败且不发布新的 complete 回执；旧热备不删除，下一次任务再补。
- 云端目标路径不可达或网络中断
- 保留本地静态副本并让 Drive 任务返回失败；当前小时监控已禁用，正常重试来自已登记的任务策略。
真实入口
Backup-WeChat.ps1微信原生应用数据增量备份主流水线
G:\80_Backup\ControlPlane\wechat-hot-last.json不含文件名或正文的微信 Hot 完成回执，供 PCConfig 冷备前置检查
WeChat-Recovery.Common.ps1微信恢复路径、客户端状态、本地复制与失败回滚通用模块
Monitor-WeChatDrive.ps1首次云端补齐期间的临时续传监控；完成后禁用，当前并非常规运行任务
tests/Assert-WeChatIncrementalIntegrity.ps1checksum 内容变化 fixture、Hot 回执字段和部分静态接线检查
tests/Assert-CloudBackupIntegrity.ps1远端对象核对与 WAL/SHM/journal 未被过滤的静态合同
如何验证
- 当前来源回归覆盖微信候选、保留与同名内容漂移；网页本轮没有重新执行源测试或修改原应用数据。
- 8G 上限、DbOnly/DriveFull 范围与 WAL/SHM 保留只有脚本/静态合同证据；本轮没有真的传满 8G，也没有运行 SQLite 一致性测试。
- 9月18日历史Hot为145,307文件、45,218,959,121字节，当时PCConfig对G/H全量验真并修复53个同大小/时间的冷备差异；9月22日下一代为145,473文件、45,413,770,744字节。9月24日现存Hot为145,544文件、45,422,871,529字节，生产者报告VSS与全树验真；9月23日H完成回执较旧，本轮未重哈希或同步。
- 本轮 Backup-Status -NoDrive 消费 wechat.hot-backup-receipt.v2 的完整集合和保留结果；同次状态见微信Drive最近任务9月20日因本地复制哈希不符失败、该次上传未请求。没有读取聊天正文、访问云端或把生产者此前验真冒充这次重新计算。
- 云端最后成功采用已发布来源验收与当前小回执；网页没有重列微信远端对象、执行 rclone check 或登录客户端。
与其他模块的关系
把体积大、变化快的微信原应用目录从配置包里拆出来单独维护；热备结果再用有界回执交给 PCConfig 判断冷备前置条件。