go接口多态依赖方法签名严格匹配：方法名、参数类型列表、返回值类型列表必须完全一致，包括大小写、指针/值接收者、类型别名等细节；interface{}无行为契约，非真正多态；接口变量底层为(type, value)二元组，动态调度但编译期校验。
Go 里接口多态不靠声明，靠函数签名完全匹配——差一个字母、一个指针符号、一个返回值类型，就不是同一个接口实现。
接口方法签名必须逐字匹配
Go 接口的实现是隐式的，但匹配条件极其严格：方法名、参数类型列表、返回值类型列表，三者必须与接口定义完全一致。哪怕只是把 func (s *Shape) Area() float64 写成 func (s Shape) Area() float64（值接收者 vs 指针接收者），该类型就无法赋值给该接口变量。
- 大小写敏感：
Area()和area()是两个不同方法 - 接收者类型影响实现资格：
(*Circle).Area实现了接口，(Circle).Area可能没实现（取决于接口要求） - 参数/返回值不能有别名干扰：即使
type MyFloat float64，func() MyFloat也不等于func() float64，除非显式转换或重定义
interface{} 不是多态接口，只是类型擦除容器
写 func Process(v interface{}) 看起来“能传任何东西”，但它不提供任何行为契约。你无法在函数体内安全调用 v.Area()，因为编译器不知道 v 是否有这个方法——它只是个空壳。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 真正多态起点是定义带方法的接口，比如
type Shape interface{ Area() float64 } -
interface{}常用于泛型前时代的通用容器（如map[interface{}]interface{}），但会丢失类型信息和方法访问能力 - 若真需要运行时判别行为，得配合类型断言（
v.(Shape)）或反射，但这是兜底手段，非设计首选
指针接收者与值接收者决定谁能赋值给接口
结构体是否能被赋给某接口，取决于其方法集是否包含接口要求的所有方法——而方法集由接收者类型决定。
- 值接收者方法：属于
T和*T的方法集（*T可调用T的值接收者方法） - 指针接收者方法：只属于
*T的方法集（T无法调用） - 所以如果接口要求
ChangeName(string)是指针接收者，那么var s MyStruct = ...; var i Interface = s会编译失败；必须写i = &s
接口变量底层是 (type, value) 二元组，动态分发靠 runtime
当你写 var s Shape = Circle{radius: 2.0}，变量 s 实际存储的是一个类型描述符 + 数据指针。调用 s.Area() 时，Go runtime 根据实际类型查表跳转到对应实现，这叫“动态调度”——但整个过程在编译期已校验合法性。
- 没有虚函数表（vtable）概念，但效果类似；性能开销极小，基本等价于一次间接跳转
- 接口变量本身不保存方法地址，只存类型信息；方法查找发生在首次调用时并缓存
- 注意：接口变量为 nil 时，调用其方法会 panic（
nil pointer dereference），不是空安全的
最容易被忽略的是接收者类型与接口赋值之间的隐含约束——它不像 Java 那样“对象就是对象”，而是“值就是值，指针就是指针”。写接口时就要想清楚：这个方法是否要修改状态？是否需要保持引用一致性？一旦定下接收者形式，所有实现者都得对齐，否则多态链就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
