Steam 云存档冲突,该保留哪一个?
Steam 云存档冲突时,先保留副本,再核对最后游玩的设备和进度。结合三款游戏的实际商店数据与开发商说明,解释文件怎么找、PC 与 Steam Deck 怎么换着玩,以及客服无法恢复存档的限制。
文章语言
准备开游戏,Steam 却让你在本地文件和云端文件之间选一个。如果还没弄清昨天的进度在哪边,先别选。找到最后游玩的设备,把能拿到的存档另存一份,再比较两边。只凭“云端”两个字,或者日期看起来更新,就决定覆盖哪一份,可能很难补救。
选择之前,先保留还能找到的文件
先读警告在问什么。两份版本不一致,需要你选择,和目前无法同步,并不是同一种情况。前者要判断继续使用哪份进度;遇到后者,则需要先判断是否要在尚未同步的状态下启动游戏。看到同步失败,不能直接认定两份存档已经发生冲突,也不能仅凭这句话判断问题出在上传还是下载。
Valve 的 Steam Cloud 说明提醒,忽略同步失败的警告继续玩,可能造成冲突或进度丢失。游戏能启动,并不表示它会载入你想要的记录。即使警告没有完全阻止启动,只要最后一次游玩发生在另一台设备上,就值得先查那边。

第一张图重建的是官方 FAQ 里较早的 Portal 冲突示例。文中的示意图和表格不是当前账号的冲突截图,也不是恢复成功的案例。实际按钮文字与位置,以你正在使用的 Steam 界面为准。
记下游戏名、两边日期,以及按钮表示上传还是下载。“本地”指的是当前这台设备。昨天主要在台式机上玩,不代表台式机的文件永远叫本地文件;今天用笔记本打开冲突窗口,本地就是笔记本上的那一份。云端则是 Steam 服务器上的版本。
再核对最后游玩的设备和当前登录的账号。昵称相似不够,要确认实际用哪个账号启动了游戏。共用电脑时,也看看操作系统的用户是否相同;用户或账号不同,寻找存档的位置可能就不同。下面会按游戏说明具体路径。
我会先把两边到底是什么状态弄清楚,再想办法消除警告。能找到的存档文件夹,可以复制到游戏同步范围之外,保留操作前的一份副本。这里说的是复制,不是移动原文件夹、改名或替换文件。也不是保证你能下载所有云端版本。窗口里看得到一条记录,和已经保管好那份文件副本,要分开看。
如果游戏已经在运行,别为了“看看还剩什么”就新建游戏,或打开别的槽位再保存。有的游戏退出时也会写入存档,需要先了解它的保存方式。若仍停在启动前的警告窗口,也没必要为了找文件特意进入游戏。复制期间应避免游戏继续修改文件;不清楚退出与保存如何衔接,就先读开发商的说明。
先把日期截图,随便选一边,出错再问客服——我不建议这样做。截图能说明窗口当时显示了什么,却没有保存游戏进度本身。暂时用不了另一台设备,或者记不起想保留的进度在哪边,可以推迟选择。
日期更新,不一定进度更多
日期当然要看,但最好同时记下那一刻做了什么:在哪台设备打过最后一个首领,进入新区域后有没有保存,一直在玩的角色叫什么。记得几点打开游戏,和确认几点完成保存,也不是一回事。
下面是假设的两台设备使用过程,只用来说明怎么判断。它不是用户事故记录,也不代表某款游戏的真实自动保存机制。所有时间统一使用韩国时间,章节 5 和章节 7 同样是示例。
| 假设时间 | 设备与操作 | 这个例子中留下的记录 |
|---|---|---|
| 9 月 1 日 21:00 | 台式机保存到章节 5,同步完成 | 其他设备能够取得章节 5 的记录 |
| 9 月 2 日 20:00 | 笔记本接着玩到章节 7,离线保存 | 笔记本有章节 7,但尚未上传 |
| 9 月 2 日 22:00 | 台式机从章节 5 的记录继续玩了一会儿,保存并上传 | 云端日期更晚,却没有章节 7 的进度 |
| 9 月 3 日 | 假设笔记本联网后出现冲突窗口 | 需要比较笔记本与云端的记录 |

