Go 明确放弃 C/C++ 风格的 const 类型限定符（如 const T*），并非疏漏，而是基于“简洁性优先、代码即契约”的核心设计哲学：用清晰的接口约定、不可变语义和工具链辅助替代复杂的类型修饰系统。
go 明确放弃 c/c++ 风格的 `const` 类型限定符（如 `const t*`），并非疏漏，而是基于“简洁性优先、代码即契约”的核心设计哲学：用清晰的接口约定、不可变语义和工具链辅助替代复杂的类型修饰系统。
在 C++ 等语言中，const 是一个类型系统层面的限定符，可用于修饰变量、指针、函数参数甚至成员函数，形成细粒度的“只读承诺”（例如 void process(const BigStruct* s) 表示该函数不会通过 s 修改所指对象）。这种机制增强了编译期安全性，但也显著增加了类型系统的复杂度——开发者需记忆 const T*、T* const、const T* const 等多重组合，并面临 const_cast 绕过、mutable 特例等例外情形。
而 Go 的设计选择截然不同：它不提供任何类型级别的 const 限定符（如 const *T 或 func(f *const File) 这类语法根本不存在），原因在于其根本设计信条——
✅ 类型系统应服务于表达，而非约束：Go 的类型系统刻意保持极简（无泛型前尤其如此），避免让开发者陷入“为满足类型而写类型”的困境；
✅ 契约应由 API 设计与文档显式承载，而非隐式嵌入类型：若一个函数不应修改传入结构体，Go 社区惯例是——
- 使用值传递（func Process(s MyStruct)）明确表示“接收副本”，天然不可反向修改原值；
- 若需高效传递大结构体，则通过只读接口抽象行为，而非修饰指针：
type Reader interface {
Read() []byte // 不暴露写方法，从接口层面杜绝修改意图
}
func Process(r Reader) { /* 安全消费，无需 const 保证 */ }✅ 不可变性由语言原语与惯用法保障：
- const 关键字仅用于编译期常量声明（如 const MaxRetries = 3），语义单一、不可覆盖；
- 字符串（string）、切片头（slice header）本身是不可变视图（string 底层数组不可写，slice 可重切但不直接暴露底层指针修改能力）；
- map、chan、slice 等引用类型虽可被修改内容，但 Go 鼓励通过封装+方法控制实现逻辑只读：
type Config struct {
data map[string]string
}
// 提供只读访问，隐藏可变内部
func (c *Config) Get(key string) string {
return c.data[key]
}
// 不暴露 Set 方法 → 外部无法修改⚠️ 关键注意事项：
- 值传递 ≠ 绝对安全：若结构体包含指针字段（如 *[]int），副本仍指向同一底层数组，此时并发读写仍需同步（如 sync.RWMutex）；这不是 const 能解决的问题，而是数据所有权与共享模型的设计责任；
- Go 工具链弥补静态检查空白：go vet、staticcheck、golangci-lint 等可检测常见误修改模式（如未使用的返回值、可疑的指针别名）；
- “传指针即可能修改”是 Go 的显式契约文化：函数签名 func Update(u *User) 本身即暗示副作用，开发者需主动审查文档与实现，而非依赖类型修饰“自动担保”。
总结而言，Go 放弃 const 类型限定符，是其“少即是多”哲学的典型体现——它用更少的语言特性，换取更高的可读性、更低的学习成本与更强的工具可分析性。真正的“只读保障”，在 Go 中不靠类型修饰，而靠值语义的合理使用、接口的精确抽象、包级封装的严格控制，以及整个生态对清晰契约的共同遵守。
