企业官网建设流程全解析

1. 从一个被关掉的服务说起：Sunshine 到底补上了什么坑

NVIDIA 当年那套 GameStream 对很多人来说是第一次真正接触“把客厅电视当成第二块显示器”这件事。主机放在书房，客厅只有一台电视和一个手柄，游戏画面顺着网线跑到电视上，延迟低到能打动作游戏。2023 年前后 NVIDIA 宣布逐步停止对 GameStream 的维护，官方客户端从应用商店下架，服务端也从驱动包里被摘掉，一大批已经习惯这种玩法的用户突然发现自己手里的硬件还在，但“回家”的路没了。

Sunshine 就是在这条路上接棒的项目。它的定位非常明确：重新实现一套与 GameStream 协议兼容的主机端服务，让仍然活跃的 Moonlight 客户端可以继续配对、继续串流。GitHub 上四万颗星的体量不是靠情怀堆出来的，而是因为它解决的是真实存在的、且没有官方替代品的需求。你不需要换显卡，不需要买新的串流盒子，只要主机端装一个 Sunshine、客户端装一个 Moonlight，配对流程和当年几乎一模一样。

这篇文章面向的读者大致分三类。第一类是手里已经有能跑游戏的 PC，想把它变成一个“自托管云游戏服务器”的人；第二类是被“AMD 处理器到底该下哪个安装包”这类问题卡住、搜索半天没找到明确答案的人；第三类是想在自建环境里做低延迟串流、但对编码参数、网络配置一知半解的人。全文不涉及任何跨地域访问手段，讨论范围严格限定在你自己能掌控的局域网或私有网络环境里。

我个人的判断是：Sunshine 真正的价值不在于“免费”，而在于它把控制权还给了使用者。官方方案下线后你不是只能认命，协议还在、客户端还在、硬件编码器还在，缺的只是一个服务端实现，而这个实现现在由社区维护，迭代速度比当年的官方版本还快。理解这一点，后面的所有配置和调优才有意义——你不是在“破解”什么，你只是在用自己的机器跑一个开源服务。

2. 选型逻辑：为什么是 Sunshine，而不是别的方案

2.1 协议层兼容比功能堆料更重要

市面上做串流的方案不少，有商业的、有开源的、有基于浏览器推流的，但选型的第一个判断标准不是谁功能多，而是客户端兼容性。Sunshine 复用的是 GameStream 的协议族，这意味着 Moonlight 这个已经迭代多年、覆盖 Windows、macOS、Linux、Android、iOS、tvOS 甚至部分嵌入式设备的客户端生态，可以直接拿来用。你不需要给每台设备单独找客户端，也不需要担心某个平台的客户端停止维护。

这一点在实际使用中的差别非常大。我试过一些基于 WebRTC 的串流方案，主机端配置确实简单，但客户端往往只有一个浏览器页面，手柄支持、HDR、多声道音频、按键映射这些东西要么缺失，要么实现得很粗糙。而 Moonlight 的手柄处理已经打磨了很多年，Xbox 手柄、DualSense、Switch Pro 手柄的震动和陀螺仪都能透传，这是短时间堆不出来的积累。

另一个被低估的点是协议层的成熟度。GameStream 协议在延迟控制、丢包恢复、动态码率这些方面有大量工程细节，Sunshine 在复现过程中基本沿用了这套思路，而不是重新发明一套。对于使用者来说，这意味着你在网上翻到的老帖子、老经验，很多仍然适用。

2.2 自托管意味着哪些具体的好处

“自托管”这个词现在被用得很泛，落到 Sunshine 上其实是几件很具体的事。配置数据全部存在本地，配对信息、应用列表、编码参数都在你自己的机器上，没有第三方服务器参与握手；串流链路是点对点的，画面数据不经过任何中转节点；版本升级由你自己决定，不会某天早上打开发现服务端被下架了。

这三点带来的直接结果是：你的使用方式不会因为外部决策而改变。官方方案关停这件事本身就是最好的教训——当服务端不在你手里时，你的使用习惯随时可能被一纸公告打断。Sunshine 的配置文件是纯文本，你可以备份、可以版本管理、可以在多台机器之间同步，这种可控性在长期使用中价值极高。

