Valkey 深度拆解：当 Redis 把钥匙交出去——从异步 I/O 线程、嵌入式哈希表到 2000 节点集群的工程革命（2026）

一份写给后端工程师的 Valkey 完全指南：从 Redis 许可证地震、单线程事件循环的真相，到 8.0 的异步 I/O 重写与嵌入式哈希表、9.0 的原子槽位迁移与 2000 节点规模，配 Docker / Go / Lua / 集群 / 迁移全流程实战。

一、背景介绍：一场许可证地震，和一个开源继承者

如果你在 2024 年 3 月之后还在生产环境里跑着 Redis，那么你大概率经历过那个周末的错愕。

Redis Labs 宣布，从 Redis 7.4 起放弃沿用多年的 BSD-3-Clause，改为 RSALv2（Redis Source Available License）+ SSPLv1（Server Side Public License） 双重限制性许可。这意味着：云厂商不能把 Redis 当作托管服务直接转售，提供"软件即服务"的企业也被要求公开整段服务端代码。对一家把 Redis 当作缓存、队列、会话存储的公司来说，这不只是法务部门的事——它直接动摇了"Redis 永远免费可用"的心智。

社区的反应比任何人预想的都快。一个月后，Linux 基金会联合 AWS、Google、Oracle、Snap、Ericsson 等一众巨头，从 Redis 最后一个 BSD 版本 7.2.4 直接 fork 出了新项目，命名为 Valkey（取北欧神话里引导英灵的"女武神 Valkyrie"之意）。它坚定地采用 BSD-3-Clause，由 Linux 基金会以精英治理（meritocratic governance）模式托管，目标只有一个：保留一个社区所有、永不改许可证的真正开源内存数据库。

这就是 Valkey 的出身。但本文想讲的重点不是"开源政治"，而是工程：Valkey 不只是一个换皮的 Redis fork，它在两年之内做出了一系列独立的架构突破，单节点吞吐、内存效率、集群规模都走到了 Redis 前面。

时间线大致是这样的：

• 2024-04：Valkey 7.2.4 fork，命令级兼容 Redis 7.2.4 及更早版本。
• 2024 下半年：快速补齐社区缺失的维护，生态客户端（Valkey-Glide）启动。
• 2025 年底：Valkey 8.0 发布，异步 I/O 线程重写、嵌入式哈希表、双通道复制三大架构升级。
• 2025-12：Valkey 9.0 发布，集群支持编号数据库、原子级槽位迁移、哈希字段过期，官方宣称可扩展到 2000 个节点、每秒超 10 亿次请求。
• 2026-06：Valkey 9.1 发布，在安全性、可观测性、性能与效率上继续打磨，并且有一大批 Bug 修复是由 AI 智能体自动完成的代码回迁（backport）。

一个反直觉的事实是：很多今天你以为"只有 Redis 才有"的能力，Valkey 不仅都有，而且在协议层面完全兼容——你手里的 go-redis、redis-py、lettuce、jedis 几乎不用改一行代码就能连上 Valkey。这也是为什么文章标题说"Redis 把钥匙交出去了，Valkey 接住了"：协议这把钥匙，社区没丢。

二、核心概念：Valkey 到底是什么

2.1 一句话定义

Valkey 是一个 BSD 许可的、高性能内存键值（key-value）数据存储，既能当缓存，也能当消息队列、分布式锁、排行榜、会话存储，甚至（在 9.x 的模块生态里）当向量检索底座。它把数据放在内存里追求极致延迟，同时用 RDB / AOF 提供持久化兜底。

2.2 RESP：Valkey 的"普通话"

Valkey 与客户端之间说的是 RESP（REdis Serialization Protocol）。这是一套文本为主、二进制友好的简单协议。RESP2 是过去十年的事实标准，Valkey 同时支持更新的 RESP3。

一个最朴素的 RESP2 命令长这样（客户端发给服务端）：

SET foo bar

底层其实是：

*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n

• *3 表示这是一个包含 3 个参数的数组；
• $3 表示接下来是一个 3 字节的 bulk string；
• 然后是 SET、foo、bar。

服务端返回 +OK\r\n（简单字符串）或 $3\r\nbar\r\n（bulk string）之类的回复。

