为什么存档与会话连续性是云游戏最后一块地基

聊云游戏，大家张口就是延迟、码率、编解码、边缘节点。这些当然重要，但我干这行越久越确信一件事：延迟决定玩家骂不骂你，存档决定玩家还回不回来。

给你一个特别具体、我亲眼看过的场景。一个哥们儿周末在 GeForce NOW 上肝《刺客信条》，打到凌晨两点，眼看就要过那个卡了三天的据点。网一抖，会话掉了。他重新连上去，游戏从头加载——不是从存档，是从头。那一刻他不是在骂网络，他是在骂云游戏这个物种本身。第二天他把订阅退了。你不会在任何一个延迟测试报告里看到这种流失，但它每天都在发生。

存档这件事，在本地游戏里是天经地义的：一个文件躺在硬盘里，明天打开还是它。可一旦搬进云，它就从一个文件，变成了一场分布式系统的一致性难题——你的存档现在可能在某台临时虚拟机里，可能正等着往第三方云存档服务上传，可能因为反作弊绑定了一台已经销毁的机器的硬件指纹而彻底失效。

这一篇，我想把「存档、进度、会话连续性」这三件常被混为一谈的事拆开讲透。它们是递进关系：存档是数据，进度是数据随时间的样子，会话连续性是让玩家在任意设备、任意时刻都能接上那个样子的能力。搞不清这三层，你做的云游戏就永远卡在「能玩，但不敢认真玩」的阶段。而「不敢认真玩」，是云游戏商业化的死刑判决书。

第一层：存档不是文件，是「状态」——先搞清楚你把进度存在哪

很多人做云游戏适配，第一反应是「我游戏本来就有存档功能啊，云上跑不就行了」。这话对，但只对了一半。云游戏的存档问题，根本不是「有没有」，而是「存在哪、谁拥有、绑了谁」。业界大致三种模型，我做个表让你一眼看穿区别：

看清这张表你就明白了：云游戏平台大多站在第二列和第三列之间。它们本身往往不「拥有」你的存档，只是把你的存档从一个临时环境里搬来搬去。而这个「搬」，就是所有血泪的源头。

先说最阴险的一类——DRM 加密绑定。很多游戏为了防存档修改、防作弊、防破解，会把存档和账号甚至硬件指纹绑在一起。加密密钥可能掺了机器信息、MAC 地址、主板序列号。这在本地玩毫无问题。可在云游戏里，你每次连上来的可能都是一台全新的临时虚拟机，硬件指纹每次都不一样。结果就是：存档文件明明在，游戏就是不认，报个「存档损坏」或者干脆读不出来。玩家一脸懵，你后台看日志一脸懵，因为他上一个会话的机器已经被回收、被下一局《英雄联盟》的玩家覆盖了，你连复现都复现不了。

这就是云游戏存档的第一课：默认「存档能读」这件事，在云上是需要你主动保障的，不是天然成立的。Steam 的 userdata 加密、一些单机的 DRM 校验，进了云都会变成你意料之外的雷。我的建议很土但很实在——上线前，把你游戏库里所有带加密/校验的存档路径列成一张清单，逐条在「机器每天都不一样」的假设下过一遍，别等玩家替你测。

第二层：增量存档——本质是「多久拍一次照」的取舍

搞清楚了存档存在哪，下一个真问题是：多久存一次？

本地游戏存档的节奏大家很熟：检查点一分一个、手动存档随手一个、自动存档十秒一次。本地扛得住，因为写盘几乎不要钱。但云上，每一次存档都是一次「跨越机器和网络的数据投递」，你得算账。

先把「拍一次照」到底多重搞清楚。这个东西分两种粒度，差别是数量级的：

看到没，这两个东西名字都叫「存档」，量级差了三四个数量级。绝大多数初学者把这两件事混为一谈，然后就设计出了「每十秒把整块内存 dump 一次」这种把成本干到天上的方案。

真正干活的，是中间那条路：游戏自己产出的逻辑存档做高频增量，整机快照做低频兜底。增量存档的原理说人话就是——我不存「全部进度」，我只存「这次和上次之间变了什么」。你捡了把剑，就记一条「背包新增剑」，而不是把整个背包重新拍一遍。这在本地是优化，在云上是刚需，因为你要通过网络传的每一字节都要钱、要时间。