还有一点容易被忽略：自托管方案通常有更好的硬件利用率。你可以指定用哪块显卡的哪个编码器，可以控制码率上限，可以选择 H.264、HEVC 还是 AV1。商业方案往往把这些选择权收走，给你一个“智能推荐”，但对串流这种对参数极度敏感的场景来说，能手动调才是刚需。

2.3 主流主机端方案的横向对比

下面这张表是我在几个常见方案之间做的对比，判断维度都是实际使用中会踩到的点，而不是纸面参数。

从这张表能看出来，Sunshine 的核心优势集中在编码器覆盖度和配置可控性上。前者决定了你的硬件能不能用，后者决定了你能不能用得舒服。特别是编码器这一项，直接关系到 AMD 用户能不能上车，这也是下一节要重点展开的内容。

3. AMD 平台安装包怎么选：把 CPU 和 GPU 分开看

3.1 一个被问爆的问题：AMD 处理器该装哪个包

“AMD 处理器选择哪个 Sunshine 安装包”这句话在搜索框里出现的频率非常高，但这个问题本身藏着一个常见的认知偏差：决定安装包选择的不是 CPU，而是 GPU。串流画面的编码工作是由显卡承担的，CPU 品牌在这里几乎不产生影响。你用的是锐龙还是酷睿，只要显卡是同一块，需要的安装包就是同一个。

这个偏差之所以普遍，是因为很多人习惯性地把“我的电脑是 AMD 的”当作一个整体标签。但在串流场景里，CPU 主要负责的是系统调度、游戏逻辑、音频处理这些通用任务，真正决定串流能不能跑起来、画质能到哪一档的，是显卡上的硬件编码单元。所以正确的问法应该是“我的显卡是 AMD 的，该装哪个包”。

把这个问题捋清楚之后，后面的判断就简单了。你需要确认的只有两件事：主机上的显卡是哪家的，以及你打算用哪种编码格式。

3.2 判断依据：三步确认你该用哪个包

第一步，确认主机端显卡品牌。Windows 上可以直接在任务管理器的性能标签页里看，或者在显卡驱动控制面板里确认。如果你用的是带核显的 AMD 处理器且没有独显，那么核显本身也是 AMD 的编码单元，同样按 AMD 显卡处理。

第二步，确认你想用的编码格式。AMD 显卡走的是 AMF 编码器，支持 H.264 和 HEVC，AV1 编码需要较新的架构才具备。如果你打算用 HEVC 来降低码率，需要确认显卡世代是否支持；如果只打算用 H.264，那绝大多数近几年的 AMD 显卡都能满足。

第三步，对照项目发布页选择安装包。Sunshine 的历史版本中曾经为 AMD 显卡单独提供过安装包，原因是 AMF 相关的运行库需要额外打包；而在较新的版本里，官方倾向于把各家的编码器支持合并进统一安装包，减少选择成本。所以正确做法是：先去发布页看当前版本提供了哪几个安装包，再决定下哪个，而不是照着两年前的教程去点某个固定的文件名。

提示：如果你不确定当前版本是否还需要单独的 AMD 包，可以先装标准包，启动后在 Web 配置界面里查看编码器下拉列表。如果列表里能看到 AMF 相关选项，说明当前包已经包含 AMD 支持；如果只有 NVENC 或软件编码，再换用标注了 AMD 的安装包。

3.3 三条稳妥的安装路径与验证方法

路径一，标准包直装。这是最省事的做法，适用于当前版本已经合并编码器支持的情况。装完之后进入 Web 配置界面，在编码器选项里找 AMF 字样，找到就说明可用。这个路径的好处是后续升级只需要替换同一个安装包，不用每次重新判断该下哪个。

路径二，AMD 专用包。如果标准包里确实没有 AMF 选项，就去发布页找带 AMD 标识的安装包。这类包通常会额外打包 AMF 运行库，体积会略大一些。装完之后同样进 Web 界面验证编码器列表，并且建议实际发起一次串流测试，确认画面能正常输出而不是黑屏。

路径三，源码或包管理器安装。Linux 用户走这条路的比较多，各发行版的仓库或者项目提供的安装脚本都能用。这种方式的好处是依赖关系由包管理器处理，升级也走同一套流程。代价是需要手动处理一些权限配置，比如编码设备节点的访问权限，以及在某些桌面环境下需要额外的显示捕获配置。

