Go中全局变量的工作特点是什么，如何避免其不正确的初始化和启动时的竞争（初始化顺序）？典型的陷阱是什么？

答案。

在Go中，全局变量是按照文件的声明顺序和它们的init函数的调用顺序进行初始化的。这影响了对全局状态的正确访问：如果一个包中的变量依赖于另一个包中的变量的值，而该包尚未初始化，则会出现错误或不可预期的行为。

无法直接指定不同包的init函数之间的“启动顺序”。编译器根据导入图来确定这个顺序。

• 所有全局变量在调用main.main()函数之前被初始化。
• 不建议在package init期间进行过多依赖的状态初始化！
• 使用sync.Once或mutex来确保全局变量在复杂初始化中的线程安全。

安全的延迟初始化示例（lazy init）：

var cfg *Config
var once sync.Once

func GetConfig() *Config {
    once.Do(func() {
        cfg = LoadConfigFromDisk()
    })
    return cfg
}

---

诱导性问题。

问题：在Go程序启动时，不同包的init函数能否同时（并行）执行？

正确答案： 不，init函数和全局变量是严格按编译器在分析包之间的依赖关系时确定的顺序依次执行的。不会发生init函数的并行启动。

---

由于不熟悉主题细节而导致的实际错误示例。

---

故事

在一个大型项目中，几个模块通过init()从磁盘加载全局配置。一个模块依赖于另一个模块，但由于go.mod图的重构，初始化顺序发生了改变——结果配置值突然变为空！这个错误会随机出现，依赖于构建顺序，直到分析依赖关系并将初始化转移到显式函数后才找到。

---

故事

在一个REST服务中，用于缓存字典的全局map未使用mutex进行保护。初始化从几个在init中启动的goroutine开始。结果——数据竞争、周期性恐慌、map内无效数据。通过替换为sync.Once和显式调用初始化后，问题解决。

---

故事

全局日志记录器在一个辅助包的init函数中创建，但另一个包在启动时也在访问该日志记录器，在其初始化之前。最终，部分启动日志丢失，因为在日志记录器存在之前。这一解决方案是依赖注入和在所有服务启动之前显式初始化日志记录器。