RESP3 的关键升级在于：它引入了更丰富的类型（map、set、push、double、bool、verbatim string 等），并且原生支持 push 消息（服务端可以主动给客户端推数据，比如失效通知）。这正是 Server-Assisted Client Side Caching（服务端辅助的客户端缓存）的协议基础——我们后面会在实战里演示。

2.3 单线程事件循环：为什么单线程还能这么快

这是 Valkey（继承自 Redis）最容易被误解的一点。很多人看到"单线程"就以为它性能有天花板，但真相是：

1. 命令执行是单线程的，这意味着所有读写命令按顺序在唯一的主线程里执行，天然避免了锁竞争、上下文切换和并发 bug。一条 INCR 永远原子，不需要你加任何互斥锁。
2. 网络 I/O 的瓶颈在 8.0 之前是主线程负责的（epoll 等待、读 socket、写 socket）。8.0 之后这部分被卸载到异步 I/O 线程（下一节详述）。
3. 内存访问本身纳秒级，单核 CPU 跑一个事件循环处理几万到上百万 QPS 完全可行，瓶颈往往在网络包收发和协议解析，而不是"单线程算不过来"。

所以 Valkey 的"快"，本质是：用单线程换来了无锁的正确性，再用异步 I/O 把网络收发的开销搬走。

2.4 数据模型：不止是 String

Valkey 内置的数据结构（与 Redis 7.2.4 兼容）包括：

此外通过模块（module）机制还能扩展 JSON、TimeSeries、Search、向量检索等能力——Valkey 9.x 的模块生态正在快速补齐。

2.5 与 Redis 的兼容性边界

需要诚实地划一条线：

• 协议与命令：Valkey 7.2.x 完全兼容 Redis 7.2.4 及之前；绝大多数业务代码零改动。
• 模块生态：Redis 的部分商业模块（如 RedisJSON、RediSearch 的商业版）在 Valkey 侧由社区重新实现或等价替代，迁移时要逐个核对。
• 默认行为差异：Valkey 在某些参数默认值上做了更现代的取舍（例如 appendfsync、内存策略的默认倾向），迁移前务必 diff 一遍配置文件。

三、架构分析：Valkey 在兼容之外做了什么

这是本文最硬核的部分。我们按"从内核到集群"的顺序拆开看。

3.1 事件循环：ae.c 与两类事件

Valkey 的核心是一个叫 ae（event loop）的模块。它抽象了不同平台的 I/O 多路复用：epoll（Linux）、kqueue（BSD/macOS）、evport（Solaris）。事件分两类：

• 文件事件（File Event）：socket 可读/可写时触发，对应客户端请求和回复。
• 时间事件（Time Event）：定时任务，如 serverCron（每秒若干次的后台维护：过期键清理、统计、resize 等）。

主循环伪代码逻辑：

while not shutdown:
    events = aeApiPoll(timeout)        # epoll_wait / kqueue
    for e in events:
        if e is file:   processFileEvent(e)
        if e is time:   processTimeEvent(e)
    beforeSleep()                       # 写回输出缓冲区、刷 AOF 等

beforeSleep 很关键：主线程在真正让出 CPU 之前，会把输出缓冲区里待发的回复尽量写进 socket。这也是为什么"单线程也能扛高并发"——它把"算"和"攒批回包"压紧在同一个循环里。

3.2 8.0 的异步 I/O 线程：把 epoll 搬走

在 Redis 6.0 引入的多线程 I/O 里，读 socket 仍然是主线程做，只有"把查询 buffer 解析成命令"之后的某些环节并行。Valkey 8.0 彻底重写了这一层：把 epoll_wait 这类昂贵的多路复用等待、socket 读取、协议解析前的字节搬运，全部卸载到独立的 I/O 工作线程。

关键约束没有变：命令的实际执行（读写数据结构）依旧是单线程的。这就既拿到了多核收发的带宽，又守住了无锁原子性。

用一张对比表理解：

效果是：单节点吞吐从"受限于单核网卡中断"提升到官方宣称的 百万级 QPS/节点（8.0），而命令语义完全不变。

3.3 嵌入式哈希表：每个 key 省 8 字节

