何时该使用全局变量？

全局变量并非绝对禁忌，关键在于其作用域、可变性与复用场景：单程序内只读的全局配置（如类型映射表）是合理且安全的；但跨包可变全局状态会破坏封装性与可测试性，应优先通过结构体字段或依赖注入替代。

全局变量并非绝对禁忌，关键在于其作用域、可变性与复用场景：单程序内只读的全局配置（如类型映射表）是合理且安全的；但跨包可变全局状态会破坏封装性与可测试性，应优先通过结构体字段或依赖注入替代。

在 Go 开发中，“避免全局变量”是一条广为流传的最佳实践，但它的真实含义并非“禁止使用”，而是警惕副作用与隐式耦合。你的示例中定义了一个只读的 myTypes 映射：

var myTypes = map[string]string{
    "type1": "tpl1",
    "type2": "tpl2",
}

func AFunc(someType string) string {
    return fmt.Sprintf("this is your type %s", myTypes[someType])
}

这段代码在单程序、单包（如 main）且初始化后永不修改的前提下，完全合理——它本质上是一个常量配置，语义清晰、无并发风险、无需额外参数传递，反而提升了可读性与简洁性。

然而，若将此模式推广到可复用包中，则隐患显现。例如，设想一个第三方 renderer 包暴露了全局变量：

// ❌ 危险：跨导入污染
var DefaultTemplateMap = map[string]string{"html": "base.html"}

func Render(tplName string) string { /* 使用 DefaultTemplateMap */ }

当两个不同模块分别调用 renderer.Render(“html”) 并意外修改 DefaultTemplateMap 时，彼此行为将相互干扰，导致难以复现的竞态问题，且单元测试无法隔离——因为测试间共享同一全局状态。

✅ 更健壮、更可测试的替代方案是显式封装与依赖注入：

type Renderer struct {
    templates map[string]string
}

func NewRenderer(templates map[string]string) *Renderer {
    // 深拷贝或只读视图可选，确保内部不可变
    return &Renderer{templates: templates}
}

func (r *Renderer) Render(someType string) string {
    if tpl, ok := r.templates[someType]; ok {
        return fmt.Sprintf("this is your type %s", tpl)
    }
    return "unknown type"
}

// 使用方式（可轻松 Mock 或替换）
func main() {
    r := NewRenderer(map[string]string{
        "type1": "tpl1",
        "type2": "tpl2",
    })
    fmt.Println(r.Render("type1"))
}

这种设计带来三大优势：
? 可测试性：每个测试可创建独立 Renderer 实例，互不干扰；
? 可复用性：包使用者完全掌控配置，避免隐式依赖；
? 可扩展性：未来可轻松添加字段（如日志器、缓存策略）而不破坏 API。

总结：判断全局变量是否合理，请自问三个问题：
1️⃣ 它是否仅限于当前程序（非导出包）？
2️⃣ 它是否在初始化后绝对不可变（map/slice 需注意引用陷阱）？
3️⃣ 它是否被多个逻辑单元隐式共享并可能被修改？

满足前两条，即可放心使用；若涉及第三条，务必重构为结构体成员或函数参数——让依赖显式化，才是 Go 式清晰与可靠的根基。