按这个例子的条件,想接着玩章节 7,就应先保留笔记本上的那份存档。窗口也是在笔记本上打开的,所以它对应本地文件。云端虽然显示更晚的 22:00,但那次上传来自章节 5 之后的另一段游玩。只因为日期更新就下载云端版本,会与想留下章节 7 的目的相反。
换成自己的情况,只填确实知道的部分。记得在笔记本保存过,却没确认上传成功,就把两件事分开写。“游戏都关了,应该传完了”不能直接记成同步完成,否则之后的判断也会跟着这个猜测走。还没检查旧设备的文件,就又在那台设备玩一次,也可能让经过更难理清。
有时,云端才是该取回的那一份。例如,最后在另一台电脑保存到了想要的进度,并且确认那台电脑上传的正是目前的云端版本,那么取回这份记录就符合目的。当前设备刚重装,或是许久没用的笔记本,也能帮助判断。不过,别仅仅因为设备旧,就先删掉里面的存档。那里可能还有另一个角色;在确认不需要之前,可以先保留。
如果两边各玩了不同内容,就未必存在一个“完全更新的版本”。一边推进了主线,另一边收集了物品,两份各有另一份没有的内容。不要期待冲突窗口替你把两边的好处合在一起。游戏有没有独立的合并或导入功能,要查该游戏自己的规则;把文件放进同一个文件夹,也不会自动合并两段进度。
文件大小只能作辅助信息。查阅的资料没有给出“文件更大,就完成了更多任务或玩得更久”的判断规则。有差异,可以进一步查原因;不能据此直接选大的。两份大小相同,也不等于内容已经确认一致。
日期和记忆对不上时,先看两个界面的时间格式、时区是否相同,以及比较的是文件修改时间还是游戏内游玩时间。跨过午夜,“昨天存的”就容易说不清。保留原来的显示文字,再补上具体日期和设备,之后求助也更容易讲明白。这里不建议修改文件时间来让数字看起来吻合。
真正选择前,试着把目的和操作连成一句话:“我想留下笔记本上的章节 7,所以使用当前的本地文件。”如果能说出的理由只有“按钮在上面”或“网上都说选云端”,就还缺判断依据。最后再核对窗口上的上传、下载方向,确认这次操作会把哪一边的内容同步到另一边。
Steam Cloud 标记能说明多少
商店具体列出了哪些支持项?这次实际查询了 Portal 2、Stardew Valley 和 Hades 的公开 Steam 商店数据,查看其中的 Steam Cloud 功能项和操作系统标记。
2026 年 9 月 5 日 07:57:01–07:57:03 UTC,也就是韩国时间 16:57:01–16:57:03,分别取得了一次 Portal 2、Stardew Valley 和 Hades 的响应。三个请求都使用美国地区、英语,且均正常返回。表中只记录响应里的 Steam Cloud 功能项和 platforms 字段。
| 查询的游戏 | Steam Cloud 功能项 | Windows | macOS | Linux |
|---|---|---|---|---|
| Portal 2 | 有 | true | false | true |
| Stardew Valley | 有 | true | true | true |
| Hades | 有 | true | true | false |
true 与 false 是这次商店响应里的操作系统标记,不是安装游戏后跑出来的兼容性测试结果。Hades 的 Linux 值为 false,不能据此说它无法通过 Proton 或在 Steam Deck 上运行。Portal 2 的 macOS 值也只是本次响应的值,不能用来概括它所有旧版本的支持历史。

