Go语言不支持方法重载，同名但参数不同的方法会编译失败；应通过不同方法名、接口实现、可变参数、结构体选项或类型断言等惯用方式替代，契合其简洁、显式、类型安全的设计哲学。
Go 语言不支持方法重载，任何同名但参数类型或数量不同的 Add、Print、Save 方法放在同一作用域都会触发编译错误：redeclared in this block。这不是限制，而是设计选择——它强制你用更清晰、更易维护的方式表达意图。
为什么 func (t T) Add(a int) int 和 func (t T) Add(s string) string 一定编译失败
Go 的方法签名（名称 + 参数类型 + 返回类型）必须全局唯一。编译器不会根据参数类型做运行时分发，也不做隐式转换或重载解析。一旦出现两个 Add，哪怕接收者不同、参数完全不相干，也会报错。
- 常见错误现象：在 IDE 里写完第二个
Add立刻红标，go build直接失败，错误信息类似method redeclared: T.Add - 根本原因：Go 的方法集（method set）是静态确定的，不依赖调用时的实际参数类型
- 别指望靠接收者类型“绕过”：即使一个是
func (t T) Add(...)，另一个是func (t *T) Add(...)，只要方法名相同，仍会冲突
用不同函数名替代重载是最直接、最安全的做法
Go 社区高频实践是为语义相近但类型/行为不同的操作起明确函数名，比如 AddInt、AddFloat64、AddVector。这比隐藏分支逻辑更利于阅读、调试和工具链支持（如 go doc、IDE 跳转）。
- 使用场景：包级工具函数（如
json.Marshalvsyaml.Marshal）、结构体上需区分输入类型的运算 - 参数差异：不混用类型，避免
func Add(x, y interface{})这类泛型前时代的“万能接口”写法 - 性能影响：零额外开销；编译期绑定，无反射或类型断言成本
- 示例：
func (v *Vector) AddInt(other Vector) *Vector { /* ... */ } func (v *Vector) AddFloat64(scale float64) *Vector { /* ... */ }
用接口统一行为契约，而非塞进一个方法名
当你真正需要“对多种类型做同一件事”，比如序列化、校验、日志输出，接口才是 Go 的惯用解法。它把“能做什么”和“谁来做”解耦，而不是靠重载制造假统一。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：定义一个宽泛的
Processor接口，里面塞了Add、Validate、Render，结果每个实现只填一个方法，其余返回panic("not implemented") - 正确做法：按最小职责拆接口，如
type Marshaler interface { Marshal() ([]byte, error) }，让Person、Event、Config各自实现 - 注意方法集规则：如果接口方法用指针接收者定义（
func (t *T) Marshal()），那只有*T能满足该接口，T{}值类型不行
真要单入口分发？用 switch v := x.(type)，但仅限顶层
仅在确实需要动态路由的场景（如 CLI 命令分发、RPC 请求处理器）才考虑 interface{} + 类型断言。这不是重载替代品，而是一种有代价的分发机制。
- 性能影响：每次断言都有微小反射开销；大量分支会拖慢编译和热路径执行
- 可读性风险：所有分支挤在一个函数里，类型逻辑分散，难测试
- 关键约束：永远不在循环、HTTP handler 内部、高频计算路径中做多次断言；只在
main()或命令入口做一次，立刻转给专用函数 - 示例：
func HandleCommand(cmd interface{}) { switch c := cmd.(type) { case StartCmd: handleStart(c) case StopCmd: handleStop(c) default: log.Fatal("unknown command") } }
最容易被忽略的一点：Go 的方法集规则不是语法细节，而是接口实现的硬边界。比如 func (t *T) Notify() 定义后，T{} 值本身不能赋给 Notifier 接口变量，必须传 &t。这个约束会穿透到所有基于接口的“重载式”设计里——没意识到这点，90% 的运行时 panic 都源于此。