不管走哪条路径，验证环节都不能省。具体的验证动作是：启动服务端，打开 Web 配置页面，看编码器列表；然后在客户端发起连接，观察画面是否正常、帧率是否稳定、延迟是否在可接受范围。我在第一次配置 AMD 平台时就是跳过了验证环节，结果客户端连上了但画面全黑，排查了半天才发现是编码器选错了。

3.4 显卡世代与编码能力的对应关系

这张表用来快速判断你的显卡能支持到什么程度。具体型号的支持情况以官方文档为准，这里给出的是大致规律。

从表里能看出来，编码格式的选择本质上是码率、画质、兼容性三者之间的权衡。H.264 兼容性最好，几乎所有客户端都能解，但同码率下画质最差；HEVC 在同等画质下能把码率压掉三成左右，适合带宽紧张的场景；AV1 更省带宽，但对客户端解码能力有要求，老设备可能跑不动。

我在实际使用中的选择是：局域网千兆有线环境用 HEVC，码率给到 50 到 80 Mbps，画质和延迟都能接受；如果是无线连接或者带宽受限，会降到 H.264 配合更低的码率，牺牲一点画质换稳定。

4. 从零跑通一次串流：主机端部署全流程

4.1 环境准备与依赖检查

主机端准备工作的核心目标只有一个：让编码器能稳定工作。围绕这个目标，需要确认的东西其实不多，但每一条都不能省。

显卡驱动要更新到较新的稳定版本。这一点在 AMD 平台上尤其重要，AMF 编码器的实现依赖驱动里的运行库，驱动太旧可能出现编码器初始化失败、画面撕裂、偶发花屏这些问题。我不建议追最新的测试版驱动，选一个发布了一段时间、口碑稳定的版本就好。

系统层面的检查包括：确认没有其他程序占用编码器资源，关闭不必要的后台录制软件和直播推流工具，这些程序会和 Sunshine 抢编码器。另外检查一下电源计划，把主机设置成高性能或者平衡模式，避免处理器降频影响游戏本身的帧率。

网络方面，主机端强烈建议走有线。这不是玄学，无线链路的抖动对串流体验的影响远大于平均带宽的影响。你可以用一个很简单的测试来判断：在主机上持续 ping 客户端设备几百个包，看丢包率和延迟波动。如果波动超过几毫秒，串流时大概率会出现卡顿。

4.2 安装后必须做的四件事

装完 Sunshine 之后有四件事必须做，顺序不能乱。

第一件，设置 Web 界面的访问凭据。Sunshine 会启动一个本地 Web 服务用于配置，默认监听在本机的一个端口上。第一次访问时会要求你设置用户名和密码，这个凭据用来保护配置界面，也用于后续的客户端配对。密码建议设得复杂一点，因为如果主机在网络里可被访问，配置界面就是入口。

第二件，确认服务以正确的权限运行。Windows 上一般以当前用户身份运行即可；Linux 上要确保运行服务的用户有访问显卡设备和输入设备的权限，通常需要把用户加入对应的用户组，或者在服务配置里显式指定。权限不到位最典型的表现是编码器列表为空，或者启动后立刻退出。

第三件，配置防火墙放行。Windows 上安装程序一般会自动添加规则，但如果你的网络环境被系统识别为“公用网络”，规则可能不会生效。需要手动确认相关端口的入站规则已启用。这一条是“客户端一直显示正在连接但连不上”的最常见原因。

第四件，添加你要串流的应用。Sunshine 通过一个应用列表来管理可启动的程序，你可以手动添加游戏的可执行文件，也可以直接添加桌面会话。添加桌面会话的好处是灵活，任何程序都能通过它串流；坏处是主机上的任何操作都会同步到客户端，隐私上要自己注意。

配置文件的路径分别在：Windows 上通常在安装目录下的 config 子目录，Linux 上在用户配置目录下的 sunshine 文件夹。这个文件是纯文本，可以直接编辑，也方便备份。

4.3 编码参数怎么算：码率、帧率、编码格式

码率是串流里最容易被拍脑袋设置的参数，但它其实是可以算的。基本公式是：

码率(Mbps) = 分辨率宽 × 高 × 帧率 × 每像素比特数 ÷ 1,000,000

每像素比特数反映了压缩效率，不同编码格式和分辨率下经验值差别很大。1080p 分辨率下大致在 0.15 到 0.2，4K 分辨率下因为空间冗余更多，可以降到 0.1 到 0.12。

