先说结论：这次升级，改的是"看不见的部分"
如果你在客户端里翻找更新日志，会看到一串技术名词——探测频率、链路建模、调度权重——这些词你未必关心。真正值得知道的是下面这几条：
这三个数字对应三件不同的事。平均延迟降幅指的是：在相同的使用场景下，用户实际感受到的往返时延比 3.0 之前平均下降了 38%。选路耗时指的是：从"当前线路变差"到"切换到新线路"，中间花掉的时间被压到 3.2 秒。而探测频率是这两件事的基础——从每 5 秒探测一次，变成每秒探测一次。
你可能注意到了，这三件事都不是"加了一条新功能"，而是"让原来那条路走得更顺"。这就是这次升级的特点：改的全是看不见的部分，但你能感觉到区别。
为什么要重写：旧引擎遇到了两个瓶颈
要讲清 3.0 的价值，得先讲讲 2.x 时代的引擎是什么样的。它是这样工作的：每隔 5 秒，对全部节点做一次链路质量探测；每次探测得到一组延迟、丢包数据；把这些数据按一定权重排序，选出当前最优的节点；用户流量始终走这个"最优节点"，直到下次探测发现更好的选择。
这套机制在大多数情况下是够用的，但遇到两种场景时，就会显得不够灵活。
瓶颈一：5 秒的"探测空窗"
两次探测之间的突发拥堵，旧引擎是"看不见"的假设某个节点在 t=0 秒时还很空，5 秒后突然涌入了一批流量开始排队。这 5 秒里，引擎根本不知道情况变了，用户流量还会继续走这条路，直到下一次探测才发现"这里已经堵了"。
对短时间的突发拥堵来说，5 秒的空窗期会带来一次"短暂的卡"——视频转一下圈，游戏里一秒钟的操作延迟——虽然不长，但很影响体验。
把探测频率提升到每秒一次，等于把这个空窗期从 5 秒缩到 1 秒。虽然不能完全消除突发拥堵带来的影响，但至少能把影响范围缩小到一个"来不及被察觉"的区间。
瓶颈二：单一的"延迟优先"策略
不是所有场景都只看延迟，但旧引擎只会看延迟旧引擎选节点时，权重最高的指标是延迟。这本身没错——延迟低通常体验好。但"延迟"和"负载"这两个指标，在很多情况下会给出矛盾的答案。比如某个节点延迟数字特别低，但它已经负载很高，实际体验未必比延迟稍高但更空闲的节点好。
旧引擎处理这个矛盾的方式比较简单：按固定权重打分。延迟占比高，负载占比低。这个策略在"延迟差异大、负载差异小"时表现好，但在两者都接近、或者负载波动剧烈时，就容易做出次优选择。
3.0 的做法是把"权重"变成动态的——不再用一个固定的打分公式，而是根据实时的全局状态、用户的场景类型、节点的历史表现，动态调整各指标的相对权重。简单说就是：不是"永远优先看延迟"，而是"看情况决定这次看什么"。
3.0 改了哪三个地方
上面说的两个瓶颈，对应着 3.0 做的三件事。下面用"前后对比"的方式讲，左边是旧引擎的做法，右边是 3.0 的做法。
探测机制
探测机制
调度策略
调度策略
故障处理
故障处理
用户能感受到什么：三件具体的事
上面这些技术变化，落到日常使用中，最明显的是下面三种感受。如果你原本就是 QuickQ 的用户，装上新版本之后应该能立刻察觉到区别。
晚高峰不再"越用越钝"
这是 3.0 最容易被感知到的改善旧引擎时代，晚上八九点的时候，很多用户会明显感觉"网络越用越钝"——刚开始还行，用着用着就慢下来了。原因是：那个时段节点负载在快速变化，而 5 秒一次的探测跟不上变化速度，流量持续走在一条"看起来还空、实际上已经排队"的线路上。
3.0 之后，探测频率提高到每秒一次，节点一变得拥挤，流量就会在 1～3 秒内切走。体感上就是：整体速度可能和以前差不多，但不会再出现"用久了就慢"的情况。对每天固定时段使用的人来说，这个改善非常明显。
切换节点不再"卡一下"
会话保持让切换过程对用户完全无感旧引擎切换节点时，需要断开当前连接、重新建立新连接。这个过程虽然只有几秒，但对正在看视频、开会、打游戏的用户来说，几秒钟的中断足以造成一次"卡一下"的体感。
3.0 引入了会话保持机制：在切换节点时，当前连接的会话状态会被完整移交到新线路上，用户侧的连接不会中断。对用户来说，切换过程是隐形的——你不会看到"正在重新连接"，也不会经历短暂的流量中断。
这个改善对实时性强的场景尤其重要。开视频会议的时候，最怕的就是突然那一下卡顿；打排位的时候，一次切换可能就意味着一次失误。现在这些都不会发生了。
自动选路更"懂你"了
常用线路会被单独建模，越用越贴合3.0 之前，所有用户共享一套调度逻辑。3.0 引入了"个性化调优"——系统会观察你常用的线路和时段，为你的账号建立一份独立的线路偏好档案。
这份档案不会用来做任何用户画像或数据分析，它的唯一作用是：让自动选路更快地找到适合你的线路。比如你每天固定用某个节点开视频会议，系统会优先为你保留这条线路的稳定性；如果你经常在不同时段访问不同区域，系统也会学习这些模式。
简单说，就是用得越久，自动选路越贴合你的使用习惯。
怎么用上 3.0：不需要任何操作
你可能会问：那我要做什么才能用上这次升级？
答案是：什么都不用做。
3.0 分为两部分——客户端侧的界面逻辑和服务端侧的调度引擎。服务端部分已经全量上线，所有账号从 9 月 25 日起就已经在 3.0 引擎上运行了，哪怕你的客户端还是旧版本，你享受的也是新引擎的调度能力。
客户端部分会在你下次打开客户端时自动提示更新。更新到 3.0.0 之后，你会看到：
- 节点列表上新增"抖动"指标的显示（之前只有延迟和负载）
- 节点切换时不再显示"重新连接中"，而是直接完成
- 智能选路的推荐理由会显示在界面上（比如"基于你的常用线路偏好"）
- 设置里新增"个性化调优"开关（默认开启，可关闭）
如果你没看到更新提示：可以前往 下载中心 手动下载 3.0.0 版本安装包。安装过程会和之前一样，不会覆盖任何本地配置，节点偏好和分流规则都会保留。
几个技术细节，感兴趣可以看看
下面这部分偏技术向，如果你只想了解用户侧的体验变化，可以跳过，直接看后面小结。
探测机制的改动
旧引擎的探测是"集中式"的——引擎统一对所有节点发起探测，得到一个全局快照。3.0 改成了"分散式"——每个客户端在日常使用中，会对自己走过的线路持续做微小探测，把结果上报给调度中心。这样做有两个好处：一是探测频率天然更高，二是探测数据来自真实使用场景，比"实验室环境"更准确。
链路的四维建模
旧引擎只看延迟和丢包两个维度。3.0 增加了"抖动"和"出口带宽余量"。前者决定了音视频场景的流畅度，后者决定了持续传输的稳定性。这两个指标在旧引擎里是"看不见"的，导致某些场景下的调度不够精准——现在补上了。
分层评估的逻辑
一个完整的连接路径，由"用户到节点"和"节点到目标"两段构成。旧引擎把这两段合在一起评分。3.0 把它们分开评估：节点层负责"用户到节点"的质量，出口层负责"节点到目标"的质量。这样即使在"用户到节点很快、但节点出口很挤"的情况下，也能做出更准确的判断。
会话保持的实现
切换节点不断流，依赖的是"会话快照 + 平滑迁移"两个机制。切换前，引擎会把当前的连接状态、加密上下文、未完成的请求做成快照；切换时，快照被同步到新节点，用户流量从旧节点平滑移送到新节点。整个过程对上层应用是不可见的。
关于这次升级，几个常见疑问
升级上线后，我们收到了几个用户问得比较多的问题，在这里统一回答一下。
小结：一次"看不见"的升级，值得你更新
3.0 不是那种"一眼就能看出改了哪里"的版本升级。它没有新增功能按钮，没有改界面布局，没有加新的节点。它做的是把整个调度系统从底层重写了一遍——让它在更短的时间内做出更准确的判断，让你在不同场景下都能得到更贴合的线路。
如果你问我一句话概括这次升级，我会说：它把 QuickQ 从"会用就行了"变成"越用越舒服"。
三个可以带走的认知
- 3.0 改的是"怎么选节点"，不是"有多少节点"。它让已有的 137 个节点发挥出更接近上限的能力。
- 三个最直观的体感变化：晚高峰不再越用越钝、切换节点不再卡一下、自动选路越来越懂你。
- 什么都不用做就能用上。服务端已全量升级，客户端更新一下就好，配置全部保留。
如果你对 3.0 的具体实现感兴趣，可以接着看 节点怎么选 和 延迟、抖动、丢包 这两篇——它们分别讲了"节点选择"和"链路质量"的更多细节，看完之后你会对这次升级的很多设计取舍有更深的理解。
