go语言不支持运算符重载，是设计上的主动放弃而非缺陷；+、-、==等运算符仅对内置类型有效且行为固定，自定义类型必须用明确命名的方法（如add、plus）替代，以避免语义冲突、保障类型安全与可读性。
Go语言不支持运算符重载，这不是一个待修复的缺陷，而是设计上的主动放弃——它直接改变了你写代码时的思考路径。
为什么+不能对自定义类型重载
你在其他语言里习惯的vec1 + vec2或money1 + money2在Go里会编译失败。因为Go的+、-、==等运算符只对内置类型（整数、浮点、字符串、复数、指针、channel、map、slice、func）有效，且行为完全由语言定义，无法扩展。
这不是遗漏，是刻意为之：避免类型系统与运算符语义耦合过深，防止不同包对同一运算符赋予冲突含义。比如两个第三方库都定义了Duration + Duration，但一个返回Duration，另一个返回float64，编译器无法消歧。
- 所有自定义类型必须用方法代替运算符，如
vec.Add(other)或money.Plus(other) - 接口无法约束运算符行为，
type Adder interface { Add(Adder) Adder }只能约定方法名，不能绑定到+ - 连
==和!=也受限：结构体字段全可比较时才允许，含map、slice、func字段则直接报错
==比较失败的常见场景
你以为==能像Java的equals()一样被重写？不能。Go的==是编译期静态判断，不调用任何用户代码。
典型翻车点：
- 含
map字段的结构体：struct{ m map[string]int }{m: map[string]int{"a": 1}} == struct{ m map[string]int }{m: map[string]int{"a": 1}}→ 编译错误 - 含
slice字段的结构体：struct{ s []int }{s: []int{1,2}} == struct{ s []int }{s: []int{1,2}}→ 编译错误（即使内容相同） - 匿名字段嵌套不可比较类型，也会传染：外层结构体哪怕只读，只要内嵌不可比较字段，整个结构体就失去
==资格
替代方案只有显式循环比对或用reflect.DeepEqual（性能差，仅适合测试）。
从“写法直觉”到“设计意图”的切换成本
初学者常把Go当成“带GC的C”，试图用运算符表达领域逻辑，结果卡在编译器报错上。这种挫败感本质是范式切换：Go要求你把“什么操作”和“怎么操作”彻底分离。
- 运算符只负责基础算术、拼接、布尔判断——语义窄且固定
- 业务逻辑必须封装进方法或函数，名字要明确：
user.MergeProfile()比user1 + user2更难误解 - 没有重载，意味着调用者永远知道
+做了什么：不是加法就是字符串拼接，绝不会是“合并配置”或“叠加权限”
这降低了阅读成本，但抬高了初期建模门槛——你得先想清楚“这个行为该叫什么”，而不是直接套用符号。
真正容易被忽略的，不是语法限制本身，而是它迫使你提前暴露设计决策：每个运算意图都必须变成一个命名实体。这对小项目像枷锁，对协作规模超百人的系统，却是防止语义漂移的锚点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
