go 语言不会为每个结构体实例重复分配方法代码，所有方法仅在编译期生成一份静态元数据；仅当结构体值被赋给接口时，运行时才按需、一次性缓存对应接口的 itable，且后续复用不新增内存开销。
go 语言不会为每个结构体实例重复分配方法代码，所有方法仅在编译期生成一份静态元数据；仅当结构体值被赋给接口时，运行时才按需、一次性缓存对应接口的 itable，且后续复用不新增内存开销。
在 Go 中，方法本质上是带有接收者参数的函数，不隶属于结构体实例。与 C++ 的虚函数表（vtable）不同，Go 并未为每个 struct 实例维护方法指针数组，也不会在堆或栈上为每个实例复制方法代码或跳转表。方法代码本身由编译器统一生成并驻留在只读代码段中，而方法集（method set）信息则作为类型元数据，在程序启动时静态初始化、全局唯一。
真正涉及动态内存分配的环节，仅发生在 结构体值被赋给接口类型时。此时 Go 运行时会构建一个 itable（interface table），用于记录该具体类型对某接口的实现关系，包括：
- 接口方法签名到具体函数指针的映射；
- 类型转换所需偏移量（如嵌入字段）；
- 类型反射信息（_type 指针）。
关键特性如下：
✅ 按接口维度缓存：每个 (T, I) 组合（即类型 T 实现接口 I）最多生成一个 itable，首次赋值时创建，之后全部复用；
✅ 零开销实例化：纯结构体切片（如 []Custom）不触发任何 itable 分配，10,000 个 Custom{} 实例仅占用字段内存（本例中为 string 字段的底层数据 + header）；
❌ 非接口使用无额外成本：如原问题中直接调用 c.TurnItUp() 或存储为 []Custom，全程不涉及 itable，亦无方法集内存拷贝。
以下对比示例清晰体现行为差异：
// 示例 1：无接口 → 零 itable 分配
var many []Custom
for i := 0; i < 10000; i++ {
many = append(many, Custom{value: "nowhere"})
}
// 内存增长仅来自 10000 个 struct 实例（含 string header + data）// 示例 2：单接口 → 仅 1 个 itable（全局复用）
type Volume interface {
TurnItUp()
TurnItDown()
}
var volumes []Volume
for i := 0; i < 10000; i++ {
volumes = append(volumes, Custom{value: "nowhere"}) // 首次触发 itable 构建
}
// 后续 9999 次 append 复用同一 itable，无新分配// 示例 3：两个不兼容接口 → 2 个独立 itable
type Upper interface{ TurnItUp() }
type Downer interface{ TurnItDown() }
var uppers []Upper
var downers []Downer
for i := 0; i < 10000; i++ {
uppers = append(uppers, Custom{value: "nowhere"}) // 创建 (Custom, Upper) itable
downers = append(downers, Custom{value: "nowhere"}) // 创建 (Custom, Downer) itable
}
// 共分配 2 个 itable，各自缓存，互不影响⚠️ 注意事项：
- itable 分配发生在接口值构造时（如 Volume(c) 或 append([]Volume, c)），而非类型定义或方法声明时；
- 使用 unsafe.Sizeof 或 runtime.MemStats 可验证：纯结构体切片的内存增长严格等于 len × sizeof(Custom)，不含方法相关开销；
- 若需极致内存敏感场景（如百万级轻量对象），应避免不必要的接口包装——直接操作具体类型既高效又可控；
- 所有 itable 元数据由运行时管理，开发者无需手动释放，GC 会自动回收不再可达的 itable（实践中极少发生，因通常长期存活）。
总结而言，Go 通过“静态方法代码 + 懒加载/强缓存 itable”的设计，在保持接口灵活性的同时，彻底规避了方法集的实例级冗余分配，兼顾了性能、简洁性与工程可预测性。