这三款是为了说明问题而选的游戏,不是代表全部 Steam 游戏的样本,也没有测量云存档错误率或恢复成功率。公开商店响应可能经过缓存,取得响应的时间不能当成每个字段更新的时间。这次没有登录账号,也没有启动游戏。
三款都带有 Cloud 功能项,能确认的只是商店列出了这个功能。自己账号有没有启用同步、具体覆盖哪些文件、刚才的存档是否上传成功,还得另查。不能拿这张表承诺某款游戏的设置、模组和存档全都可以恢复。
Steamworks 的 Cloud 文档说明,开发商负责配置同步的文件组和路径。Auto-Cloud 能否跨操作系统共享,也取决于路径及其他系统的路径覆盖配置。对玩家来说,需要分别找两个答案:这款游戏能不能在另一种系统运行;原来的存档能不能在那里继续用。
查开发商说明时,可以留意存档位置、哪些版本能共享,以及哪些文件不在同步范围。某个槽位或设置没带过去,先问它是否属于同步对象。其他设置到了,不代表进度也到了;一个设置恢复默认,也不能直接推断全部存档消失。
设备上的设置同样要单独确认。在 Steam 库里打开该游戏的 Properties,查看 General 下的 Steam Cloud 项。只是检查的话,先记下当前状态。关闭再开启这个选项,不能替你判断该保留哪份文件。还需要保护另一台设备进度时,别把修改设置也混进来,免得同时改变太多条件。
存档文件夹要按游戏来找
复制 Steam 安装目录,不一定就把所有游戏的存档带走了。即使从库里找到了游戏安装文件,那里也未必是保存进度的位置。套用搜索结果里的路径之前,先确认开发商的说明对应同一款游戏、同一种系统和自己使用的版本。
先看 Stardew Valley。开发商的存档问题排查指南给出的 Windows 路径是 %appdata%/StardewValley/Saves。在里面找到以角色名开头、后接下划线和数字的文件夹。与这个文件夹完全同名的文件保存角色进度,SaveGameInfo 则负责在载入菜单显示角色信息。
| Stardew Valley 角色文件夹中的项目 | 开发商说明的用途 |
|---|---|
| 与角色文件夹同名的文件 | 载入角色所需的实际存档数据 |
SaveGameInfo | 载入菜单中的角色信息 |
原存档文件名后加 _old 的文件 | 若存在,是游戏生成的上一份存档副本 |
SaveGameInfo_old | 若存在,是上一份菜单信息副本 |

