## 引言：沉睡 8 年的提案为何被唤醒？
2026 年 2 月，Go 语言规范团队的一次例行会议纪要在社区引发轩然大波——**Issue #27975**，这个关于引入不可变类型（Immutable Types）的提案，在沉寂 8 年后重新回到了讨论桌前。
这个提案最初提交于 2018 年，那是"Towards Go 2"口号喊得最响亮的年代。当时社区正沉浸在对泛型、错误处理和不可变性的热烈讨论中。然而，随着泛型在 Go 1.18 落地，关于不可变性的声音似乎逐渐微弱。甚至在 2025 年 9 月的 GopherCon Europe 座谈会上，Go 团队还明确表示对不可变类型"我们放弃了"。
**为何短短数月后，这个"已被放弃"的提案又重获新生？**
本文将深入分析这一提案的核心内容、技术挑战、社区分歧，以及它背后反映的 Go 语言设计哲学的深层矛盾。
---
## 一、问题背景：防御性拷贝的代价
在深入提案之前，我们需要理解它试图解决的核心问题。
### 1.1 现实中的痛点
假设你有一个包含敏感配置的结构体，想把它暴露给其他包，但又不希望它被修改：
```go
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）的引入，旨在提供**第三种选择**：既安全，又高效。
**理想中的代码：**
```go
// 定义一个只读的切片类型
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` 接口定义是：
```go
Write(p []byte) (n int, err error)
```
**两难选择：**
| 方案 | 结果 |
|:---|:---|
| 把 `p` 改成 `immut []byte` | 现有的所有 Write 方法实现都会破坏兼容性 |
| 不改 | 即使手里有一个只读的切片，也没法传给 io.Writer，因为类型不匹配 |
这似乎陷入了一个死循环：要么破坏所有现有代码，要么新特性无法与标准库兼容。
### 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 接口：**
```go
// 这是一个设想中的"权限泛型"接口
type Writer[T ~[]byte | ~immut []byte] interface {
Write(p T) (n int, err error)
}
```
**泛型化的影响：**
1. **权限无关的调用**：由于约束涵盖了两种类型，调用者现在可以合法且安全地将 `immut []byte` 传给标准库函数
2. **非破坏性的兼容**：对于现有的实现者（如 `bytes.Buffer`），其原本定义的 `Write([]byte)` 签名可以被视为该泛型约束的一个特化实例
### 4.2 其他推动因素
除了泛型，还有几个关键因素：
| 因素 | 说明 |
|:---|:---|
| **性能压力** | Go 在高性能领域（数据库、AI 推理）的应用越来越深，对"零拷贝"的需求越来越强烈 |
| **安全性需求** | 数据竞争依然是 Go 程序的头号杀手，社区渴望编译期的保证而非运行时的检测 |
---
## 五、社区观点：支持与质疑
### 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 对其他语言的启示
对比其他语言的处理方式：
| 语言 | 不可变性方案 | 复杂度 |
|:---|:---|:---:|
| **Rust** | 所有权 + 借用检查 | 高 |
| **C++** | const 限定符 | 中（但有 const correctness 噩梦） |
| **Java** | `final` 关键字（仅引用不可变） | 低（语义不完整） |
| **Kotlin** | `val` / `var` 区分 | 低 |
Go 可能会走一条独特的道路：利用泛型的灵活性，在保持简洁的同时实现安全性和性能。
---
## 八、结论：Go 的未来走向
NO.27975 提案的"复活"，是一个重要信号。它表明：
1. **Go 团队并未满足于现状**，依然在探索如何在保持"简单"核心价值观的同时，赋予语言更强的表达力和安全性
2. **泛型为 Go 打开了新的可能性**，许多之前"不可能"的特性现在有了实现路径
3. **社区对安全性和性能的需求在增长**，这推动着语言向更严格的方向演进
无论最终结果如何，这都是 Go 语言演进史上值得铭记的一笔。它提醒我们：**在软件工程中，没有免费的午餐，每一个简单的特性背后，都是无数次复杂的权衡。**
对于 Go 开发者来说，现在或许是时候开始关注这个话题了。即使提案最终不落地，理解不可变性的价值，并在现有代码中通过约定和工具来实现类似的效果，也是提升代码质量的重要途径。
---
## 参考资料
1. [GitHub Issue #27975 - Immutable Type Qualifier Proposal](https://github.com/golang/go/issues/27975)
2. [Tony Bai - 沉睡 8 年的提案被唤醒](https://tonybai.com/2026/02/09/go-immutable-types-8-year-dormant-proposal-awakened/)
3. [Tony Bai - Go 团队坦诚布公](https://tonybai.com/2025/09/22/go-team-gave-up-on-features/)
4. [Romshark's Go 1.2 Immutability Proposal](https://github.com/romshark/Go-1-2-Proposal---Immutability)
---
*本文仅代表作者观点，欢迎讨论交流。*
登录后可参与表态
讨论回复
1 条回复
C3P0 (C3P0)
#1
02-10 17:49
登录后可参与表态