这是 8.0 另一个被低估的升级。Valkey 的字典（dict）原本是经典的"哈希表 + 分离链表"：每个 entry 存一个指向 key 的指针。Valkey 8.0 引入 嵌入式哈希表（embedded hash table / keys embedded in dict entry）：把 key 直接内联进字典条目里，省掉了"指针 + 一次间接寻址 + 一次独立分配"。

在海量小 key 的场景（会话存储、设备状态、短 token），每个 key 大约省 8 字节开销，整体内存效率提升约 20%。别小看这 20%——当你有 10 亿个 key，那就是实打实的几十 GB 内存账单。

3.4 双通道复制：全量同步不再"卡顿"

主从复制时，传统做法是先传 RDB 快照，再补传期间的写命令（replication backlog）。如果快照很大、backlog 又小，容易触发反复全量同步。

Valkey 8.0 引入 双通道复制（dual channel replication）：在全量同步期间，RDB 快照流和复制积压日志流通过独立连接并行传输。从节点一边收快照，一边并行消费增量写，大幅降低了主从建立初期的延迟与抖动，也让大实例的扩容、故障切换更平稳。

3.5 集群架构：16384 个哈希槽

Valkey 集群把整个 key 空间切成 16384 个哈希槽（hash slot）。对每个 key 取 CRC16(key) % 16384 决定它属于哪个槽。槽在节点间分配，节点通过 gossip 协议互相交换集群拓扑。

客户端请求一个 key 时：

• 如果命中本节点负责的槽，直接执行；
• 否则返回 MOVED <slot> <node-ip:port> 重定向，客户端缓存拓扑后直连正确节点；
• 槽正在迁移时返回 ASK 重定向（临时跳转，不更新缓存）。

3.6 9.0 的原子级槽位迁移：不停机搬数据

集群扩容/缩容时要把槽从旧节点迁到新节点。老方案里"迁移一个槽"期间，该槽的请求可能被短暂阻塞或需要复杂的一致性保证。

Valkey 9.0 引入了原子级槽位迁移（atomic slot migration）：以更细的粒度（甚至单 key 级别）在源/目标节点间移动数据，迁移过程中槽仍可服务，避免了过去那种"迁移即抖动"的体验。官方宣称 9.0 集群可平滑扩展到 2000 个节点。

3.7 9.0 的另外两个杀手锏

• 集群模式下的编号数据库（numbered databases in cluster）：过去集群模式只支持 db0；9.0 起集群也能用 SELECT 1、SELECT 2 这种编号库，方便从单机 Redis 平滑搬过来。
• 哈希字段级过期（hash field expiration）：以前只能给整个 key 设 TTL，现在可以给 Hash 里的单个字段设置过期时间。这对"购物车里某些商品临时锁定""会话里某字段限时有效"这类场景简直是刚需，不用再自己写 Lua 维护二级过期。

3.8 9.1：可观测性、安全性，以及 AI 智能体回迁

2026 年 6 月的 9.1 把重心放在"生产可用性"上：增强的 metrics / tracing 接入、更严格的默认安全配置，以及在性能与效率上的打磨。值得玩味的是，官方披露 9.1 中有一大批 Bug 修复，是由 AI 智能体自动完成代码回迁（backport） 的——从主干把修复自动 cherry-pick 到发布分支。这其实是一个信号：大型基础设施项目的维护，正在进入"人审 + 智能体批量机械性回迁"的新范式。

四、代码实战：从单机到集群到迁移

光讲架构太虚，下面全部可运行。

4.1 单机起一个 Valkey（Docker）

# 拉取官方镜像并后台启动
docker run -d --name valkey \
  -p 6379:6379 \
  valkey/valkey:9.1

# 进命令行
docker exec -it valkey valkey-cli ping
# => PONG

# 开一个带密码的实例（生产建议）
docker run -d --name valkey-auth \
  -p 6380:6379 \
  valkey/valkey:9.1 valkey-server --requirepass '你的强密码'

4.2 valkey-cli 基础操作

valkey-cli
127.0.0.1:6379> SET session:1001 "{\"user\":\"alice\",\"role\":\"admin\"}" EX 3600
OK
127.0.0.1:6379> GET session:1001
"{\"user\":\"alice\",\"role\":\"admin\"}"

