题图

本文永久链接 – https://tonybai.com/2026/07/17/go-maps-same-proposal-accepted

TL;DR

  • Go 的 map 是引用类型，但语言不允许用 == 比较两个 map 是否"同一个"，只能用 reflect.ValueOf(x).UnsafePointer() 这类笨重写法
  • 新提案在 maps 包中加入 Same(x, y) 函数，本质是一次指针比较，编译后仅一条 CMP 指令，零开销
  • 函数最初名为 Identical，但因与 types.Identical（类型系统里的"同一性"）语义冲突、容易被误解为"深度相等"，社区几轮拉锯后改名为 Same
  • 两个 nil map 会被判定为"相同"，以保持与 m == nil 语义一致；但含 NaN 键的 map 用 Same 做优化捷径时可能产生反直觉结果，官方专门写入文档警告
  • 泛型签名几经演化：从允许 K、V 类型完全独立，到收敛为共享 K/V，委员会明确否决了"过度灵活"的版本，理由是会削弱编译期类型检查、诱发误用
  • 社区顺带提议给 slices 包也加类似函数，但因为切片同时具有值语义（len/cap）与引用语义（底层数组），委员会明确将其排除在本提案之外
  • 提案已于近日正式 accepted

大家好，我是Tony Bai。

先看一个很多 Gopher 都遇到过的问题。

func union(x, y map[string]int) map[string]int {
    if x == y { // 编译错误！
        return x
    }
    // ...
}

Go 里 map 是引用类型——它本质上是指向底层哈希表的指针。两个 map 变量如果来自同一次 make(M) 调用或同一个字面量 M{...}，那么对其中一个做的任何修改，另一个都能立刻看到。这是"引用语义"最朴素的体现。

但奇怪的是，Go 语言规范偏偏不允许你用 == 去判断"这两个 map 变量是不是指向同一份数据"。

原因也很直接：map（连同 slice、func）从一开始就被设计为不可比较类型，唯一允许的比较对象是 nil。

这个限制是为了避免歧义——如果 x == y 能编译通过，有人会理解成"比较两个 map 的键值对内容是否相等"，也有人会理解成"比较两个 map 是不是同一个引用"，这两种语义完全不同，Go 选择干脆不让你用 ==，把这团混乱扼杀在语法层面。

问题是，判断"是不是同一个引用"这件事本身是有实际价值的。提案作者、Go 团队资深工程师 Alan Donovan（也是《The Go Programming Language》一书的作者）在提案里举了个典型场景：实现一个 union(x, y) 函数求两个集合的并集时，如果能提前知道 x 和 y 是同一个 map，就可以直接短路返回，省掉一次深拷贝。

在这个提案之前，很多人估计会这样写：

reflect.ValueOf(x).UnsafePointer() == reflect.ValueOf(y).UnsafePointer()

这行代码不仅丑，性能也很差——reflect 包的调用链会带来不小的开销，而这本来只需要一条机器指令就能完成的操作。更讽刺的是，这个操作其实是完全内存安全的，用户却被迫祭出 reflect 和 unsafe 这两把重型武器。

于是就有了 issue #78456这个提案。

提案核心：三行代码，一条 CMP 指令

Donovan 最初的提案非常简洁，在标准库 maps 包里加一个函数：

package maps

// Identical reports whether two maps refer to the same data structure.
func Identical[MX ~map[K]VX, MY ~map[K]VY, K comparable, VX, VY any](x MX, y MY) bool {
    type pointer = unsafe.Pointer
    return *(*pointer)(pointer(&x)) == *(*pointer)(pointer(&y))
}

函数体的原理很简单：把 map 变量的内存表示强行按指针读出来做比较。因为 map 在运行时本质上就是一个指向 hmap 结构体的指针，所以这个操作在编译后会被优化成一条 CMP 指令，几乎零开销。

虽然内部用了 unsafe，但这个函数对外暴露的是一个完全类型安全、内存安全的接口——用户不需要接触任何危险操作，标准库替你把"脏活"做了。

这个提案在设计上一开始就显得很克制：不追求功能大而全，只是把一个大家反复用 reflect+unsafe 手搓的模式，收编进标准库，变成一个安全、高效的一等公民。

然而，越是简单的提案，细节上的分歧往往越多。接下来的几个月里，这个函数在四条战线上被反复拉扯。

战线一：命名之争——“Identical” 还是 “Same”？

第一个火药味十足的问题是命名。

有社区成员第一时间就提出了担忧：Identical 这个名字太容易让人联想到"相等"（Equal），而不是"同一个引用"。他随即抛出了备选方案 IsAliased/Aliased。

紧接着 开发者rittneje 类比了标准库里已有的 os.SameFile，建议改名为 maps.Same。