按这个公式算几个常见场景：1080p60 用 H.264，取 0.16 的系数，得到 1920×1080×60×0.16÷1e6，约等于 19.9 Mbps，所以 20 Mbps 是个合理起点。4K60 用 HEVC，取 0.11，得到 3840×2160×60×0.11÷1e6，约等于 54.7 Mbps，所以 50 到 60 Mbps 是合理区间。1440p60 用 HEVC 取 0.12，约等于 35.8 Mbps，给 35 到 40 Mbps 比较稳妥。

注意：这只是起点，不是终点。实际码率还要看游戏类型。快速运动的画面（赛车、射击）需要更高码率才能避免块状伪影，静态画面多的游戏可以适当降低。如果看到画面在快速转动视角时出现明显马赛克，说明码率不够。

帧率方面，建议和主机显示器的刷新率保持一致，避免不必要的帧率转换。如果你的显示器是 120Hz，客户端也支持 120Hz，那就可以直接给到 120，串流链路在局域网下支撑这个帧率没什么问题。但要注意，帧率翻倍意味着码率需求也跟着上去，4K120 的码率需求是 4K60 的两倍左右。

编码格式的选择在前一节已经说过，这里补充一个实践细节：HEVC 在部分老客户端上会出现解码延迟偏高的问题。判断方法是看客户端显示的延迟统计，如果网络延迟很低但总延迟偏高，很可能是解码端在拖后腿，这时候换回 H.264 反而更流畅。

4.4 客户端配对与首次连接

配对流程和当年用官方方案时几乎一样。客户端启动后会自动搜索局域网内的主机，找到之后点击配对，客户端会显示一个四位数的 PIN 码。回到主机的 Web 配置界面，在配对页面输入这个 PIN，配对就完成了。

如果自动搜索不到主机，可以手动添加 IP 地址。这一步失败的话，按顺序检查：主机端服务是否在运行、防火墙是否放行、两台设备是否在同一个网段、主机的网络配置文件类型是否正确。这四项排查完，绝大多数连不上的问题都能定位。

首次连接成功后，我建议先做一次基线测试：选一个负载不重的游戏，把码率设低一点（比如 15 Mbps），帧率设成 60，编码格式先用 H.264，连上去看基本画面是否正常、音频是否正常、手柄是否符合预期。这个基线跑通之后，再逐步往上调参数，每调一项就测试一次。一次性把所有参数拉到最高再去排查问题，会非常痛苦，因为你不知道是哪一项导致的。

5. 画质、延迟、稳定性：三角平衡的调优实录

5.1 编码器与延迟的真实关系

很多人以为延迟主要来自网络，实际上在局域网环境下，编码和解码才是延迟的大头。编码器从拿到画面到输出压缩码流需要时间，解码端从收到码流到还原出画面也需要时间，这两段加起来往往比网络传输时间长得多。

大致的时间分布是这样的：主机端编码 5 到 15 毫秒，取决于编码格式和硬件性能；网络传输在有线局域网下 1 到 3 毫秒；客户端解码 5 到 15 毫秒，取决于客户端芯片的解码能力；显示链路 10 到 20 毫秒，取决于电视或显示器的处理延迟。加起来大概 25 到 50 毫秒，这是比较典型的水平。

从这个分布能得出两个调优方向。一是减少编码层级，选择硬件编码器而不是软件编码，软件编码在 4K 场景下延迟会飙到几十毫秒。二是优化显示链路，如果客户端是电视，把电视切到游戏模式能砍掉十几毫秒的延迟，这个收益比调码率大得多。

还有一个容易被忽略的点：编码器的预设级别。部分编码器提供速度优先和画质优先的预设，速度优先的预设编码更快、延迟更低，但同码率下画质略差。在串流场景里，我一般会倾向速度优先，因为延迟的感知比画质的细微差异明显得多。

5.2 网络侧的几个关键开关

网络配置里有几个开关对串流体验影响很大，但经常被忽略。

第一个是有线优先原则。主机端尽量走网线，这一点前面说过。如果客户端也只能无线，那就尽量让客户端离路由器近，并使用 5GHz 频段。2.4GHz 频段在串流场景下基本不可用，带宽和稳定性都不够。

