Go面向接口编程应从首行代码实践，依赖隐式实现、接口变量持有和运行时多态；interface{}无法替代具体接口因无行为约束；指针/值接收者需匹配接口方法定义；私有结构体+公有接口+工厂函数保障解耦；接口应小而专、可组合；接口变量须判空防panic。
Go 的面向接口编程不是“学完再用”的理论，而是从第一行可运行代码开始就该介入的实践习惯。它不依赖继承或泛型约束，靠的是隐式实现 + 接口变量持有 + 运行时多态这三样东西撑起整个解耦骨架。
为什么 interface{} 不能替代具体接口
新手常把 interface{} 当成万能占位符，传参、返回、存切片全用它，结果很快遇到两个问题：一是方法调用必须先类型断言，二是编译器完全无法检查你是否漏实现关键行为。
-
interface{}是空接口，只保证“是个值”，不承诺任何能力；而业务接口如Reader、Writer或自定义的Parser，明确约定了“能做什么” - 用
interface{}存储结构体后，想调用Parse()方法？得写v.(Parser).Parse()—— 这里一旦类型不符就 panic，且 IDE 无法跳转、无法补全 - 真正解耦的前提是“调用方只依赖接口定义”，而不是依赖某个 struct 名字或字段布局
指针接收者 vs 值接收者：接口实现失败的常见原因
一个结构体实现了某个接口方法，但赋值给接口变量时报错：“cannot use … as … value in assignment: missing method …”。八成是因为接收者类型不匹配。
- 如果接口方法定义为
func (t *T) Do() error，那只有*T类型能实现它；T类型不行 - 反过来，若方法是
func (t T) Do() error，则T和*T都能实现（因为 Go 会自动取地址或解引用） - 典型坑：定义了
func (s *Service) Start()，却试图把Service{}（而非&Service{}）赋给Starter接口变量 - 建议统一用指针接收者——既避免拷贝大结构体，也规避这类实现歧义
私有结构体 + 公有接口：控制构造权的关键组合
对外暴露接口、隐藏具体 struct，不是为了炫技，而是为了后续替换实现不改调用方代码。但前提是 struct 必须是包内私有的，否则别人绕过你的工厂函数直接 new。
立即学习“go语言免费学习笔记（深入）”；
- 定义
type client struct{ ... }（小写开头），再定义type Client interface{ Do() error } - 提供
NewClient(...)函数返回Client接口，而不是*client - 这样外部包只能通过接口调用，无法直接构造
client实例，也就无法依赖其字段或未导出方法 - 后续你想把
client换成基于 HTTP/2 的实现，或加 mock、加中间件，只要新 struct 实现了Client接口，老代码完全无感
接口嵌套与组合：避免爆炸式接口定义
别一上来就定义 type DataProcessor interface{ Read() error; Write() error; Validate() error; Log() error }。这种“大而全”接口很难复用，也违背单一职责。
- 优先拆成小接口：
Reader、Writer、Validator，再按需组合：type Processor interface{ Reader; Writer; Validator } - 嵌套后，实现
Processor只需实现三个小接口的方法，而不是一次性写一堆 - 调用方也能按需依赖：
func Load(r Reader)比func Load(p Processor)更灵活，未来支持只读场景无需改签名 - 注意：嵌套接口只是语法糖，底层仍是方法集合合并，不会产生额外开销
接口不是写完就扔的契约文档，它是调用链上每个环节的“能力说明书”。最容易被忽略的，是接口变量本身可能为 nil —— 尤其在工厂函数返回前没做判空、或 map 查找不到键时直接赋值，一调方法就 crash。别省那两行 if x != nil。
