Deck挂起后在另一台电脑继续：Steam动态云同步还需要游戏接续什么

在Steam Deck上挂起游戏，换到电脑继续一段，再回到掌机，玩家期待看到刚刚推进的进度。Steamworks文档用这个场景说明Dynamic Cloud Sync。理解它的关键，是把文件何时传输和游戏何时采用新进度分开：云端已有新文件，并不等于仍在运行的游戏已经把它读进当前会话。[1]

普通Steam Cloud概述把同步放在游戏会话前后：退出后，将相关文件上传；换一台电脑时，在游戏启动前下载。这个安排让新会话有机会读取另一台设备留下的文件。挂起却保留了原设备的会话，因此不能仅凭普通退出、启动的描述，推断唤醒时每个环节都已经完成。

动态同步扩大了可下载变化的时机。文档所述流程先要求应用被标记为支持该能力：Deck挂起时把文件同步到云，另一设备启动时取得更新，游玩并退出后再上传新变化。原Deck唤醒时，Steam会把变化下载到本机，并向应用通知本地文件已经改变。这样的顺序把两台设备之间的交接串了起来。

但通知后还有游戏自己的工作。原文说，应用可以枚举这些变化并采取相应行动，例如从磁盘读取更新的进度，让玩家接着另一台设备的进展继续。这里的读取是游戏需要处理的部分，并非文档对所有已上架游戏的统一承诺。验收讨论如果只写“下载成功”，就还没有回答当前画面是否已采用新存档。

据此，开发团队可以把跨设备复核拆成三个可记录结果：另一设备退出后是否留下预期进度，回到原设备后文件是否完成更新，以及游戏恢复后呈现的是哪一份进度。这是本文整理的核对思路，不是已经执行的测试。发现问题时先定位在哪个环节，可以避免用一个笼统的“云同步坏了”掩盖文件传输与会话读取的差别。

适用条件也要随记录保留。用户可以全局关闭Steam Cloud，也可以只对某个游戏关闭；因此，商店或开发资料显示支持云存储，不能代替当前用户的实际启用状态。文档还明确，动态同步可用于Cloud API与Auto-Cloud两种形式，不应仅凭项目采用Auto-Cloud这个名字，就判断它一定具备或缺少某次会话中的动态接续。

该页预发布测试部分提醒，向所有用户启用动态同步，而运行版本没有处理相应的新方法和回调，可能造成数据丢失。对已经发行的游戏，这个条件使限定测试尤其有意义：先确认当前构建确实能接续文件变化，再讨论扩大范围。本文没有启用功能、修改存档或运行控制台命令，也不保证特定游戏跨设备无损；解释的是需要分别验证的过程。

资料来源：[1] [Steamworks Documentation：Steam Cloud](https://partner.steamgames.com/doc/features/cloud?l=english)。