Go 语言不可变类型提案复活：一场关于简洁性与安全性的博弈

引言：沉睡 8 年的提案为何被唤醒？

2026 年 2 月，Go 语言规范团队的一次例行会议纪要在社区引发轩然大波——Issue #27975，这个关于引入不可变类型（Immutable Types）的提案，在沉寂 8 年后重新回到了讨论桌前。

这个提案最初提交于 2018 年，那是"Towards Go 2"口号喊得最响亮的年代。当时社区正沉浸在对泛型、错误处理和不可变性的热烈讨论中。然而，随着泛型在 Go 1.18 落地，关于不可变性的声音似乎逐渐微弱。甚至在 2025 年 9 月的 GopherCon Europe 座谈会上，Go 团队还明确表示对不可变类型"我们放弃了"。

为何短短数月后，这个"已被放弃"的提案又重获新生？

本文将深入分析这一提案的核心内容、技术挑战、社区分歧，以及它背后反映的 Go 语言设计哲学的深层矛盾。

一、问题背景：防御性拷贝的代价

在深入提案之前，我们需要理解它试图解决的核心问题。

1.1 现实中的痛点

假设你有一个包含敏感配置的结构体，想把它暴露给其他包，但又不希望它被修改：

type Config struct {
    Servers []string
    // ...
}

// 现在的做法：为了安全，必须返回拷贝
func (c *Config) GetServers() []string {
    out := make([]string, len(c.Servers))
    copy(out, c.Servers)
    return out
}

这种"防御性拷贝"带来了两个严重问题：

正如提案作者 romshark 所言："我们现在的做法，要么是不安全的（直接返回指针），要么是低效的（防御性拷贝）。"

1.2 不可变性的价值

不可变类型（Immutable Types）的引入，旨在提供第三种选择：既安全，又高效。

理想中的代码：

// 定义一个只读的切片类型
func ProcessData(data immut []byte) {
    // 读取是 OK 的
    fmt.Println(data[0]) 
    
    // 修改是编译错误的！
    // data[0] = 'X' // Compile Error: cannot assign to immutable type
}

二、提案核心：immut 限定符的设计

2.1 核心思想

NO.27975 提案的核心非常直接：引入一个新的类型限定符 immut（最初建议重载 const，后倾向于引入新关键字），让编译器强制执行"只读"契约。

2.2 五大基本规则

根据提案的设计文档，不可变类型基于以下 5 条规则：

1. 每个类型都有对应的不可变版本
2. 对不可变类型的对象进行赋值是非法的
3. 在不可变类型的对象上调用可变方法（具有可变接收者类型的方法）是非法的
4. 可变类型可以转换为其不可变对应类型，反之则不行
5. 不可变接口方法必须由具有不可变接收者类型的方法实现

2.3 应用场景

不可变类型可用于：

• 不可变字段
• 不可变方法
• 不可变参数
• 不可变返回值
• 不可变变量
• 不可变接口
• 不可变引用类型和容器
• 不可变包级变量

三、技术挑战：理想与现实的碰撞

这个提案下的讨论区，堪称 Go 语言设计哲学的"修罗场"。Ian Lance Taylor、Rob Pike 等核心大佬纷纷下场，与社区开发者展开了长达数年的拉锯战。

3.1 const 污染（Const Poisoning）

这是 Ian Lance Taylor 最担心的问题。

传染性问题：如果你把一个底层函数的参数标记为 immut，那么所有调用它的上层函数，为了传递这个参数，往往也需要把自己的变量标记为 immut。

这种"传染性"会导致代码库中充斥着 immut 关键字。更糟糕的是，如果你以后需要修改底层函数，让它对数据进行一点点修改，你需要修改整个调用链上的类型签名。

这在 C++ 中被称为 "const correctness"的噩梦。

3.2 io.Writer 的兼容性困境

bcmills 提出了一个极其尖锐的兼容性问题：

现有的 io.Writer 接口定义是：

Write(p []byte) (n int, err error)

两难选择：

这似乎陷入了一个死循环：要么破坏所有现有代码，要么新特性无法与标准库兼容。

3.3 语义陷阱：到底是谁不可变？

jimmyfrasche 指出了一个微妙的语义问题。

在 C++ 中，const T& 只是意味着"我不可以通过这个引用去修改它"（Read-only View），并不意味着"这个数据本身不会变"。因为可能还有另一个非 const 的指针指向同一块内存，并且正在修改它。

两种语义的区别：

如果是后者（真正的内容不可变），那么 Go 必须引入一套类似 Rust 的所有权（Ownership）系统来保证"没有其他人在写"。这对于 Go 来说，改动太大了。

四、转机：泛型的"降维打击"

