Go 中推荐使用空结构体 struct{} 定义仅承载方法、不保存状态的类型，因其零内存开销、语义清晰且符合标准库惯例；而使用 int 等具名基础类型别名不仅浪费内存，还易引发类型混淆和误用。
go 中推荐使用空结构体 `struct{}` 定义仅承载方法、不保存状态的类型，因其零内存开销、语义清晰且符合标准库惯例；而使用 `int` 等具名基础类型别名不仅浪费内存，还易引发类型混淆和误用。
在 Go 语言中，有时我们需要定义一种“无状态”的工具型类型——它不持有任何字段，仅用于组织一组相关方法（如编码/解码辅助、策略实现、常量行为封装等）。典型案例如标准库中的 binary.BigEndian 和 binary.LittleEndian：
var BigEndian binary.BigEndian
var LittleEndian binary.LittleEndian
type BigEndian struct{}
func (BigEndian) PutUint16(b []byte, v uint16) { /* ... */ }
func (BigEndian) Uint32(b []byte) uint32 { /* ... */ }
type LittleEndian struct{}
func (LittleEndian) PutUint16(b []byte, v uint16) { /* ... */ }
// ...这类类型的核心诉求是：零内存占用 + 明确意图 + 类型安全。此时，struct{} 是唯一满足全部条件的合理选择。
✅ 为什么首选 struct{}？
-
零尺寸（Zero-sized）：struct{} 的底层表示为空，unsafe.Sizeof(struct{}{}) == 0。这意味着：
- 变量声明（如 var util util）不消耗栈或堆空间；
- 作为接口实现时，值传递无开销；
- 在大型结构体中嵌入（如 type Config struct { Codec binary.ByteOrder }）不会增加内存 footprint。
语义明确：struct{} 天然表达“无数据，仅有行为”的设计意图，比 type util int 或 type util string 更直观、更不易误导——后者会让人误以为该类型与整数/字符串存在逻辑关联，甚至可能意外调用其基础类型的方法（如 int 的 + 运算）。
类型安全与封装性：struct{} 是具名类型，可独立实现方法集，且无法被其他包直接构造（因无导出字段），天然支持封装；而基于基础类型的别名（如 type util int）若未加限制，可能被滥用为数值参与计算，破坏抽象边界。
❌ 为什么不推荐 int、string 等基础类型别名？
type util int // ❌ 不推荐
func (util) Help(v VM) {}尽管语法合法，但存在严重隐患：
- 内存浪费：每个 util 实例占用至少 8 字节（64 位平台），而实际完全不需要存储任何数据；
- 类型污染：util(42) 合法，u := util(1); u++ 也合法——这违背了“纯行为类型”的设计初衷；
- 接口实现风险：若某处期望 interface{ Help(VM) }，传入 util 值虽能工作，但其底层 int 特性可能在反射或调试中暴露冗余信息，降低可维护性。
✅ 最佳实践示例
type Util struct{} // 清晰、轻量、意图明确
func (Util) Help(v VM) { /* ... */ }
func (Util) HelpMe(v VM) { /* ... */ }
func (Util) HelpYou(v VM) { /* ... */ }
func (Util) HelpEveryone(v VM) { /* ... */ }
// 使用方式（零开销）
var util Util
util.Help(vm)? 提示：空结构体变量可安全取地址（&Util{}），其指针有效且唯一；但注意 Util{} 本身不可比较（因结构体含不可比较字段时不可比较，而 struct{} 是可比较的——不过通常无需比较）。
总结
选择 struct{} 作为方法-only 类型的底层类型，不是权宜之计，而是 Go 语言惯用、经标准库验证的最佳实践。它兼顾性能（零内存）、语义（无状态即行为）与工程健壮性（防误用、易维护）。在设计工具类、策略对象或接口实现体时，请坚定使用 struct{} —— 这是 Go 式简洁与精确的体现。
