Go 语言明确禁止将指向接口的指针（如 *IFile）作为嵌入字段，因其既违反结构体嵌入语法规则，又违背接口的设计本质——接口值本身已能容纳指针或值，再加一层指针冗余且危险。
go 语言明确禁止将指向接口的指针（如 `*ifile`）作为嵌入字段，因其既违反结构体嵌入语法规则，又违背接口的设计本质——接口值本身已能容纳指针或值，再加一层指针冗余且危险。
在 Go 中，结构体嵌入（embedding）是一项强大而精巧的机制，用于实现组合与方法提升。但它的语法和语义受到严格约束，其中一条核心限制便是：嵌入类型必须是具名类型 T 或指向非接口类型的指针 *T，而 *interface{} 是明确禁止的。
An embedded type must be specified as a type name
Tor as a pointer to a non-interface type name*T, andTitself may not be a pointer type.
关键词是 “pointer to a non-interface” —— 即 *T 中的 T 必须是具体类型（如 struct、int、自定义类型等），绝不能是接口类型。因此以下写法均非法：
type TestFile struct {
*IFile // ❌ 编译错误："embedded type cannot be a pointer to interface"
**IFile // ❌ 更错：T 本身已是指针，且仍是接口
*interface{} // ❌ 同样违反规则
}
为什么不允许 *IFile？根本原因有三：
语义冗余且易误导
接口类型（如IFile）在运行时本就以(type, value)二元组形式存在，其value部分天然可为指针（如*os.File）或值（如bytes.Buffer）。显式写成*IFile会让人误以为“需要取接口的地址”，但接口变量本身不可寻址（类似map或func），对它取地址无意义且不安全。无法构造合法值
假设允许*IFile，那么如何初始化该字段？&IFile是非法的（接口类型无地址），&someImpl又不是*IFile类型（*FileImpl≠*IFile）。Go 不支持接口指针的隐式转换，这会导致该字段永远无法被有效赋值。破坏方法提升逻辑
嵌入的核心价值在于「自动提升嵌入类型的方法到外层结构体」。但*IFile不是一个可拥有方法的类型——接口类型的方法属于其实现者，*IFile本身无方法集。提升无从谈起，嵌入失去意义。
✅ 正确做法：嵌入接口本身，而非其指针
你真正需要的，是让 TestFile 拥有 IFile 的所有方法，这只需直接嵌入接口：
type IFile interface {
Read() (n int, err error)
Write() (n int, err error)
}
type TestFile struct {
IFile // ✅ 合法：嵌入非指针接口类型
}
// 使用示例
func main() {
f := TestFile{
IFile: &os.File{}, // 实现者可以是 *os.File（指针）
// 或 IFile: bytes.Buffer{} // 也可以是值类型
}
n, err := f.Read() // 方法被自动提升，可直接调用
}
此时 TestFile 自动获得 Read() 和 Write() 方法（接收者为 TestFile，内部转发至 IFile 字段），完全满足组合需求。
⚠️ 重要提醒：嵌入接口 ≠ 实现接口
需特别注意：嵌入 IFile 仅表示 TestFile 声明了 IFile 字段，并获得其方法提升；但它并不自动实现 IFile 接口——除非你为 TestFile 显式实现 Read/Write，或确保 IFile 字段非 nil 并正确转发。更常见、更安全的模式是避免嵌入接口，改用组合+显式委托：
type TestFile struct {
file IFile // 导出字段名，语义清晰
}
func (t TestFile) Read() (int, error) { return t.file.Read() }
func (t TestFile) Write() (int, error) { return t.file.Write() }
这种方式可控、可测试、无 panic 风险，是 Go 生态中（如 io.Reader/io.Writer 组合）广泛采用的惯用法。
总结：Go 禁止 *interface{} 嵌入，是语言一致性与安全性的必然选择。拥抱接口值的天然灵活性，善用组合与显式委托，才能写出清晰、健壮、符合 Go 风格的代码。