既然困难重重，为何在 2026 年的今天，这个提案又被翻出来了？

关键答案：泛型。

4.1 权限泛型（Permission Genericity）

在 Go 1.18 泛型落地之前，不可变性提案面临着"io.Writer 陷阱"的致命矛盾。泛型的引入为这一难题提供了全新的解题思路。

通过类型约束中的联合类型（Union Types），我们可以实现所谓的"权限泛型性"。这意味着 mutability（可变性）不再是一个硬编码的死结，而可以作为一个类型参数来处理。

设想中的泛型化 Writer 接口：

// 这是一个设想中的"权限泛型"接口
type Writer[T ~[]byte | ~immut []byte] interface {
    Write(p T) (n int, err error)
}

泛型化的影响：

1. 权限无关的调用：由于约束涵盖了两种类型，调用者现在可以合法且安全地将 immut []byte 传给标准库函数
2. 非破坏性的兼容：对于现有的实现者（如 bytes.Buffer），其原本定义的 Write([]byte) 签名可以被视为该泛型约束的一个特化实例

4.2 其他推动因素

除了泛型，还有几个关键因素：

五、社区观点：支持与质疑

5.1 支持者的声音

• romshark（提案作者）："不可变性是防止可变共享状态的技术，这是 bug 的非常常见的来源，尤其是在并发环境中。"
• 性能敏感用户：希望能够安全地共享内存，避免防御性拷贝的开销。

5.2 质疑者的担忧

• Go 团队（2025 年立场）：Michael Pratt 承认这是"可能做的最好的事情之一"，但"我们不知道该如何实现它"。核心问题在于任何这类功能都会像病毒一样在代码库中蔓延。
• 简洁性倡导者：担心 Go 会变得像 C++ 或 Rust 一样复杂，失去其"简单"的核心价值。

六、替代方案：更温和的演进

虽然完全的"不可变类型"可能依然很难落地，但社区提出了一些更温和的替代方案：

6.1 只读视图 (Read-only Views)

不是引入新的关键字，而是引入一种新的泛型类型 ReadOnly[T]，或者编译器内置的 view 类型。

6.2 纯函数检查

引入一种机制，标记某些函数是"无副作用"的，从而允许编译器进行更激进的优化。

6.3 静态分析增强

不改变语言规范，而是通过更强大的 vet 工具，利用注释或特定命名约定，来静态检查不可变性约束。

七、我的观点：一场关于设计哲学的博弈

7.1 Go 的核心矛盾

这个提案的反复讨论，反映了 Go 语言设计中的核心矛盾：

简洁性 vs. 安全性 vs. 性能

7.2 历史视角

回顾 Go 的发展历程：

• Go 1.0-1.17：坚持简洁，拒绝泛型
• Go 1.18：泛型落地，证明 Go 愿意在保持简洁的前提下引入复杂特性
• Go 1.20+：json/v2、math/rand/v2 等 v2 包的出现，证明 Go 愿意为标准库 breaking change

这表明 Go 团队并非固守成规，而是在谨慎地寻找平衡点。

7.3 可行性判断

我认为这个提案最终有可能以某种形式落地，但可能不是最初设想的样子：

1. 最可能：通过泛型实现"权限泛型性"，保持向后兼容
2. 次可能：引入 view 类型作为实验特性，逐步演进
3. 最不可能：直接引入 immut 关键字，像 C++ const 一样蔓延

7.4 对其他语言的启示

对比其他语言的处理方式：

Go 可能会走一条独特的道路：利用泛型的灵活性，在保持简洁的同时实现安全性和性能。

八、结论：Go 的未来走向

NO.27975 提案的"复活"，是一个重要信号。它表明：

1. Go 团队并未满足于现状，依然在探索如何在保持"简单"核心价值观的同时，赋予语言更强的表达力和安全性
2. 泛型为 Go 打开了新的可能性，许多之前"不可能"的特性现在有了实现路径
3. 社区对安全性和性能的需求在增长，这推动着语言向更严格的方向演进

无论最终结果如何，这都是 Go 语言演进史上值得铭记的一笔。它提醒我们：在软件工程中，没有免费的午餐，每一个简单的特性背后，都是无数次复杂的权衡。

对于 Go 开发者来说，现在或许是时候开始关注这个话题了。即使提案最终不落地，理解不可变性的价值，并在现有代码中通过约定和工具来实现类似的效果，也是提升代码质量的重要途径。

参考资料

1. GitHub Issue #27975 - Immutable Type Qualifier Proposal
2. Tony Bai - 沉睡 8 年的提案被唤醒
3. Tony Bai - Go 团队坦诚布公
4. Romshark's Go 1.2 Immutability Proposal

本文仅代表作者观点，欢迎讨论交流。