本文揭示 Go 程序因 init() 函数内 goroutine 过早访问未初始化全局变量（如 *sql.DB）导致的 Windows/Linux 行为差异，本质是竞态条件（race condition），并提供线程安全的初始化方案。
本文揭示 go 程序因 `init()` 函数内 goroutine 过早访问未初始化全局变量（如 `*sql.db`）导致的 windows/linux 行为差异，本质是竞态条件（race condition），并提供线程安全的初始化方案。
Go 的 init() 函数按包依赖顺序执行，但其中启动的 goroutine 会立即脱离主线程调度——这正是问题根源。在您的代码中：
func init() {
go feedChan() // ⚠️ 此时 db 尚未赋值！
connString := os.Getenv("DB_CONN")
var err error
db, err = sql.Open("postgres", connString) // ← db 在此处才被初始化
// ...
}feedChan() 在 db 赋值前就已并发执行，尝试调用 db.Prepare(...)，必然触发 nil pointer dereference。Linux 下“看似工作”并非正确，而是侥幸：
- Go 调度器在不同 OS 上的实现细节（如 goroutine 启动延迟、M:N 调度策略微调）存在差异；
- Linux 内核调度器可能使主线程更快完成
sql.Open和db.Ping()，而 Windows 调度更早将 CPU 时间片分配给feedChangoroutine； - 这属于典型的 非确定性竞态（non-deterministic race） —— 依赖调度时机，而非逻辑正确性。
验证方法很简单：在 go feedChan() 后插入 time.Sleep(100 * time.Millisecond)，多数情况下 Linux 也会复现 panic；反之，在 Windows 上加长 sleep 可能“暂时修复”，但这绝非解决方案。
✅ 正确做法是显式同步初始化顺序。推荐两种生产级方案：
方案一：前置初始化（最简洁）
确保 db 初始化完成后再启动依赖它的 goroutine：
func init() {
connString := os.Getenv("DB_CONN")
var err error
db, err = sql.Open("postgres", connString)
if err != nil {
log.Fatalf("Failed to connect to database: %v", err)
}
if err = db.Ping(); err != nil {
log.Fatalf("Database ping failed: %v", err)
}
// ✅ 此时 db 已就绪，再启动 goroutine
go feedChan()
}方案二：通道屏障（barrier）控制（适合复杂依赖链）
使用无缓冲 channel 实现 goroutine 启动阻塞：
func init() {
barrier := make(chan struct{}) // 更语义化：struct{} 零内存开销
go feedChan(barrier)
connString := os.Getenv("DB_CONN")
var err error
db, err = sql.Open("postgres", connString)
if err != nil {
log.Fatalf("Failed to connect to database: %v", err)
}
if err = db.Ping(); err != nil {
log.Fatalf("Database ping failed: %v", err)
}
close(barrier) // 或 barrier <- struct{}{}，此处 close 更清晰表达“初始化完成”
}
func feedChan(barrier <-chan struct{}) {
<-barrier // 阻塞直到 barrier 关闭（即 db 初始化完毕）
selectQuery, err := db.Prepare(`
SELECT id, proxy
FROM proxy
WHERE fail_count < 2
ORDER BY date_added DESC, last_used ASC, fail_count ASC
LIMIT 5
`)
if err != nil {
log.Fatalf("Failed to prepare query: %v", err)
}
// ... 后续逻辑
}⚠️ 注意事项：
- 绝对避免在
init()中启动 goroutine 后直接访问尚未初始化的全局变量； - 使用
go run -race检测竞态（本例会明确报告data race on db）； -
sql.Open返回的是连接池句柄，不保证立即连通，务必调用db.Ping()校验； -
init()函数应保持幂等与快速，复杂初始化逻辑建议移至main()或专用初始化函数。
归根结底，跨平台行为差异不是 Go 的 bug，而是竞态暴露的“时间窗口”在不同系统上表现不同。可靠程序必须消除竞态，而非依赖调度巧合。