第二个是关闭路由器的节能相关功能。部分路由器有节能以太网或者空闲降速的功能，会在流量低谷时降低链路速率，等流量上来再恢复，这个恢复过程会造成卡顿。在路由器设置里关掉这些功能，串流稳定性会明显改善。

第三个是给主机设置固定的局域网地址。不管是静态地址还是地址保留，目的都是让客户端的连接目标保持稳定。用动态地址的话，主机重启后地址可能变化，客户端就需要重新搜索。

第四个是避免网络中的其他大流量任务。串流对带宽的占用是持续的，如果有其他设备在同一时间做大量下载或上传，会挤压串流的可用带宽，表现为周期性的卡顿。这个问题的解决方案要么是给串流设备做优先级标记，要么就是在串流时避开大流量任务。

5.3 主机侧的性能取舍

主机在串流时承担的是双份工作：一边跑游戏，一边编码。这两件事都会吃 GPU 资源，需要做一些取舍。

比较有效的做法是给游戏帧率设一个上限。如果游戏本身能跑到 144 帧，但客户端只显示 60 帧，那多出来的帧数只是白白消耗 GPU 资源，还可能让编码器来不及处理。把游戏帧率限制在客户端需求的水平，能明显降低 GPU 占用，编码延迟也会更稳定。

另一个做法是适当降低游戏内的画质设置。这不是为了编码器减负，而是为了给编码留出足够的 GPU 余量。如果 GPU 已经跑满，编码任务就要排队，延迟会突然升高。我一般会把 GPU 占用控制在 85% 以内，给编码留出空间。

散热也是要考虑的。持续串流时主机是长时间高负载运行，如果散热跟不上导致降频，画面会周期性卡顿。清理一下机箱灰尘、检查风扇转速，这些基础工作比调参更有效。

5.4 外设透传与手柄映射

手柄的问题主要集中在两类：连接方式和按键映射。

连接方式上，手柄接在客户端还是主机端，体验差别很大。接在客户端的话，输入信号通过串流链路传到主机，延迟取决于网络；接在主机端的话，输入是本地处理，延迟最低，但你在客厅操作手柄就得考虑无线接收器的覆盖范围。我的做法是把无线接收器插在主机上，用手柄自带的无线连接主机，这样输入延迟最低。

按键映射上，Moonlight 客户端通常自带映射界面，可以把手柄按键映射成键盘鼠标操作，这对那些不支持手柄的游戏很有用。配置时要注意的是，映射是在客户端侧完成的，主机看到的只是虚拟输入设备，如果映射不生效，先检查客户端是不是保存了配置。

震动和陀螺仪的透传需要客户端和服务端都支持。震动一般在连接建立后就能用，陀螺仪则需要在客户端设置里显式开启。如果发现震动不工作，可以尝试在客户端里切换输入模式，有时候换一种模式就能解决。

6. 常见问题排查：黑屏、花屏、连不上、音频跑丢

6.1 连不上与配对失败

这是最高频的问题，排查顺序建议固定下来，避免东试一下西试一下。

先看主机端服务是否在运行，最简单的判断方法是访问本机的配置界面，能打开就说明服务起来了。再看防火墙，这是重灾区，尤其是网络类型被识别成公用网络的时候，规则不生效。接着确认两台设备的地址段，如果主机是 192.168.1.x 而客户端是 192.168.0.x，那中间可能隔了一层路由，需要调整网络拓扑。最后检查主机是不是休眠或者睡眠了，这个属于低级错误但确实常见。

配对失败还有一种是 PIN 码输入后提示错误。这种情况多半是 PIN 码过期了，客户端重新生成一个再输就行。如果反复失败，可以试着在主机端清除已有的配对记录，重新走一遍流程。

6.2 画面类问题：黑屏、花屏、卡顿

黑屏是第二高频问题，原因通常有三类。一是编码器选错了，比如在 AMD 显卡上选了 NVENC，编码器初始化失败但服务没有报错，客户端连上就是黑的。二是 HDR 状态不匹配，主机开了 HDR 而客户端不支持，或者反过来。三是显示捕获方式的问题，Linux 上尤其容易遇到，需要根据桌面环境选择合适的捕获方式。

花屏通常和码率、网络有关。如果花屏是偶发的、伴随画面马赛克，基本可以判断是带宽不足或者丢包。降低码率、改用有线连接、检查网络中的干扰源，按这个顺序排查。如果花屏是持续性的、特定区域异常，那可能是编码器本身的 bug 或者驱动问题，换一种编码格式试试。

