Go语言单方法接口：函数实现与结构体实现的适用场景辨析

在Go语言中实现仅含单个方法的接口时，两种实现方式各有适用场景，核心差异在于状态需求、逻辑复杂度以及接口扩展性：

函数实现更优的场景 #

• 无状态的简单逻辑：当接口的实现不需要维护任何状态，只是单纯执行一段基础逻辑（比如简单日志打印、数据格式转换），函数实现更简洁。无需定义空结构体，直接通过适配器类型把现有函数转换成接口实例，减少冗余代码。
• 快速适配已有函数：如果已经存在签名匹配的函数，无需重新编写结构体方法，直接用适配器包装即可满足接口要求。比如示例中的LogOutput函数，只需一行LoggerAdapter(LogOutput)就能转换成Logger接口实例。
• 临时/动态逻辑场景：需要快速创建接口实例时，匿名函数（闭包）可以直接适配，无需提前定义结构体。比如动态添加日志前缀：

l := LoggerAdapter(func(msg string) {
    fmt.Printf("[DEBUG] %s\n", msg)
})

这种场景下，函数实现比结构体更灵活，省去了定义带前缀字段的结构体和对应方法的步骤。

结构体实现更合适的场景 #

• 需要维护可变状态：当实现逻辑需要保存可变状态（比如日志级别、输出文件句柄、缓存数据），结构体可以通过字段携带这些状态。例如：

type FileLogger struct {
    file  *os.File
    level string
}

func (fl *FileLogger) Log(msg string) {
    fl.file.WriteString(fmt.Sprintf("[%s] %s\n", fl.level, msg))
}

函数实现无法直接维护可变状态，闭包捕获的状态是固定的，无法动态修改。

• 接口存在扩展可能：如果未来接口可能新增方法（比如Logger接口后续添加Error、Warn方法），结构体实现只需新增对应方法即可兼容；而函数实现需要修改适配器类型，还要适配新的方法，改动成本更高，适应性更差。
• 复杂逻辑与代码组织：当实现逻辑复杂，需要拆分多个辅助逻辑时，结构体可以将相关方法绑定在一起，代码结构更清晰、职责更明确。比如日志实现需要格式化、过滤、输出等步骤，结构体可以定义私有辅助方法供Log方法调用，而函数实现很难组织这类复杂逻辑。
• 测试与Mock需求：结构体实现更便于编写Mock实例，比如测试时可以定义MockLogger结构体，通过字段记录调用次数、参数等信息，验证逻辑正确性；相比之下，函数实现的Mock依赖闭包，灵活性和可读性都不如结构体。

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