var _ interface = (*struct)(nil) 能在编译期报错，本质是go编译器执行赋值类型检查：将(*struct)(nil)作为右值尝试赋给interface类型空白变量，若*struct未实现interface全部方法，立即报错；该机制依赖原生静态类型系统，零开销、不触发初始化、无需反射或工具链。
为什么 var _ Interface = (*Struct)(nil) 能在编译期报错
它不是运行时检查，也不是工具链扫描，而是 Go 编译器对一次赋值语句做的原生类型兼容性验证：把 (*Struct)(nil) 当作右值，尝试赋给左值 Interface 类型的空白变量。只要 *Struct 没实现 Interface 的全部方法，编译器立刻报错：cannot use (*Struct)(nil) (type *Struct) as type Interface in assignment: *Struct does not implement Interface。
这个机制完全依赖 Go 静态类型系统，零开销、不触发任何初始化逻辑（比如 sync.Mutex 字段不会 panic），也不依赖反射或 AST 分析。
(*Struct)(nil) 为什么不能换成 Struct{} 或 &Struct{}
用 Struct{} 会失败，因为它是值类型，而接口要求的是指针接收者方法（若接口方法由指针接收者定义）；&Struct{} 看似合理，但会实际构造一个零值实例——如果结构体含 sync.Mutex、io.ReadCloser 等字段，构造过程可能 panic 或触发副作用。
-
(*Struct)(nil)是最轻量、最安全的占位表达式：它只声明类型，不分配内存，不调用任何构造逻辑 - 必须确保接口方法签名和结构体方法签名**完全一致**：包括大小写、参数名（可省略）、返回值顺序和类型
- 如果结构体方法是值接收者，但接口方法是指针接收者，校验会失败；反之亦然
校验语句放错位置就等于没写
这行代码必须出现在包级作用域（即 package 声明之后、任何 func 之前），且所在文件必须被 go build 或 go test 实际纳入编译流程。
- 写在函数内部？编译器直接忽略，不参与类型检查
- 放在
build tag控制的条件编译块里（如//go:build !test），而当前构建不满足条件？那它根本不会被解析 - 结构体和接口在不同包时，校验语句**必须写在结构体所在包**，不能写在接口定义包——实现方才有责任保证兑现契约
- 写在
_test.go文件里可以生效，但仅限于go test构建；想让主构建失败，就得放在非测试文件中
导出规则和泛型约束里的相似陷阱
接口本身必须导出（首字母大写），否则跨包校验失效；这点和泛型约束名必须大写是同一套可见性规则——Go 不允许包外代码“看到”未导出的接口定义，自然也无法验证其实现。
泛型场景下，类似问题更隐蔽：比如你定义了 type number interface{ ~int | ~float64 }，但 number 小写，其他包调用 func Sum[T number]() 会报 cannot use number (not defined in this package)，和接口未导出导致的校验静默失效本质相同。
真正容易被忽略的是：这种编译期检查只覆盖「当前已知的方法集」。如果接口后续新增方法，而你没更新校验语句所在包，它不会自动提醒——得靠 CI 或人工复查变更影响范围。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
