隔三差五就有客户在微信上甩过来一句话：你们做云电脑的，这玩意儿到底能不能打游戏？问这话的人大概分两类，一类是自己想省一台高配主机的钱，另一类是公司采购，想给员工配云电脑又怕被吐槽“连个游戏都跑不动”。我作为长期在一线做云桌面交付的渠道侧人员，这两种问法背后的真实诉求完全不一样：前者关心帧率和手感，后者关心的是“别买了用不了”。云电脑能不能玩游戏这个问题，答案从来不是“能”或“不能”，而是“看你怎么配、玩什么、网怎么样”。这篇就把这件事从头到尾拆开讲，包括渲染链路、规格选型、客户端调优、现场踩过的坑，以及我作为渠道商在交付时真正会做的验收动作。看完你至少能自己判断：手里这台云电脑，适合跑什么、不适合跑什么，卡的时候该往哪个方向查。
1. 云电脑跑游戏的真实链路：你的按键要经过四次跳转
很多人对云电脑玩游戏的想象是“远程桌面开个窗口点点鼠标”，所以第一反应是“那不得卡死”。这个理解偏差挺大——真正决定体验的不是“远程”这两个字，而是整条链路上每一跳花掉多少毫秒。把这个账算清楚，你就能预判自己能不能接受，而不是靠玄学感觉。
1.1 渲染发生在机房，你手上这台机器只干两件事
云电脑的架构你可以理解成“把主机搬到了隔壁楼的机房”。你在本地客户端按下 W 键，这个事件被打包成很小的网络包发出去，机房里那台虚拟机收到指令，由它的 CPU 和 GPU 完成游戏逻辑运算和画面渲染，渲染出来的画面经过硬件编码器压成视频流，再推回你的本地客户端，客户端用显卡或核显做解码，最后显示在屏幕上。整个过程中，你本地这台设备基本不参与任何图形运算，它只干两件事：采集输入和解码视频。
这个特性带来两个直接后果。第一，本地设备的下限被拉得很低，一台五年前的轻薄本、甚至一台平板，只要解码能力够、网络够稳，就能“玩”到机房那张显卡的算力。第二，本地设备的显卡好坏对游戏帧数几乎没有影响，但对解码延迟和画面质量影响很大——支持硬件解码（比如常见的 H.264/H.265 硬解单元）的设备，解码耗时能压到个位数毫秒，而纯软件解码可能单帧就要十几毫秒，还带CPU占用飙升。所以经常出现“同样的云电脑，A 的笔记本很顺，B 的老机器明显拖影”这种情况，问题不在云端，在本地解码。
再往下拆一层，云端那台虚拟机的显卡并不是“整张卡给你”。图形型实例通常是 GPU 直通或者 vGPU 切分，直通性能好但成本高、规格死，切分灵活但存在显存争抢。同一台物理机上如果同时跑了多个图形实例，邻居在跑满载渲染的时候，你这边可能出现瞬时掉帧——这是我在现场遇到过好几次的“莫名其妙卡一下”，最后定位到是同一宿主上的资源竞争，换规格或者错峰就好了。
1.2 延迟预算：一帧画面到底要走多少毫秒
要判断“卡不卡”，最实用的办法是列一张延迟预算表，把每一段的耗时估出来加总。人眼对“操作到画面反馈”的容忍度，一般认为在 60~100 毫秒之间开始有明显感知，超过 150 毫秒基本就是“手感发飘”。下面这张表是我在做方案时常用的估算口径，数值是常见区间，具体以实测为准。
| 环节 | 典型耗时 | 说明 |
|---|---|---|
| 本地输入采集与打包 | 1~5 ms | 键鼠/手柄的轮询率越高越短 |
| 上行网络传输 | 3~15 ms | 同城同运营商可压到个位数 |
| 云端游戏逻辑与渲染帧时间 | 8~17 ms | 60fps 每帧 16.7ms，120fps 每帧 8.3ms |
| 画面编码 | 5~15 ms | 硬编码器快，软编码慢且吃CPU |
| 下行网络传输 | 3~15 ms | 码率越高越吃带宽 |
| 本地解码 | 3~10 ms | 硬解 3~5ms，软解可能 10ms 以上 |
| 显示刷新等待 | 8~16 ms | 60Hz 屏平均多等半帧 |
把中位数加一遍，端到端大约在 45~80 毫秒这个量级。这还只是“你的操作回到你眼睛”的时间，如果玩的是联网对战，还要再叠加云电脑到游戏服务器的那一跳 RTT。这就是为什么单机、回合制、挂机类游戏在云电脑上几乎无感，而竞技类射击游戏会明显“跟不上手”——后者本来就靠几十毫秒的优势分胜负，你再叠一层上去，体验断层就很明显了。
提示：做延迟评估时不要只看 ping 值。ping 测的是 ICMP 往返，和实际的视频流 UDP 传输路径不一定完全一致，但它依然是最快能拿到的参考值。真正要看的是客户端自带的连接质量面板里的“往返时延”和“丢包率”。
1.3 什么类型的游戏适合搬上云，什么坚决别碰
我一般给客户按“对延迟的敏感度”分三档来建议，比笼统地说“能玩/不能玩”有用得多。
| 游戏类型 | 适配度 | 主要原因 |
|---|---|---|
| 回合制、卡牌、策略、模拟经营 | 高 | 对帧率和延迟几乎无感，长时间挂机也稳 |
| MMORPG 日常、挂机、副本 | 较高 | 操作不是毫秒级判定，画质优先 |
| 单机大作（剧情向） | 较高 | 高画质需求正好由云端 GPU 满足 |
| 沙盒、建造、模拟类 | 高 | 长时间运行，正好符合云电脑“不关机”的特性 |
| MOBA、非竞技射击 | 中 | 有感知但可接受，看网络质量 |
| 竞技类 FPS、格斗、音游 | 低 | 毫秒级判定，叠加延迟后手感明显变差 |
| 需要特定反作弊环境的网游 | 需先确认 | 部分游戏对虚拟化环境有限制，需提前核实规则 |
这里必须单独强调最后一行。很多游戏的用户协议里对运行环境有明确约定，虚拟化、远程环境是否被允许，各家规则不一样。我的做法是让客户自己去游戏的官方规则页确认，渠道商不替客户做这个判断，也不提供任何“绕过限制”的方案。这一条我在每次售前沟通时都会明确讲一遍，属于必须提前说清楚的风险项，事后扯皮最麻烦。
2. 规格怎么挑：图形型实例的选型逻辑与成本账
渠道商最容易犯的错，就是客户说“我要玩游戏”，直接甩一个最贵的图形型规格过去。这既不明智也不专业——客户可能只是想挂个模拟经营，你给他配一张专业级显卡，钱花了体验没差别，续费的时候第一个骂你。
2.1 显卡、vCPU、内存的配比不是越高越好
云电脑的规格是一个整体，任何一项短板都会成为瓶颈。我用一个生活化的比喻：显卡是厨房里的灶台，vCPU 是切菜的师傅，内存是操作台面。灶台再猛，只有一个师傅切菜、台面还小得放不下盘子，出菜速度照样上不去。
具体到游戏场景，要看游戏本身的负载倾向：
- GPU 密集型（3A 单机、高画质网游）：显卡是主要瓶颈，vCPU 配到 4~8 核、内存 16GB 起步就够，把钱花在显卡上。
- CPU 密集型（模拟经营、大型策略、部分沙盒）：这类游戏后期单位数量爆炸，吃的是单核性能和内存容量，显卡反而次要，这时候选高主频 vCPU + 大内存比堆显卡划算。
- 内存敏感型（多开、长期挂机、浏览器多标签）：内存不足会触发大量磁盘交换，表现就是“隔一会儿卡一下”，非常典型。挂机场景建议 16GB 起，多开按每个实例 4~6GB 估算。
还有一个经常被忽略的点是系统盘和存储。云电脑的系统盘默认往往是高效云盘或者 ESSD 入门档，游戏本体动辄几十上百 GB，加载时间全压在磁盘 IO 上。我在一个模拟项目里做过对比：同一个游戏装在高效云盘和 ESSD 上，场景切换的加载时间差了将近一半。这不是玄学，是随机读写 IOPS 的差距。所以给游戏用途配云电脑，系统盘至少选到 ESSD 级别，容量按“游戏本体 + 更新预留 + 20% 余量”来算，别卡着装。
2.2 包月、按量、时长包：三种计费方式的适用边界
这块是渠道商真正能创造价值的地方，因为客户往往只看单价，不看使用模式。云电脑的计费大致分三类：包年包月、按量付费、以及各种时长包/闲时包。它们的差别不在价格数字，而在“你是否能忍受关机后资源被释放”。
| 计费方式 | 适合场景 | 关键特点 | 注意事项 |
|---|---|---|---|
| 包年包月 | 每天固定使用、长期挂机 | 单价最低，资源独占 | 中途降配麻烦，需提前规划 |
| 按量付费 | 临时试用、项目制、周末集中玩 | 用多少算多少 | 忘记关机是最大成本陷阱 |
| 时长包/闲时包 | 每天只用两三小时、主要在晚间 | 单价介于两者之间 | 有可用时段限制，要看清楚 |
我见过最典型的翻车案例：某客户为了“随时能玩”选了按量付费，结果客户端没退出、实例一直在线，一个月账单出来的时候人傻了。后来给他改成包月 + 定时关机策略，成本直接降下来一截。这件事的经验是：按量付费必须配自动化关机策略，比如设置每晚某个时间无会话自动关机，第二天用的时候再唤醒。唤醒通常需要一两分钟，这个等待要提前跟客户讲明白，别让人以为坏了。
成本测算我一般用“月度总拥有成本”来跟客户对话，而不是单看每小时单价。把云电脑月费、客户端侧不需要升级硬件的节省、电费、以及本地主机折旧放在一起比，客户才会有直观感受。一台能跑 3A 的本地主机，硬件投入加上三五年折旧和电费，和一个中档图形型云电脑的月费放在一起，其实差得没有想象中那么大——云电脑贵在持续支出，本地贵在一次性投入和后续升级。这个账要实事求是地算，别为了成单硬吹。
2.3 一张可以直接拿去用的选型对照表
下面这张表是我在给客户做初步方案时的默认起点，实际还要结合具体游戏和预算微调。
| 使用场景 | vCPU | 内存 | 显卡档位 | 系统盘 | 备注 |
|---|---|---|---|---|---|
| 挂机、卡牌、页游 | 2~4 核 | 8 GB | 入门图形或集成 | 高效云盘 100GB | 成本优先 |
| 主流网游中画质 | 4~8 核 | 16 GB | 中档图形 | ESSD 200GB | 平衡档，最常推荐 |
| 3A 单机高画质 | 8 核 | 16~32 GB | 高档图形 | ESSD 300GB+ | 显存是关键 |
| 多开挂机（3~5 开） | 8 核 | 32 GB | 中档图形 | ESSD 300GB | 内存按实例叠加 |
| 直播 + 游戏同机 | 8~16 核 | 32 GB | 高档图形 | ESSD 500GB | 编码占额外算力 |
注意：表里的“档位”是相对说法，实际采购时要看具体实例族的显卡型号、显存大小和是否直通。同样是“图形型”，显存 8GB 和 16GB 在高画质下差距非常明显，这一项一定要在报价单上确认清楚。
3. 客户端侧调优：把画质和延迟捏到平衡点
云端配好了只是及格线，真正决定手感的是客户端这一侧的参数。我发现很多客户的“卡”，其实是客户端设置和网络环境没对齐，跟云端算力一点关系都没有。这一节讲的东西，是交付时我一定会现场调的。
3.1 编码协议、码率、分辨率的三角关系
这三个参数互相牵制，不可能同时拉满。理解它们的取舍，比记住某个“最佳配置”有用得多。
- 分辨率决定画面清晰度的上限。客户端窗口分辨率和云端桌面分辨率不一致时，会出现缩放，缩放是要额外算力的，还会让文字发虚。所以第一条铁律：让两端分辨率对齐，或者用整数倍缩放。1920×1080 的客户端窗口，云端就设 1920×1080，别搞什么 1600×900 拉伸。
- 码率决定单位时间内传多少画面数据。码率低，快速运动的画面就会出现明显的块状模糊；码率高，带宽压力大。一般 1080p60 的办公场景 8~15 Mbps 够用，游戏场景建议 20~30 Mbps 起步，动作激烈的话往上加。
- 编码协议决定压缩效率和解码开销。H.265 同画质下比 H.264 省 30%~50% 带宽，但对本地解码能力要求更高，老设备可能解不动反而更卡。我的默认策略是：本地设备五年内的用 H.265，老设备退回 H.264，宁可多花带宽也别让解码成为瓶颈。
一个常见的误解是“码率调越高越清晰”。实际上如果网络本身丢包严重，高码率反而会让卡顿更明显，因为每一帧携带的数据更多，丢一包影响的面更大。丢包率高的时候，正确做法是降码率、降帧率，先把流畅度保住，再谈清晰度。
3.2 网络自检：几条命令和判定标准
我不喜欢凭感觉判断网络好坏，现场一般会跑几条命令拿数据。Windows 上：
# 连续 100 次探测，看平均延迟、最大延迟和丢包 ping -n 100 <云端接入地址> # 看路径上每一跳的延迟，定位是哪一段慢 pathping <云端接入地址> # 检查到目标端口的连通性和握手时间 Test-NetConnection <接入地址> -Port 443 -InformationLevel DetailedLinux 或 macOS 上对应的是：
# 100 次探测并统计 ping -c 100 <接入地址> # 逐跳延迟与丢包，比 tracert 信息更全 mtr -r -c 100 <接入地址> # 带宽打流测试，验证实际可用上行/下行 iperf3 -c <测试服务端> -t 30 -P 4判定标准我一般这么划：
| 指标 | 良好 | 可用 | 需要处理 |
|---|---|---|---|
| 平均往返时延 | < 20 ms | 20~50 ms | > 50 ms |
| 最大时延抖动 | < 10 ms | 10~30 ms | > 30 ms |
| 丢包率 | < 0.1% | 0.1%~1% | > 1% |
| 可用下行带宽 | > 码率 × 1.5 | 码率 × 1.2 | < 码率 × 1.2 |
抖动这一项比平均延迟更值得看。平均 20ms 但抖动 60ms 的线路，玩起来是“一顿一顿”的，反而不如稳定 40ms 的线路。这也是为什么有些客户说“我测速很快啊怎么还卡”——测速测的是峰值带宽，抖动和丢包它不告诉你。
3.3 外设接入：手柄、键鼠、USB 重定向
外设这块是体验落差最大的地方，很多人云端配了顶配，结果用蓝牙手柄连本地，手感稀烂。原因在于外设事件的传输路径不同：
- 本地键鼠：客户端直接采集，延迟最低，是最推荐的方案。但要注意客户端是否把按键做成了“快捷键拦截”，比如某些组合键被本地系统吃掉，传不到云端。这类问题要在客户端设置里把快捷键映射关掉或改掉。
- 手柄：分两种接法。接在本地、由客户端转发，延迟取决于转发实现，通常可用；接在云端（通过 USB 重定向），延迟取决于重定向通道质量，抖动可能更大。我的经验是优先本地接、客户端转发，兼容性问题少。
- USB 重定向：U 盘、加密狗、特定外设需要走这条路。重定向对网络质量比画面流更敏感，丢包时会直接表现为“设备掉线重连”。游戏场景里除非必要，不建议开大量 USB 重定向。
- 音频：音频也是走独立通道的，如果出现“画面不卡但声音断续”，先查音频重定向设置，别去怪显卡。
还有一个细节：多显示器。云电脑支持多屏的时候，是云端虚拟出多个显示输出再分别编码推流，带宽和编码开销是翻倍的。客户如果只是“想把游戏放副屏”，完全没必要开多显示器，直接把客户端窗口拖到副屏、全屏化就行。
4. 上线前的实战验证：我在现场踩过的六个坑
这一节是全文最“不好看但最有用”的部分。规格选对了、参数调好了，依然会有各种意外。下面这些坑都是我在真实交付里撞过的，写出来是为了让你少走一遍。
4.1 “能开机不能开游戏”：驱动和运行库的缺失
图形型实例刚创建出来，系统里装的往往是通用显卡驱动，甚至是微软自带的兼容驱动。表现就是桌面能进、网页能开，一启动游戏就报“找不到图形设备”或者直接闪退。
根因很简单：虚拟化环境下的 GPU 需要匹配的驱动版本，通用驱动认不出这张“虚拟显卡”的完整能力。处理路径是：先确认实例规格对应的 GPU 型号，再装厂商提供的对应驱动包，装完重启，然后在设备管理器里确认没有黄色感叹号，最后跑一个图形压力测试确认渲染正常。
顺带一个高频问题：运行库缺失。很多游戏依赖特定版本的 DirectX 运行库和 C++ 运行库，纯净系统里没有。我在一个模拟项目里遇到过游戏启动黑屏，查了半天是缺一个 2015-2022 的运行库合集，装完立刻正常。所以交付清单里我现在固定加一条：预装常用运行库合集。
4.2 登录环境与账号规则：先问清楚，别替客户拍板
这一条我放在很前面强调，因为它是唯一可能造成“不可逆损失”的坑。部分游戏对登录环境变化敏感，突然换设备、换地区登录会触发安全验证甚至临时限制。云电脑的出口 IP 和客户常用地不一定一致，第一次登录时很可能弹验证。
我的处理方式很明确：提前告知，让客户自己决定并在官方规则允许的范围内操作。具体做法包括建议客户先在游戏官方渠道确认虚拟化环境的可用性，首次登录时准备好验证手段，不要在重要活动期间切换环境。渠道商在这里的角色是提示风险，不是承诺“肯定没问题”。任何涉及规避平台规则的操作，我一律不做，也不建议客户做——账号是客户自己的资产，出问题没人替他兜。
4.3 音频、剪贴板、多屏：最容易被追问的“小功能”
大功能都通了之后，客户最先抱怨的往往是小功能。剪贴板不通，复制个游戏攻略都费劲；音频不出声，以为是显卡坏了；副屏拖不过去，觉得“这云电脑是不是残废”。
这些都属于客户端策略配置问题，改起来很快，但如果不提前配好，验收当天会非常难看。我现在交付前会固定过一遍清单：
| 功能 | 检查动作 | 常见问题 |
|---|---|---|
| 剪贴板 | 双向复制一段文字 | 策略默认只允许单向 |
| 音频 | 播放一段音频，检查输入输出设备 | 默认音频设备选错 |
| 文件传输 | 拖拽一个小文件 | 通道未开启或大小超限 |
| 多屏 | 拖动窗口到副屏 | 云端未配置多显示输出 |
| 打印 | 打印到本地打印机 | 重定向未启用 |
| 快捷键 | 试 Alt+Tab、Win 键 | 被本地系统拦截 |
这张表看着琐碎，但它是“客户觉得好不好用”的真正分水岭。技术上都通了，就差复制粘贴不能用，客户的主观评价会直接掉一个档。
5. 排查手册：画面糊、卡顿、掉线三类的定位路径
客户报“卡”，其实是三种完全不同的故障被同一个字概括了。我现在的习惯是先反问一句“是画面不清楚，还是操作有延迟，还是直接断线了”，把问题分类之后再动手，效率能高一倍。
5.1 画面糊：先分辨是编码损失还是分辨率没对齐
画面糊分两种，处理路径完全不同。
第一种是静态就糊，看文字边缘发虚、图标不锐利。这基本是分辨率没对齐或者缩放导致的，去客户端把显示分辨率和云端桌面分辨率设成一致，关掉系统的显示缩放（或者设成 100%），问题立刻消失。这个坑在 4K 屏笔记本上特别常见——本地是 3840×2160，云端给的是 1920×1080，客户端做了一次缩放，字就虚了。
第二种是静态清楚、一动就糊。这是编码码率不够的典型表现：画面静止时编码器可以用很低的码率保持清晰，一旦大范围运动，块状压缩痕迹就出来了。处理办法是提码率、换更高效的编码协议，或者在客户端把“动态画质优先/流畅优先”的档位调一下。如果带宽实在上不去，退一步降分辨率保帧率，比硬撑高分辨率糊成一片要好。
还有一种容易被误判的情况：远端本身画质设置就低。客户在游戏里把画质拉到最低求帧数，然后抱怨云电脑“画面像马赛克”。这种要先确认游戏内的画质设置，别一上来就怀疑链路。
5.2 卡顿掉帧：区分网络抖动和实例负载
卡顿的定位我一般按这个顺序走，从外到内：
- 看客户端连接质量面板。往返时延、丢包率、抖动三项，如果抖动大或者有丢包，问题在网络侧，先解决网络。
- 看云端实例的资源监控。CPU 是否长期跑满、GPU 利用率、显存占用、内存是否触顶。如果 GPU 利用率 100% 且帧时间超标，那是规格不够，得升配。
- 看磁盘 IO。加载场景卡、进副本卡，多半是磁盘随机读跟不上，换 ESSD 或者把游戏装到更高性能的盘上。
- 看是否有邻居干扰。同一宿主上的资源竞争会表现为“规律性的周期性掉帧”，这种最难查，一般靠换实例或者错峰规避。
这里分享一个实战技巧：让客户记录卡顿发生的时间点和持续时长。如果卡顿是集中在晚上八点到十一点，那大概率是本地宽带拥塞或者运营商线路高峰；如果是随机分布、每次几秒钟，更像云端的资源竞争或者自动更新在跑。有了这个信息，排查范围能直接缩小一半。
5.3 掉线重连：会话超时和心跳参数
掉线是另一类问题，往往和网络质量关系不大，而是会话策略。云电脑的会话有超时机制：客户端长时间无操作、网络短暂中断超过阈值，会话就可能被断开。
我遇到过的情况是客户切出去回了个消息，回来发现云电脑断开了、游戏也掉了。查下来是会话保持的超时设置偏短。处理方式是在策略里把“无操作断连时间”调长，同时确认客户端的自动重连是开启的。另外，云电脑一般支持会话保持，短暂断网后重连能回到原来的桌面状态，但正在运行的游戏是否还在，取决于游戏本身是否会因为连接中断而退出——这一点要提前跟客户说明，别让人以为重连就万事大吉。
6. 渠道商交付视角：把这件事讲清楚比卖出去更重要
最后聊聊我作为渠道侧的一点体会。这类需求最大的风险不是技术做不出来，而是预期没对齐。客户脑子里想的是“和本地高配主机一模一样”，而你交付的是“在特定条件下体验不错的远程方案”，中间的落差如果不提前说清楚，验收当天一定吵。
6.1 售前问诊：五个必须问清的问题
现在我接这类咨询，固定先问五个问题，问完基本能判断这单能不能做、该报什么规格：
- 主要玩什么游戏？决定显卡档位和延迟容忍度，也决定是否需要提前确认游戏规则。
- 每天玩多久、什么时段？决定计费方式，晚间集中玩和全天挂机是两个方案。
- 本地网络是什么情况？有线还是无线、带宽多少、是否和别人共享。无线这一项要特别问，5GHz 和 2.4GHz 差别巨大。
- 本地设备是什么？决定解码能力上限，进而决定编码协议和分辨率上限。
- 预算的心理预期是多少？决定是走性价比路线还是性能路线，也避免报了价才发现谈不拢。
这五个问题问完，方案的骨架就出来了。跳过问诊直接报价的，后面返工概率极高。
6.2 交付清单与验收标准
我现在交付云电脑，会附一张验收清单让客户逐项签字确认，把“什么算交付完成”量化下来。清单大致包括：
- 分辨率与缩放已对齐，静态画面文字清晰无发虚
- 键鼠、手柄输入正常，无按键被本地拦截
- 音频输出输入正常，无断续
- 剪贴板双向可用，文件拖拽可用
- 目标游戏能正常启动、能登录、能进入游戏场景
- 连续运行 30 分钟，帧率稳定，无异常掉线
- 客户端连接质量面板各项指标在可用区间内
这张清单最大的价值不是流程感，而是把“卡不卡”这种主观描述变成可核对的项。客户签完字，后续再有争议，对着清单一条条看，沟通成本低很多。
6.3 续费与扩容：别只看首单
云电脑是持续性支出，首单成不成交往往不是关键，关键是三个月后客户续不续。我的经验是，续费率和“第一次使用的头三天体验”高度相关。头三天顺，后面基本稳；头三天卡一次，客户心里就埋了根刺，后面怎么解释都没用。
所以我会在交付后的第一周主动回访一次，问三个问题：还卡不卡、有没有哪个功能不好用、账单有没有超出预期。第三个问题最容易被忽略，但它是隐形杀手——客户觉得贵不一定会说，只会在到期时默默不续。提前把账单构成讲清楚，告诉他哪些操作会产生额外费用（比如忘记关机、临时升配、流量超出），比事后解释有用得多。
扩容这块也有个经验：图形型实例的热迁移和变配限制比通用型多，客户如果要升配，最好在业务低峰期操作，并且提前确认数据是否需要备份。我在一个模拟项目里遇到过变配后本地缓存失效、需要重新登录的情况，虽然数据没丢，但客户体验很差。这种事提前说一句“可能会断开一次，重新连上就好”，感受完全不同。
说到底，云电脑玩游戏这件事，技术上早就没有“能不能”的问题了，难的是把适用边界讲清楚、把参数调到位、把预期管住。我个人的体会是，凡是客户问“能不能玩某某游戏”，最好的回答不是拍胸脯，而是让他把游戏名、网络环境、本地设备三样东西发过来，你按上面的思路算一遍延迟预算、对一遍选型表，然后给一个带条件的答案——比如“这个游戏可以，1080p 中画质，网络用有线，别指望竞技手感”。这种回答不讨喜，但客户用一周之后会回头找你，因为他发现你说的都是真的。