我拆个最能说明问题的案例：Xbox 的 Quick Resume。这功能你在主机上体验过就知道多爽——切出游戏去刷个视频，切回来直接在原位置，连加载画面都没有。它背后的机制不是「游戏做了个存档」，而是把整台主机的运行状态（内存加显存）原样快照到 SSD 上，多个游戏轮流存着。这是「运行时快照」这条路的极致形态。

而它在云上为什么难？因为主机上一块 SSD 又快又便宜又是私有的，随便写。到了云端，你这台虚拟机的快照要落到共享存储上、要能被另一台不同型号的 GPU 机器唤醒、还要在唤醒时把显存状态重建出来——显存不像内存那么好搬，GPU 状态和具体硬件架构强相关。所以云端做秒切，本质上是在和 GPU 虚拟化的物理边界较劲（这个我们在第 04 篇聊 MIG 和 SR-IOV 时展开过）。主机快照是「省钱省力地爽」，云端快照是「花大钱办大事，还不一定办成」。

我的工程建议：别一上来就追 Quick Resume 式的整机秒切。先把游戏自己的逻辑存档做到「高频、增量、断点必存」，让玩家丢网最多丢三秒，这已经是体验的 80 分。整机快照留给「切设备/挂起」这种低频高价值场景，且一定要有兜底——快照唤醒失败时能回退到最近的逻辑存档，而不是直接给玩家一个黑屏。

第三层：会话连续性——比断线重连更难的，是「换设备不换状态」

现在往上走一层。存档解决了「数据在不在」，会话连续性解决的是「玩家能不能无缝接上」。

先建立一个概念：会话（session）。在云游戏里，一个会话就是「一台分给你的 GPU 虚拟机 + 你这条视频流 + 你这条输入流」这一整套东西的寿命，从分配机器、加载游戏、开跑，到你下线、机器被回收。玩家的体感是「我打开就开始玩，关掉就结束」，但后台这台机器是有生命周期的。

连续性分两个难度档，很多人只做了第一档就以为大功告成：

第一档，断线重连。网络抖了一下，客户端掉线，但服务端那台机器还活着。你要做的是：把会话「保活」一小段时间，等玩家重连回来，直接接上同一个正在跑的游戏，而不是从头加载。这一档的核心参数是保活窗口——保活太久，机器和显存被白白占着烧钱；太短，玩家刚找到 WiFi 回来就发现进度没了。行业里常见的保活窗口是几十秒到几分钟，视成本容忍度而定。

第二档，跨端迁移。这才是真难。玩家在 PC 上玩到一半，出门掏出手机，想在手机上接着玩同一个进度。注意，这已经不是「重连同一个会话」了——PC 那个会话可能得关掉，手机上要新开一个会话，输入从键鼠变成了触屏（这块我们在第 17 篇输入抽象层里细说过），编码分辨率从 4K 降到 1080p，帧率可能从 120 降到 60。唯独不变的是游戏状态。

怎么让状态不变？三条技术路径，成本和效果完全不同：

看到第三行你就懂了为什么《云原神》这种方案在存档一致性上几乎「免疫」：它的账号数据全在米哈游自己的服务器上，手机、PC、网页版连的其实是同一个云端世界，客户端只是个渲染和输入终端。你在手机上打了一半，回 PC 打开，进度天然就在那。这不是它做了什么牛逼的迁移技术，而是它的架构从一开始就没把「进度」放在客户端。说句实话，任何「服务端权威」的游戏天生就站在了云游戏存档的终点线上，单机游戏想追，得从头改造架构。

这里我得抛一个金句，也是我见过无数团队翻车的地方：「重连」和「迁移」是两件事，很多团队做了重连就宣称自己支持跨端无缝，结果玩家真跨端时发现要重新加载三分钟。你试着在需求评审时把这两个词分开写，你会发现产品经理和你对「无缝」的理解可能差了半台服务器。

第四层：平台兼容性——存档的巴别塔与「State Share」式野心

最后一层，也是最容易被低估的：存档格式本身的兼容性。这问题在单平台时代不存在，一跨端就原形毕露。

你想想，一个游戏在 PC 上的存档，可能是某个加密二进制 + 一堆松散资源文件；在主机上，存档要过平台方的认证，格式、加密、目录结构全不一样；到了手机上，很多游戏干脆是另一套账号体系。玩家以为「存档」是一个东西，其实每个平台都是它自己的一尊神。这就是存档的巴别塔。