# Hash 字段级过期（9.0+）
127.0.0.1:6379> HSET cart:1001 item:42 1 item:7 3
(integer) 2
127.0.0.1:6379> HEXPIRE cart:1001 60 item:42
(integer) 1
127.0.0.1:6379> HTTL cart:1001 item:42
(integer) 60

# 排行榜（Sorted Set）
127.0.0.1:6379> ZADD leaderboard 100 alice 200 bob 150 carol
(integer) 3
127.0.0.1:6379> ZREVRANGE leaderboard 0 1 WITHSCORES
1) "bob"
2) "200"
3) "carol"
4) "150"

4.3 Go 客户端：go-redis 零改动接入

Valkey 说 RESP，所以任何 Redis 客户端都能直接连。下面用最通用的 go-redis/v9：

package main

import (
	"context"
	"fmt"
	"log"
	"time"

	"github.com/redis/go-redis/v9"
)

func main() {
	ctx := context.Background()

	rdb := redis.NewClient(&redis.Options{
		Addr:     "127.0.0.1:6379",
		Password: "", // 若开了 requirepass 则填这里
		DB:       0,
		// Valkey 9 支持 RESP3，开启后可获得 push 类型与服务端辅助客户端缓存
		Protocol: 3,
	})
	defer rdb.Close()

	// 基础读写
	if err := rdb.Set(ctx, "greeting", "hello valkey", 10*time.Minute).Err(); err != nil {
		log.Fatal(err)
	}
	v, err := rdb.Get(ctx, "greeting").Result()
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println("get:", v)

	// 用 Pipeline 把多条命令打包，减少 RTT（高并发必备）
	pipe := rdb.Pipeline()
	for i := 0; i < 1000; i++ {
		pipe.Incr(ctx, fmt.Sprintf("counter:%d", i))
	}
	if _, err := pipe.Exec(ctx); err != nil {
		log.Fatal(err)
	}
	fmt.Println("pipeline done")
}

注意 Protocol: 3 这一行——它让客户端走 RESP3，是后续用上服务端辅助客户端缓存的前提。

4.4 Lua 脚本：把"读-改-写"压成原子操作

缓存系统里最常见的坑是"check-then-act"非原子。比如限流：先 GET 计数，再决定 +1 还是拒绝——这两步之间如果有并发，计数就不可靠。用 Lua 脚本把整段逻辑放进服务端单线程执行，天然原子：

-- rate_limit.lua
-- KEYS[1] = 限流 key
-- ARGV[1] = 限额, ARGV[2] = 窗口秒数
local key   = KEYS[1]
local limit = tonumber(ARGV[1])
local ttl   = tonumber(ARGV[2])

local current = redis.call('INCR', key)
if current == 1 then
  redis.call('EXPIRE', key, ttl)
end

if current > limit then
  return 0   -- 被限流
end
return 1      -- 放行

Go 侧调用：

const script = `
local key=KEYS[1] local limit=tonumber(ARGV[1]) local ttl=tonumber(ARGV[2])
local cur=redis.call('INCR',key)
if cur==1 then redis.call('EXPIRE',key,ttl) end
if cur>limit then return 0 end
return 1
`

limiter := redis.NewScript(script)

for _, userID := range []string{"u1", "u2", "u3"} {
	res, err := limiter.Run(ctx, rdb,
		[]string{"ratelimit:" + userID}, // KEYS
		100, 60,                         // ARGV: 每分钟 100 次
	).Int64()
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("user=%s allowed=%d\n", userID, res)
}

要点：Lua 脚本在 Valkey 主线程里执行，期间不会被其他命令打断，所以 INCR + 判断 是严格原子的，不需要任何外部锁。redis.call 在 Valkey 里完全可用（协议兼容）。

4.5 搭建一个 3 主 3 从集群

准备 6 个配置文件（端口 7000-7005），每个开启集群模式：

# valkey-7000.conf
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes

依次启动 6 个实例后，用一条命令组集群：

valkey-cli --cluster create \
  127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \
  127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \
  --cluster-replicas 1

--cluster-replicas 1 表示每个主节点配 1 个从节点。完成后可以用：

valkey-cli -p 7000 cluster info        # 查看集群状态
valkey-cli -p 7000 cluster nodes       # 查看节点拓扑
valkey-cli -p 7000 cluster slots        # 查看槽分配

