Go为何不用this关键字？

Go语言虽允许将方法接收者命名为`this`，但官方明确反对这种做法——它不仅违背Go“显式优于隐式”的设计哲学和函数优先、组合优于继承的语言本质，还因接收者可为值或指针而引发语义混淆（如误以为`this`总是指向原实例），损害代码可读性与准确性；真正地道的Go风格是使用简短、具体、小写的接收者名（如`s`、`u`、`db`），让类型意图一目了然，使代码更清晰、一致且符合社区共识。

Go 语言中虽允许将方法接收者命名为 `this`，但违背官方代码规范，且易引发语义混淆——因 Go 的接收者可为值或指针，而 `this` 暗示“当前对象指针”，与语言设计哲学相悖。

在 Go 中，方法接收者（receiver）的命名属于标识符范畴，语言本身不限制名称（如 this、self、me 甚至 x 都是合法的），技术上完全可行。例如以下代码能正常编译运行：

type MyStruct struct {
    someField string
}

func (this MyStruct) getSomeField() string {
    return this.someField // ✅ 语法正确，逻辑无误
}

然而，Go 官方《Code Review Comments》明确建议：

Don’t use generic names such as "me", "this" or "self" — identifiers typical of object-oriented languages that place more emphasis on methods as opposed to functions.

这一建议背后有两层重要考量：

? 哲学一致性：Go 并非传统面向对象语言，它没有类、继承或 this 隐式上下文。方法本质是“绑定到类型的函数”，强调清晰性与显式性。使用 this 会不必要地引入 OOP 语义包袱，模糊 Go “组合优于继承”“函数优先”的设计本意。

? 语义准确性：在 Java/C++/Python 等语言中，this 或 self 总是指向当前实例的指针/引用；而在 Go 中，接收者可以是值类型（func (s MyStruct) ...）或指针类型（func (s *MyStruct) ...）。若统一用 this 命名，却在值接收者场景下实际操作的是副本，容易误导读者误判内存行为（如误以为修改 this.field 会影响原值——实则不会）。

✅ 推荐做法是：

• 使用短小、有意义、小写的单字母或缩写，如 s（struct）、m（message）、c（config）、r（reader）；
• 若类型语义明确，可稍具描述性，如 u *User、db *DB；
• 保持包内风格统一，优先遵循 Effective Go 的简洁原则。

// ✅ 符合 Go 风格的写法
func (s MyStruct) GetSomeField() string {
    return s.someField
}

func (u *User) Save() error {
    return u.db.Save(u) // 显式、无歧义
}

? 总结：不用 this 不是语法限制，而是 Go 社区对可读性、一致性与语言正交性的集体约定。坚持清晰、显式、轻量的命名习惯，才能写出真正“Go-like”的代码。

到这里，我们也就讲完了《Go为何不用this关键字？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！