这场争论最终在提案委员会的一次讨论中被正式盖章。委员会给出的理由相当精细，值得完整转述一下他们的分析逻辑：

  • “Identical” 这个词表面上暗示了编程语言里"同一性"（identity）的概念，但这种理解并不是普适的——现实语言里"identical twins"（同卵双胞胎）恰恰不是同一个个体；
  • 更要命的是，Go 自己的 go/types 包里已经有一个 types.Identical 函数，但它比较的是类型理论意义上的等价性（两个类型是否结构相同），而不是内存地址是否相同——这和新提案想表达的意思完全是两回事，两个"Identical"放在同一个语言生态里会互相打架；
  • 相比之下，“Same” 更朴素、歧义更小，也能和已有的 os.SameFile 形成命名风格上的呼应。

于是，函数正式改名为 maps.Same。这个改名过程也说明了一个事实：在标准库里加一个 API，API 的行为往往不是最难达成共识的部分，名字才是^_^。“计算机科学里真正难的只有两件事:缓存失效,以及给东西起名字” 这句话的含金量更高了！

战线二：nil 和 NaN——两个容易被忽略的语义陷阱

命名定下来后，边界语义又成了新的战场。

第一个问题：两个 nil map，算不算"Same"？

按照实现，答案是"算"——两个 nil map 在内存表示上都是零值指针，指针比较自然相等。这引发了一些社区成员的疑问：这样真的合理吗？

Donovan 的回应很干脆：map 本质上就是一种指针，Same 就是纯粹的指针比较，所以这个结果是自洽的。

更进一步，rittneje 补充了一个很有说服力的论据：Go 语言本身就允许 m == nil 这样的写法，如果 m == nil 为真，而 maps.Same(m, nil) 却给出相反结论，那才是真正让人困惑的不一致。这场讨论最后没有推翻既有实现，反而巩固了"Same 就是指针语义"这一设计原则。

第二个问题：NaN 的陷阱。

这是一个更隐蔽、也更值得开发者警惕的坑。Donovan 在后续版本的文档注释里专门加了一段警告，并给出了一个具体例子：

// Same reports whether two maps refer to the same data structure.
//
// Beware that some shortcuts based on Same(x, y) may have surprising
// behavior for maps containing floating-point NaNs, since NaN != NaN.
// For example, the early return in the union function below causes
// the result of union(s, s), where s is Set{NaN: {}}, to have only
// one element instead of two.
//
//	type Set = map[float64]struct{}
//
//	// union returns the union of two sets.
//	func union(x, y Set) Set {
//		if Same(x, y) {
//			return x
//		}
//		z := make(Set)
//		Copy(z, x)
//		Copy(z, y)
//		return z
//	}

假设 s 是 Set{NaN: {}}，调用 union(s, s) 时，因为 Same(x, y) 判断为真，函数会直接提前返回 x——这在逻辑上没问题，因为两者本来就是同一个 map。

但如果开发者错误地把 Same 当成"内容相等"的快捷替代（比如认为"Same 为真就等价于 Equal 为真，可以放心跳过逐一比较"），就可能在涉及 NaN 的场景里踩坑——因为 NaN != NaN，两个内容相同但不是同一个引用的 map，即便逐元素比较看起来"相等"，也不能simple地互相替代做优化短路，任何基于"Same 蕴含 Equal"的代数捷径在 NaN 面前都是不安全的。

这段警告的措辞本身也被反复打磨。有开发者曾建议干脆删掉举例、只留第一句警告，理由是"用浮点数当 map 键的人本来就该自求多福"；而也有开发者指出警告的第一版表述不够直观，容易让读者第一次读不出"惊喜点"在哪，并给出了更清晰的改写建议。最终文档保留了完整的警告和例子——对于一个会被写进标准库、面向所有 Gopher 的函数来说，宁可啰嗦一点，也不要留下"看起来很安全实则会让人掉坑"的表述空间。

战线三：泛型签名的三次收缩

如果说命名和边界语义是"表达层"的分歧，泛型签名的讨论则真正触及了 API 设计的核心权衡。

签名的演化经历了好几个版本：

v1（最初版本）——两个类型参数，但共享 key 类型：

func Identical[MX ~map[K]VX, MY ~map[K]VY, K comparable, VX, VY any](x MX, y MY) bool

v2——Donovan 后来简化为共享 K 和 V，理由是这样足以覆盖"调用方持有两个类型参数、但底层类型相同"的场景（比如某个函数内部 x 和 y 各自的类型是不同的类型形参，但实际实例化时是同一种 map）：

func Same[MX, MY ~map[K]V, K comparable, V any](x MX, y MY) bool

v3（有开发者提出的更激进版本）——连 key 类型都不要求一致，x 是 map[K1]V1，y 是 map[K2]V2，两者可以完全独立：

func Same[M1 ~map[K1]V1, M2 ~map[K2]V2, K1, K2 comparable, V1, V2 any](x M1, y M2) bool

v3 版本能覆盖更极端的泛型场景——比如一个通用的 SetIsEqual 函数，接受 map[K]bool 或 map[K]struct{} 作为集合实现，内部想用 Same 做个快速短路判断。