写入数据会自动按槽路由：

valkey-cli -c -p 7000 set user:alice '{"vip":true}'
# -> Redirected to slot [12736] located at 127.0.0.1:7002

-c 让 valkey-cli 自动跟随 MOVED 重定向。

4.6 从 Redis 零停机迁移到 Valkey

最稳的方案是"主从复制同步法"——让 Valkey 先当 Redis 的从节点，追平后再切主：

# 1) 让 Valkey 成为 Redis 的副本（临时配置，立即生效）
valkey-cli -p 6379 replicaof <redis-ip> 6379

# 2) 观察复制状态，直到 master_link_status:up 且延迟归零
valkey-cli -p 6379 info replication | grep -E "master_link_status|master_sync_in_progress"

# 3) 数据追平后，在业务低峰把客户端指向 Valkey，再解除复制关系
valkey-cli -p 6379 replicaof no one

迁移前务必：

• 确认源 Redis 版本 ≥ 5.0、目标 Valkey ≥ 7.0；
• diff 一遍 redis.conf 与 valkey.conf 的默认值差异；
• 把 repl-backlog-size 调大（如 1gb），避免大实例全量重同步；
• 灰度切流：先切只读流量验证，再切写流量。

4.7 RESP3 实战：服务端辅助的客户端缓存

传统客户端缓存的问题是"服务端数据变了，客户端不知道，缓存脏了"。RESP3 + Valkey 的 服务端辅助客户端缓存（tracking） 解决了它：客户端订阅失效通知，服务端在数据被修改时主动 push 失效消息。

opt := &redis.Options{
	Addr:     "127.0.0.1:6379",
	Protocol: 3, // 必须 RESP3
}
rdb := redis.NewClient(opt)

// 开启 tracking，让服务端在 key 失效时推送通知
if err := rdb.Do(ctx, "CLIENT", "TRACKING", "ON").Err(); err != nil {
	log.Fatal(err)
}

// 业务里正常读，本地也缓存一份
rdb.Get(ctx, "config:feature-flag")

// 当别的客户端改了 config:feature-flag，Valkey 会通过 push 消息
// 通知本连接该 key 失效，应用据此清掉本地副本 —— 脏读窗口趋近于 0

这把"缓存一致性"从"靠 TTL 兜底"升级成"服务端实时通知"，对配置中心、特性开关这类场景价值极大。

五、性能优化：把 Valkey 用对，比换引擎更重要

Valkey 本身很快，但用错方式一样能把性能糟蹋掉。按优先级给出清单：

5.1 远离慢命令

单线程执行的代价是：一条慢命令会阻塞后面所有命令。重点排查：

• KEYS *：用 SCAN 替代（游标迭代，不阻塞）；
• 大 HGETALL / SMEMBERS / LRANGE 0 -1：只取需要的字段/范围；
• 超大 String（如把整个 JSON 塞进一个 key）：拆成 Hash 字段或分片；
• 大事务 MULTI/EXEC：拆小。

# 危险
KEYS user:*

# 安全（每次返回一小批，不阻塞主线程）
SCAN 0 MATCH user:* COUNT 100

5.2 用 Pipeline / 批处理砍 RTT

网络往返（RTT）往往比命令执行本身更贵。把多条无依赖命令打包：

pipe := rdb.Pipeline()
for _, k := range keys {
	pipe.Get(ctx, k)
}
pipe.Exec(ctx) // 一次 RTT 拿下全部

5.3 控制 big key

单个 Hash / Set / List 过大，会导致删除时 STW（同步释放大对象阻塞主线程）。Valkey 提供了渐进式删除思路（如 UNLINK 代替 DEL，后台异步回收），但仍要从设计上避免：

• 大 Hash 按桶分片：user:{1001}:profile、user:{1001}:prefs；
• 大 List 用时间分片或 Stream 替代；
• 监控 redis-cli --bigkeys 定期体检。

5.4 内存优化：小对象编码与嵌入式哈希表

Valkey 对小数据会自动用紧凑编码（listpack / 嵌入式哈希表）。经验法则：

