Go语言中空结构体作为方法接收器是否为不良实践？是否应改用普通函数？

空结构体作为方法接收器并非绝对的不良编码实践，要不要改成普通函数，核心看你的代码场景和需求：

适合保留空结构体方法的场景 #

• 必须实现某个接口：如果你的逻辑需要满足特定接口契约，但又不需要维护任何状态，空结构体是完美的选择。比如要实现io.Writer但只做空操作（比如测试用的静默输出），用空结构体实现接口方法，能让代码符合类型系统要求，而普通函数无法直接赋值给接口类型变量。
• 归类相关无状态函数：把一组功能相关的无状态函数绑定到空结构体上，相当于给函数加了"命名空间"，让代码结构更清晰。比如type MathUtils struct{}，它的方法都是加减乘除这类纯工具函数，比零散的全局函数更易查找和维护。
• 预留未来扩展空间：如果以后可能需要给这个结构体添加字段（也就是需要维护状态），提前用方法接收器的写法，后续加字段时不需要修改函数的调用方式，能减少重构成本。

建议改用普通函数的场景 #

• 无接口约束且无需归类：如果你的函数既不需要实现任何接口，也不需要和其他函数归为一组，直接用普通全局函数更简洁，没必要多定义一个空结构体。比如你给出的示例代码，DoSomething()完全是独立无状态的逻辑，普通函数写法更直接，减少不必要的代码层级。
• 避免语义误解：空结构体方法可能会让其他开发者误以为这个结构体应该有状态，或者存在未完成的逻辑，反而增加理解成本。这种情况下，普通函数的语义更明确——就是一个无依赖的工具函数。

场景示例对比 #

接口实现场景（适合空结构体）

// 定义一个日志接口
type Logger interface {
    Log(message string)
}

// 用空结构体实现无操作日志器
type NoopLogger struct{}

func (n *NoopLogger) Log(message string) {
    // 什么都不做，用于测试环境
}

// 使用时可以直接赋值给Logger变量
var logger Logger = &NoopLogger{}

这种情况如果用普通函数，无法直接满足接口要求，必须额外包装，反而更麻烦。

独立工具函数场景（适合普通函数）

// 普通函数写法更简洁
func DoSomething() error {
    return nil
}

// 空结构体写法没必要，多了一层定义
type Example struct{}
func (e *Example) DoSomething() error {
    return nil
}

总结 #

空结构体作为方法接收器本身没问题，关键看是否匹配你的需求：有接口、代码组织或扩展需求时保留，没有这些需求时建议改用普通函数，让代码更简洁直接。

内容的提问来源于stack exchange，提问作者Shubham Patel