卡顿要区分是网络卡顿还是渲染卡顿。客户端一般会显示延迟统计，如果网络延迟稳定但画面周期性地顿一下，那是主机侧的渲染或者编码在掉帧，需要检查主机 GPU 占用和散热。如果延迟统计本身就忽高忽低，那就是网络问题。

6.3 音频与输入设备类问题

音频丢失的典型表现是客户端有画面没声音，或者声音从主机音箱出来了。这个问题的根源是音频输出设备的选择。串流需要在主机上创建一个虚拟音频设备作为输出目标，把声音送到这个设备上，编码后再传给客户端。如果主机默认输出设备是音箱，声音自然就走音箱了。

解决方法是手动把默认音频输出切换到虚拟设备，或者在 Sunshine 的配置里指定音频设备。注意有些系统会在设备切换后自动改回去，需要在声音设置里把虚拟设备设为默认。

手柄无响应或者按键错乱，一般是客户端没有正确识别设备，或者映射配置冲突。先在客户端里看设备列表能不能识别到手柄，能识别但按键不对就检查映射，不能识别就换一种连接方式试试。

6.4 常见问题速查表

这张表建议保存下来，遇到问题先对照，能省掉大量无效试错。

7. 长期维护：升级、备份和扩展玩法

7.1 版本升级与配置备份

Sunshine 的版本迭代比较频繁，但升级这件事不建议盲目跟。我的做法是：稳定运行中的版本，除非遇到明确影响使用的 bug 或者需要某个新功能，否则不主动升。串流配置涉及的变量很多，升级引入的行为变化可能让原本调好的参数失效。

如果确实要升级，先备份配置文件。配置目录下的配置文件和应用列表都要备份，最好连同配对信息一起。升级之后先验证编码器列表是否正常，再跑一次基线测试，确认没问题再恢复日常使用。

降级也要做好准备。有些版本在某些显卡上表现更好，如果升级后体验变差，回退到之前的版本是合理选择。保留上一版的安装包是个好习惯。

7.2 多主机与多客户端的管理思路

家里如果有多台能跑游戏的机器，每台都可以装一份 Sunshine，用同一个客户端去连。管理上的关键是给每台主机起一个能分辨的名字，避免在客户端列表里看到一堆相似的名字不知道点哪个。

多客户端的情况更常见，客厅电视、卧室平板、手机、笔记本都可能连过来。需要注意的是不同客户端的解码能力差别很大，手机可能只支持 H.264，电视可能支持 HEVC 但不支持 AV1。如果配置是全局的，就很难兼顾。较新版本支持针对不同客户端做差异化配置，可以用起来。

另一个实践建议是给不同的使用场景建不同的应用条目。比如一个条目直接启动游戏，另一个条目启动桌面会话。这样在客户端选择的时候一目了然，不用每次都在桌面上手动点开。

7.3 后续还能怎么玩

跑通基础串流之后，还有不少可以扩展的方向。

一是把主机做成常驻的游戏服务器。主机长期开机，配合远程唤醒，客户端随时连上就能玩。这需要对电源管理和系统休眠做一番配置，但一旦跑通，体验非常接近真正的云游戏。

二是多显示器与虚拟显示。如果主机平时接着显示器，串流时希望以另一个分辨率输出，可以配置虚拟显示设备，让串流链路使用独立的分辨率和刷新率，不受物理显示器限制。这个方案在无头运行（主机不接显示器）的场景下几乎是必需的，因为部分显卡在没有显示输出的情况下编码器无法正常工作。

三是外设扩展。除了手柄，还可以把方向盘、飞行摇杆这类设备接在客户端，通过串流链路透传到主机。这类设备的透传支持程度取决于客户端实现，需要逐个测试。

四是串流质量的量化监控。客户端通常会显示延迟、丢包、码率这些统计，定期记录这些数据，能帮你在问题出现之前发现趋势。比如延迟逐渐升高，可能是主机散热在退化，早发现早处理。

我在把主机改成常驻服务器之后最大的体会是，串流的体验瓶颈往往不在技术上，而在习惯上。参数调到一个“够用且稳定”的水平之后，就不该再频繁折腾了，把时间留给游戏本身。那些花在反复对比码率差异上的时间，远不如把网线换成六类线、把路由器换个位置来得实在。