Steam 显示云存档已是最新，但存档却不见了？再次启动前先保全两台设备

为什么“云存档已是最新”仍可能没有存档

Steam 只能同步游戏或开发者为 Steam Cloud 配置的文件。同步成功只证明这些已配置文件的传输完成，并不证明游戏把进度写进了这些路径。成就、游玩时间等账户数据仍在，也不能证明具体存档曾经上传。

同一游戏在 Windows、原生 Linux、macOS 或 Proton 中可能使用不同根目录。Steamworks 还允许开发者按平台分隔或覆盖根目录。因此桌面电脑与 Steam Deck 都可能显示同步正常，却在读取不同位置。另一个 Steam 账户、试玩版、测试分支或不同 AppID 也会造成同样现象。

1. 确认账户、游戏版本与 AppID

在每台设备上记录当前 Steam 账户、游戏 AppID、分支或测试版、操作系统，以及 Linux 或 Steam Deck 使用原生版还是 Proton。确认全局和该游戏的 Steam Cloud 当前状态，但先不要切换开关。

使用发行商说明或该游戏在 PCGamingWiki 的页面确认真实存档路径。如果两台设备使用不同版本或 AppID，应先确认兼容性；有效存档放入错误身份或版本的目录后，游戏可能直接忽略。

2. 保全所有候选副本，不只备份 userdata

复制每台设备的实际存档目录。Windows 存档可能位于 Documents、Saved Games、AppData、游戏安装目录或发行商目录；Linux 可能位于原生配置目录。通过 Proton 运行的 Windows 游戏通常会在 steamapps/compatdata/<AppID>/pfx 下保存 Windows 风格数据，但精确路径仍由具体游戏决定。

同时复制匹配的 Steam userdata 区域。Valve 的支持文档会用 userdata 与 cloud_log.txt 排查 Cloud，但 userdata 可能只是同步暂存或缓存位置，并非游戏运行时读取的目录。两者都要保全，不要预先认定哪一份是权威副本。

3. 盘点远端副本，不覆盖本地证据

打开该游戏的 Steam Remote Storage，将所有可用文件下载到新的证据文件夹，记录文件名、大小与修改时间。最新时间不一定代表最佳进度：丢档后生成的空存档可能比正确存档更新。

如果游戏内有编号存档位、角色名或内部时间，也把它们作为比较依据。保持原始下载文件不变，只用复制件进行测试。

4. 把 cloud_log.txt 当传输记录，而不是进度证明

完全退出 Steam 后，查看已复制的 cloud_log.txt，重点检查最后一次正常会话与首次发现进度丢失前后。寻找 AppID、文件路径、上传、下载、冲突处理和错误信息。这可以说明 Steam 是否传输了不同路径，或跳过了某个文件。

日志不能证明被传输文件包含正确的游戏进度。必须结合已保全文件，并在离线、关闭 Cloud 的情况下做一次受控验证。

5. 按证据选择恢复分支

旧设备存在正确存档：让旧设备保持离线并再做一份备份；在测试设备上关闭该游戏的 Cloud，把副本放入已确认的活动存档路径，再检查正确存档位是否能加载。

只有 Remote Storage 有正确文件：保留原下载文件，用复制件在关闭 Cloud 时恢复。如果游戏忽略它，重新核对账户、版本、AppID、平台路径、文件名，以及配套的索引或个人资料文件。

Steam 显示冲突：不要只按时间戳选择。尽可能保全两个候选副本，并与离线备份比较；只有某一副本在受控测试中正确加载后才选择它。

没有任何正常来源：停止破坏性尝试。保存所有目录、远端下载与日志，并向开发者或 Steam Support 提供 AppID、账户、设备、系统、时间和缺失存档位。Valve 提醒，已删除或被覆盖的 Cloud 数据可能无法恢复。

6. 重新启用 Cloud 前验证完成条件

关闭 Cloud，并在可行时断开网络，只用副本启动一次游戏。确认游戏内的个人资料、存档位、检查点、物品或游玩时间正确。正常退出，确认活动目录中的预期文件发生变化，然后再做一份备份。

随后只让一台设备联网并重新启用 Steam Cloud。留意冲突提示并确认同步干净完成；再次在同一设备验证进度，然后才让第二台设备上线。在两台设备都加载相同已验证状态前，保留所有原始副本。

不要这样做

不要反复在两台设备启动游戏等待存档自行回来，也不要假设修改时间更新的文件一定包含更多进度。

不要在未确认版本与真实路径时把 Windows 存档直接放进 Proton 或原生 Linux 目录；不要在逐字节复制前删除 userdata、compatdata 或存档目录；不要把成就或游玩时间当作存档已经上传的证明。