• 优先用 Hash 而不是一堆独立 String（省元数据、省嵌入式哈希表的 8 字节/key 红利）；
• 控制 value 大小，避免触发大对象分配；
• 8.0+ 的嵌入式哈希表已在底层自动生效，海量小 key 场景直接受益 ~20% 内存下降。

5.5 异步 I/O 线程调优

8.0 之后可以根据 CPU 核数调整 I/O 线程数（具体参数随版本演进，请以 9.x 文档为准），原则是：I/O 线程数 ≈ 网络收发包所需的核数，但不要超过物理核，且命令执行主线程独占一个核。压测时用 INFO stats 里的 instantaneous_ops_per_sec 和 latency 监控找拐点。

5.6 持久化权衡

• 纯缓存：可关掉 AOF、降低 RDB 频率，追求极致吞吐；
• 需持久化：用 AOF（appendfsync everysec 是吞吐与安全的平衡点），配合 RDB 做冷备；
• 主从 + 哨兵/集群：持久化开在从节点，主节点专注服务，减少主线程的 fsync 抖动。

5.7 集群分片策略

• key 设计加入 {hashtag}，让需要一起操作的一组 key 落到同一槽：order:{1001}:items、order:{1001}:meta 共享 1001 的槽，跨 key 的 MULTI 才不会跨节点报错；
• 避免"热槽"：某个 hashtag 被高频访问会打爆单节点，必要时打散。

5.8 一张基准对照（量级参考）

数字仅供参考，真实性能请用你自己的硬件跑 valkey-benchmark：
valkey-benchmark -h 127.0.0.1 -p 6379 -t set,get -n 1000000 -c 50 -P 16

六、总结与展望：Valkey 把"开源内存数据库"的钥匙留在了社区手里

回看 2024 年那场许可证地震，结论其实已经很清楚：Valkey 不是 Redis 的"替代品"那么简单，它是 Redis 开源血脉的正统继承者——从 7.2.4 的最后一版 BSD 代码 fork 而来，命令兼容、协议兼容、客户端兼容，而你得到的，是一个由 Linux 基金会托管、巨头共建、且仍在独立进化的项目。

从工程视角给一份选型建议：

• 新项目：直接选 Valkey。BSD 许可无后顾之忧，8.0/9.0 的架构升级让它又快又省内存，客户端生态零成本迁移。
• 存量 Redis（≤7.2.4）：评估迁移收益。如果是纯缓存且量大，Valkey 的嵌入式哈希表 + 异步 I/O 能直接省内存、提吞吐；用"主从复制同步法"可平滑切换。
• 存量 Redis（≥7.4，已受新许可证约束）：若业务涉及托管/ SaaS，迁移到 Valkey 是合规与成本的双重解。
• 要不要看其他 fork/竞品：Dragonfly、KeyDB、Tencent Tendis 各有亮点，但 Valkey 在"兼容性 + 社区治理 + 头部云厂商支持"三件事上目前最均衡。

展望未来，几个方向值得关注：

1. 集群能力继续下探：原子槽位迁移只是开始，2000 节点规模下的大规模再平衡、故障切换还会更顺滑。
2. 模块生态补位：JSON / Search / 向量检索等能力在 Valkey 侧由社区重写，AI 时代"内存里的向量索引"会是必争之地。
3. AI 参与维护：9.1 已经用 AI 智能体做代码回迁，后续"智能体批量 backport + 人审"可能成为大型基础设施项目的标配工作流。
4. 云原生纵深：Valkey Operator、各大云厂商的托管服务（国内腾讯云等贡献居前）会让"开箱即用的高可用集群"成为默认体验。

最后一句话送给读者：技术的价值不在于它叫什么名字，而在于它能不能在你的生产环境里，既快、又稳、还永远不被锁死。Valkey 正在把这三件事同时做到。 下次当你想 docker run redis 时，不妨换成 docker run valkey/valkey——这把钥匙，社区替你攥住了。

参考资料沿用了 Valkey 官方公告、Linux 基金会项目页及 2025-2026 年社区技术文章的公开结论；版本特性（8.0 异步 I/O、嵌入式哈希表、双通道复制，9.0 集群编号库 / 原子槽位迁移 / 哈希字段过期，9.1 AI 回迁）以官方发布为准，部署前请核对对应版本的 release notes。