按开发商的解释,SaveGameInfo 缺失或损坏时,角色可能不出现在载入菜单里,但实际存档仍可能存在。仅凭菜单里看不到角色,不能断定云同步删除了整个农场。反过来,看到一个文件,也还不能确认它能正常载入。
先把整个角色文件夹复制出来。别因为某个文件很小、看起来没用就漏掉它;若有 _old,也一起留着。指南里的 _old 指游戏内前一天的进度,不是每隔现实时间 24 小时积累一次的云端历史,也不是所有游戏都有的文件。还没弄清一组角色文件如何配合之前,不宜只挑其中一个。
找不到文件夹时,先核对最后使用的 Windows 用户。开发商也提醒检查是否为同一个 Windows 账号。找错用户目录,和正确位置确实没有文件夹,是两种不同情况。看到路径为空,再手动新建一个同名文件夹,并不能恢复原来的进度。
Hades 的官方技术支持指南列出的默认位置,Windows 是 C:\Users\[USERNAME]\Documents\Saved Games\Hades\,macOS 是 ~/Library/Application Support/Supergiant Games/Hades。其中 [USERNAME] 应对应实际用户名。这是 Hades 的路径,不是 Hades II,也不适用于所有 Steam 游戏。如果移过“文档”文件夹,或使用了其他保存位置,需要确认实际路径,只查默认目录可能漏掉文件。
Hades 文档还区分了槽位 1 的进度文件 Profile1.sav 和设置文件 Profile1.sjson。名字相似,扩展名不同,用途也不同。这里不是让你删除或替换其中某个文件。看到“重置设置文件即可解决”的帖子,先看它究竟在修改什么,别直接当成存档冲突的处理办法。
副本要能看出来自哪台设备。可以在保管文件夹的名字里写上设备和复制日期,再把原存档文件夹完整放进去。不要在游戏实际读取的目录里改名,也不要把另一台设备的文件直接覆盖过来。两台设备取得的副本分开放;因为名字相同就合并到一起,可能把本来要比较的两种状态混掉。
保管位置也要看一眼。在游戏同步路径里面新建一个“备份”文件夹,不一定就形成了独立保管。我建议放在游戏读取和同步范围之外。如果目标目录还使用了其他文件同步服务,也要了解那项服务会做什么,避免原存档和保管副本一起被自动替换。
复制完成后,打开目标文件夹,看看角色文件夹和具体文件是否真的在里面,而不只是多了一个空目录。核对名字和数量即可,不需要为此启动游戏,也不需要用存档编辑器重新保存。确认复制成功,仍不等于验证恢复成功;原文件已经损坏,副本也可能保留同样的问题。
官方指南还包含一些修复操作,但移植其他角色的部分内容、重命名文件,都需要先理解该游戏的条件。本文只讲保留原件和认清文件用途。不知道网上某条删除命令具体指向哪个目录、哪些文件,就先停下。找存档并不需要顺便清理整个 Steam 文件夹。
在 PC 和 Steam Deck 之间切换时
经常换设备玩,可以把检查放在切换时,不必等冲突后再追查经过。平时先在原设备按游戏的方式保存、正常退出,确认 Steam 的同步状态,再转到另一台设备。新设备也要检查同步状态;若出现失败警告,先别急着启动游戏。这是日常使用习惯,不是让已经发生冲突的人重新开游戏做一次实验。
Valve 的开发者文档介绍了通常在游戏启动前、退出后进行的同步。游戏内按了保存,不等于另一台设备已经收到文件。因此,关闭原设备或断网前,还要看 Steam 是否处理完。这里不规定等几秒、几分钟:既没有实际测过,也没有查到适用于所有游戏的统一时限。

离线游玩尤其需要单独记住。路上没网时推进的内容,在联网前不能传到其他设备。回家若直接打开台式机,上面可能还是出门前的旧记录。先确认离线游玩的设备留下了什么文件,之后另一台设备有没有也玩过。如果两边已经各走了一段,应该回到前面的比较步骤,不要照日常切换流程自动继续。
Steam Deck 的睡眠也不宜直接当作退出游戏。Valve 提供 Dynamic Cloud Sync:配置为支持这项功能的游戏,可以在挂起时上传文件,并在 Deck 唤醒时接收其他设备的修改;游戏本身也需要处理已经变化的文件。不能因为存在这项功能,就说所有游戏睡眠后都能以同一种方式接着玩。
没确认当前游戏如何支持它,平时就以保存、退出、检查同步状态为准。也不建议玩家输入开发者测试命令,试图强行开启支持。强行打开选项,并不能保证运行中的游戏会正确处理新收到的存档。
前面商店数据里,Hades 的 Linux 标记为 false,但 Supergiant 的 Hades 指南另有明确说明:云存档已启用,而且两台设备登录同一个 Steam 账号时,PC、Mac 的 Steam 版与 Steam Deck 之间应会自动同步数据。这是开发商针对 Hades 的说明,不是从 Cloud 图标推出来的,也不是本文用实际设备验证的结果。其他游戏或其他商店版本,需要查对应版本的说明。
有时,先分清账号和游戏运行方式,比先看设备名称更重要。能否使用家庭库里的游戏,属于 Steam 家庭的游戏访问条件。Remote Play Together则不是把存档搬到受邀设备、让对方独立继续玩的功能。如果连游戏实际由谁运行都不同,寻找本地存档的设备也可能找错。
出行前,可以记下常玩游戏的存档位置和官方支持页面。不必每次翻遍所有文件夹;至少能说清这次换设备玩的游戏用了哪个账号、最后在哪边保存、云同步是什么状态。很久没开的笔记本里还有旧游戏时,启动前尤其值得回想一下最后一次到底在哪台设备玩。
已经载入了不想要的记录,怎么办
发现进度不对,先别继续推进,也别把其他槽位逐个打开再保存。已经运行过,却不清楚有没有写入新文件,就把这点记下来。不同游戏的自动保存时机不同,不能保证强制退出就安全。记录当前画面和选过哪一边,再按游戏的保存机制,确认怎样保住剩余文件。
怀疑旧设备还留着文件,也别一上来就让它联网、打开游戏验证。新的同步或保存可能影响正想比较的那一份。先列出已经能够访问的副本、游戏自己生成的备份,以及此前单独保管的存档文件夹。哪些确实存在,哪些只是猜测可能有,分开记就行。