解决它只有两条正路：要么做一层存档抽象层，把所有平台的存档统一成一套中立格式，读的时候各自翻译；要么依赖平台方提供的云存档服务，让 Steam、Epic、主机方去当这个翻译官。前者是游戏厂商的活，后者是平台的活。云游戏平台夹在中间，往往既不是存档的所有者，也不控制游戏怎么存——这就是它最尴尬的地方。

讲到野心，必须请出 Google Stadia 的 State Share。这功能是我认为云游戏史上最被低估的设计之一，Stadia 关了，但它的思路值得每个做存档的人磕一个。State Share 是什么？它允许玩家把「游戏某一刻的完整状态」做成一个链接分享出去——你在《杀手》里蹲到了那个完美狙击点、穿着特定装备、目标在特定位置，你把这个瞬间打包成链接发给朋友。朋友点开，直接进入你那个瞬间、那个位置、那个世界状态，接着你的局玩。

这玩意的技术本质是什么？是把「会话状态」当成一等公民，序列化成可分享、可重建的东西。注意它比普通存档狠在哪：普通存档存的是「我的进度」，State Share 存的是「一个可被别人接手的完整现场」——位置、装备、目标 AI 状态、随机种子，全得序列化。这已经不只是存档，是「状态即内容」。设计意图极其聪明：它把云游戏的「状态在云端」这个技术特性，直接变成了社交玩法。可惜 Stadia 没活到把它发扬光大，但这个思路今天被 Xbox 的分享功能、各种「挑战链接」玩法继承了下来。

反过来看 GeForce NOW 的处境，就是一堂反面教材课。GeForce NOW 本身不存你的存档，它靠 Steam Cloud、Epic、Ubisoft Connect 这些第三方云存档来兜底。这意味着两件事：第一，任何不支持云存档的游戏，你在 GeForce NOW 上的进度就锁死在那台临时虚拟机里，会话一结束就灰飞烟灭；第二，就算游戏支持云存档，同步本身也有失败和延迟，玩家退出时如果同步没完成，下次进来就是旧进度。再加上它的会话有明确时长上限（免费档一小时、付费档数小时），到点强制断开重连——这套组合拳下来，「敢不敢在云上认真玩一个长流程单机」就成了玩家心里的一个坎。社群里的吐槽常年不断，本质都是同一句话：我不确定我的进度是不是真的属于我。

所以我常跟团队说：云游戏存档的最高境界，不是「存得住」，而是「让玩家相信它存得住」。这两者之间差着一整套反馈设计——同步状态要可见、失败要提示、有兜底、有版本。技术做到 100 分，玩家感知不到，等于 60 分。

可落地参数表：把存档与会话连续性变成一组可调的旋钮

讲了这么多机制，落到实现上，你需要一张能拿去和团队对齐的配置表。下面这些参数是我根据公开资料和实际项目经验整理的建议区间，不是标准答案，你按自己游戏的品类和成本容忍度去拧：

几个使用要点，都是我踩过的坑：

一、「自动存档间隔」和「逻辑存档粒度」别设成一样。前者是「多久触发一次」，后者是「玩家最多回退多远」。你可以在检查点之间频繁存增量，让回退粒度很细，但不必每次都发一次完整的网络投递——中间状态可以先在本地内存/边缘缓存里攒着，关键节点再统一上传。

二、保活窗口是成本与体验的核心博弈旋钮。把它当成「给玩家的信用额度」——额度太小，玩家一断网就破产；额度太大，你在为一大堆已经离开的玩家付 GPU 电费。我的经验是先按 60 秒上线，看真实掉线重连数据，再决定要不要加。

三、务必留兜底。所有「快照唤醒」「跨端迁移」的花活，都要配一条「失败就回退到最近逻辑存档」的退路。玩家能接受「回退了三秒」，接受不了「你把我三小时干没了」。

双路径：初级速览 + 进阶深入

给初级朋友的一句话版：云游戏存档的核心是「别让玩家的进度因为换设备或掉线而消失」。你要做三件事——确认你的存档在临时虚拟机上能正常读写（尤其带加密的），把自动存档做得勤一点细一点，掉线后给玩家留一小段重连时间。能做到这三件，你的云体验就已经及格了。别急着上什么整机秒切、跨端无缝，那些是加分项，不是及格项。

