将函数赋值给Go包级变量是否为反模式？即便利于单元测试

你在开发Go微服务时，通过将依赖函数赋值给包级全局变量来方便单元测试模拟的做法，是Go生态里常见的测试友好方案，下面针对你的疑问逐一说明：

示例代码回顾 #

业务代码：

package mycode

import identityLibrary

var credentialFunc = identityLibrary.NewCredential

func myLogic() {
    // ...
    credential := credentialFunc()
    // ...
}

单元测试代码：

func myTest(t *testing.T) {
    originalCredFunc := credentialFunc
    defer func() {
        credentialFunc = originalCredFunc
    }() // 注意需加()执行defer函数，才能确保测试后恢复原函数

    credentialFunc = func() error { // 需与原函数返回类型匹配，此处假设返回error
        return errors.New("mock error")
    }

    err := myLogic()
    
    if err == nil {
        t.Error("Expected error, got nil")
    }
}

1. 是否属于反模式？ #

仅在测试中修改、业务逻辑里不触碰这个全局变量的前提下，这不算典型反模式。Go语言没有其他语言那样便捷的原生mock方式，这种做法是平衡代码简洁性和测试可维护性的折中方案。但要严格约束：业务代码绝对不能修改这个变量，否则会引入并发安全风险（多个goroutine同时修改函数指针会导致不可预期的行为）。

2. 仅测试中重赋值是否可行？ #

完全可行，但要注意两个关键点：

• 测试并发安全：Go的go test默认会并行执行测试用例，如果多个测试都修改同一个包级变量，必须像示例里那样用defer在测试结束后恢复原值，避免测试用例之间互相干扰。
• 代码可读性：建议给这个包级变量加注释，明确标注“仅用于单元测试模拟，业务代码禁止修改”，避免其他开发者误操作。

3. 大规模场景下的性能问题？ #

• 单例问题：这个变量是函数指针，不是实例本身。每次调用credentialFunc()都会执行原函数（或mock函数）生成新实例，除非identityLibrary.NewCredential本身是单例实现，否则不会因为这个包级变量导致单例。
• 性能开销：函数指针调用的性能损耗可以忽略不计，Go编译器会对这种间接调用做优化，和直接调用函数的性能几乎无差别。真正影响性能的是credentialFunc()指向的函数本身的逻辑，和是否用包级变量存储无关。

可选优化方向 #

如果觉得包级全局变量不够优雅，可以考虑：

• 依赖注入：把函数作为参数传入myLogic，但会增加函数参数的复杂度，适合依赖较多的场景。
• 接口封装：定义CredentialCreator接口，业务代码依赖接口，测试时传入mock实现。这种方式更符合依赖倒置原则，但对于简单的函数调用，包级变量的方式更简洁。

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