对客服能做什么,也要有准确预期。Steam Cloud FAQ 开头提醒,丢失的数据不太可能恢复;同一文档的存档丢失部分说得更明确:Steam Support 无法恢复丢失的存档,也无法协助解决云端冲突。不能指望发个工单,Steam 就能替自己找出最后一次游玩的文件并选好。Valve 的存档丢失说明
这不等于所有剩余文件都已失去恢复可能。游戏有没有额外副本、还剩哪些文件、它们属于哪个版本,会影响开发商能给出什么指导。Stardew Valley 的 _old 和菜单信息文件就是例子:只看 Steam 同步状态,看不到这些游戏内部的区别。按游戏官方文档寻找支持渠道;Hades 开发商也为使用自助步骤后仍未解决进度丢失的情况提供了联系途径,但这不是成功保证。
不知如何描述问题时,可以把几条记录串起来:游戏名与 AppID、操作系统、原先游玩的设备和后来启动的设备、最后记得的进度、警告出现的日期与时间和时区、准确提示文字,以及最终选了哪边。还没选,就写未选择;没确认上传,就写未确认。把这些写清楚,支持人员更容易知道接下来该问你哪些文件,而不用从“突然全没了”开始猜。
AppID 可以区分同名版本或续作。前面实际查询的三款游戏分别是 Portal 2:620,Stardew Valley:413150,Hades:1145360。这些是商店地址中也能看到的游戏识别号,不是个人账号编号。其他游戏出问题,别直接照抄这几个数字,先确认自己游戏的商店地址和版本。
Steam 的 cloud_log.txt 可用来参考云端文件写入和取回的记录,但它不是保存游戏进度的副本。支持人员需要日志或文件时,通过官方私密渠道提供必要范围即可。里面可能包含用户名、文件路径和账号识别信息,不要把整个账号文件夹贴到公开评论区,也没有理由提供密码或验证码。
做过安装备份,也仍要单独确认存档是否包括在内。Valve 的游戏备份说明指出,Valve 游戏的安装备份不包含存档、自定义多人地图和配置,并要求第三方游戏的文件位置向相应开发商确认。能把游戏重新装回来,和能回到原来的进度,需要不同的准备。不要只看备份工具显示完成,打开实际保管的文件夹看看里面是什么。
游戏卸载后,Steam 库存物品仍会留下,但这个说明不能直接套到存档上。库存物品和游戏进度不是同一套保存机制。整理旧游戏时,还想保留进度,就要另外确认文件位置和副本。Steam 的功能确实不容易一次弄懂,先分清眼下要保护的是什么,已经能少走一些弯路。
文中的资料核对与商店观测以 2026 年 9 月 5 日为准,没有进行恢复操作或实际账号的同步测试。如果窗口里仍是两个日期,而你还不清楚哪份包含想要的进度,今天先把最后游玩设备上的文件保留下来,就可以停在这里,不必急着按下选择按钮。
准备出售支持的 宝石袋了吗?
机器人确认收货后,USDT 会计入您的站内余额;Polygon 提现需另行申请。