给想深入的同行：把「存档 / 进度 / 会话连续性」当三个独立子系统做设计，别揉成一团。存档子系统负责数据的产生、加密、版本、上传；进度子系统负责回退粒度和一致性；会话子系统负责保活、迁移、兜底。三者之间用明确的契约连接——比如「会话释放前必须触发一次全量存档并确认上传成功，否则延迟释放」。技术选型上，先问自己一个灵魂问题：我的游戏是不是服务端权威？如果是，恭喜你站在终点线上，重点做体验反馈；如果不是，那你就要在「逻辑存档接力」和「运行时快照迁移」之间做成本权衡，而我的倾向永远是先把前者做扎实，因为快照迁移的 ROI 在跨 GPU 架构面前低得感人。

争议与常见坑：这几句话，我劝你别信

坑一：「我们支持云存档，所以支持跨端。」我见过太多方案把这俩划等号。云存档只解决「数据能存到网上」，跨端还要解决「换机器能读出来」「换分辨率不崩」「换输入不懵」。前者是存储问题，后者是会话问题。你把两者混在一起讲，就等于承诺了一个你根本兑现不了的「无缝」。（喊话：下次评审，请把这两个词分开写在白板上。）

坑二：「快照等于存档。」快照是「某一刻整机状态的冷冻」，存档是「游戏认可的可恢复进度」。快照能解决「秒切回来」，但一旦跨硬件、跨版本、跨补丁，快照就可能读不了；而好的逻辑存档是向前兼容的。别拿快照当你的存档系统用，它是体验加速器，不是数据保险箱。

坑三：「保活时间越长越好。」成本会教你做人。你为每个掉线玩家白烧的每一分钟 GPU，都是真金白银的电费和显存占用。保活窗口应该是「体验和成本的最优交点」，不是「越大越贴心」。用数据说话，别用良心定价。

坑四：静默的同步失败。最致命的不是同步失败，是失败了你没告诉玩家。第三方云存档接口超时、返回了个你没想到的错误码、上传到一半会话被回收——这些都得有可见的反馈。玩家可以接受「同步中」，接受不了「以为存了其实没存」。这是我翻过的车：早期我们默认同步是可靠的，直到线上出现一批存档丢失，查了三天才发现是某个错误分支被静默吞了。从那以后我们所有同步路径都必须有状态可见。

说个反直觉的观察收个尾：存档这件事，做得越好，玩家越感觉不到它存在；做得越差，玩家越会拿它当退订理由。它是个典型的「隐形地基」——没人夸你地基打得好，但地基一塌，整栋楼都得拆。

FAQ

Q1：我做的单机游戏，云游戏平台会帮我存存档吗？
大概率不会替你「拥有」存档。平台多数是把你的存档借道第三方云存档服务（比如 Steam Cloud）搬运。所以你要自己确认：游戏是否开启了平台云存档、存档是否加密绑定了硬件、在不支持云存档的平台上玩家进度会不会丢。别把责任默认甩给平台。

Q2：会话保活多久比较合理？
行业常见是几十秒到几分钟。我建议起步 60 秒，上线后用真实掉线重连数据去调。核心逻辑是：大多数重连发生在几十秒内（手滑、切网），超过两三分钟还没回来的人，多半是真走了，为他继续烧机器不划算。

Q3：为什么云原神这类游戏看起来完全没有存档问题？
因为它是服务端权威架构——进度全在厂商服务器，客户端只是渲染终端。它没有「换设备迁移存档」这个动作，因为根本不需要迁移，大家连的是同一个云端世界。这是架构红利，不是迁移技术牛。

Q4：State Share 那种「分享状态」我能不能抄？
能，但要想清楚代价。它要求你能把「某一刻的完整游戏状态」序列化成可重建的东西——位置、装备、AI 状态、随机种子全得能打包。这对状态管理是硬要求，很多游戏的内部状态根本不是这么设计的。如果你游戏的状态足够干净，这确实是个把技术特性变社交玩法的高招。

Q5：整机快照迁移到底值不值得做？
看你的野心和预算。它是「跨端无缝」体验的天花板，但跨 GPU 架构的迁移成本极高。我的建议是先用「逻辑存档接力」把 80 分做到，把整机快照留给低频高价值场景（挂起、切设备），且永远配一条回退到逻辑存档的兜底。别为了炫技把命搭进去。