但这个更灵活的版本被委员会明确按下了暂停键。理由总结起来是三点：

  1. 类型越自由，Same 和 == 的语义距离就越远，用户心智负担越重；
  2. 一旦放开这个限制，等于砍掉了一道有用的编译期类型检查——原本"类型不匹配"会在编译期直接报错，现在则可能允许开发者不小心写出一个永远返回 false 的 Same 调用（因为类型压根对不上），而这种错误在运行时才会暴露，甚至可能悄无声息地被忽略；
  3. 更关键的是，这种灵活性的真实需求其实来自另一个尚未定案的提案（#77052），在那个提案落地之前，“是否真的需要"这种灵活性本身就缺乏足够有力的证据。

Donovan 最后也认同了这个判断，把 v3 这个更宽泛的版本正式搁置，等待 #77052 的结果再做定夺。这场讨论其实透露出 Go 团队一贯的设计取舍：API 的"能力上限"从来不是越高越好，能在类型系统里做的检查，就不应该推给运行时。

战线四：一个"合理但被拒绝"的跑题——slices 要不要也加？

讨论进行到一半，有开发者抛出了一个很自然的联想：既然 map 能加 Same，slices 包是不是也该加一个类似的函数？

有人还给出了一个看似可行的实现：

len(s) == len(s2) && &s[0] == &s2[0]

但很快 有人就指出了这段代码的漏洞：如果两个切片都是空的，&s[0] 会直接越界 panic；更麻烦的是，len 是否应该作为判断条件本身就存疑——考虑这样一个例子：

x := make([]int, 10)
slices.Identical(x, x[:5]) // 这该返回什么？

x 和 x[:5] 共享同一段底层数组的起始地址，但长度不同，它们到底算不算"相同”？这个问题没有唯一正确答案，取决于你关心的是"底层数组是否重叠"还是"长度和内容是否完全一致"。

Donovan 对此的态度非常明确：slice 的"引用相等"是一个复杂得多的问题，值得单独立项，而不是塞进这个提案里。

原因在于，slice 同时具备值语义（len、cap）和引用语义（底层数组指针），这两种语义交织在一起，会引出诸如"部分重叠算不算相同"、“空切片该怎么判断"这类子问题——slices 包内部其实已经有一个专门处理类似逻辑的私有函数 overlaps，但 Donovan 特意指出，这个函数是为特定调用场景量身定制的，内部做了一些取舍（比如刻意拒绝把"长度为零但落在另一个切片内部的切片"算作重叠），未必适合直接抽象成通用 API。

最终，slices 相关的讨论被正式排除在本提案范围外，交给未来可能出现的独立提案处理——这也是 Go 提案流程里一个很典型的自我约束：一个提案只解决一个明确的问题，哪怕相邻的问题看起来"顺手就能做”。

小结：一个三行函数背后的设计哲学

回顾整个讨论过程，maps.Same 最终拍板的版本是这样的：

// Same reports whether two maps refer to the same data structure.
//
// Beware that some shortcuts based on Same(x, y) may have surprising
// behavior for maps containing floating-point NaNs, since NaN != NaN.
// For example, the early return in the union function below causes
// the result of union(s, s), where s is Set{NaN: {}}, to have only
// one element instead of two.
//
//	type Set = map[float64]struct{}
//
//	// union returns the union of two sets.
//	func union(x, y Set) Set {
//		if Same(x, y) {
//			return x
//		}
//		z := make(Set)
//		Copy(z, x)
//		Copy(z, y)
//		return z
//	}
func Same[MX, MY ~map[K]V, K comparable, V any](x MX, y MY) bool {
	// Maps in Go are references yet the core language
	// provides no safe way to ask whether they alias.
	type pointer = unsafe.Pointer
	return *(*pointer)(pointer(&x)) == *(*pointer)(pointer(&y))
}

昨天，Go 提案审核组组长 aclements 正式宣布：讨论共识没有变化，提案 accepted。对应的实现 CL（CL 794421）已经提交，正式进入实现阶段。

一个函数体只有一行核心逻辑的提案，硬是花了几个月时间、40 多条评论，在命名、nil、NaN、泛型签名四条战线上被反复推敲。这在一些人看来或许是"小题大做"，但恰恰是这种近乎苛刻的审慎，撑起了 Go 标准库一贯的稳定性口碑——毕竟一旦某个函数、某个签名进了标准库，就意味着要向后兼容几十年。比起"先上线再迭代"，Go 团队显然更倾向于"想清楚了再落笔"。

这也是这场围绕一个"三行函数"的漫长讨论，真正值得被记录下来的地方。

参考链接

  • 提案原文：https://github.com/golang/go/issues/78456
  • 实现 CL：https://go.dev/cl/794421
  • Go 提案流程说明：https://go.dev/s/proposal-status

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。