包级变量并发读写需手动加锁或原子操作，init函数执行顺序不可控，sync.pool不适用于长期持有对象，应优先采用显式初始化和懒加载。
包级别变量被多个 goroutine 同时读写会直接崩溃
Go 不会自动保护包级变量的并发访问。只要没加锁或没用原子操作，var counter int 这种变量在多 goroutine 中增减（比如 counter++）就是未定义行为——可能得到错误值、panic、甚至静默数据损坏。
常见错误现象：fatal error: concurrent map writes（对包级 map 直接写）、数值跳变、测试偶尔失败但本地复现困难。
- 所有包级变量默认无并发安全保证，无论类型是
int、string还是struct -
sync.Once只能保初始化一次，不能保后续读写安全 - 如果变量只读（初始化后不再改），比如
var cfg Config = loadConfig()，那没问题；但一旦有写入，就必须自己管
init 函数执行时机不可控，依赖顺序容易出错
多个文件中定义的 init() 函数，执行顺序由 Go 编译器按包内文件名排序决定，不是按 import 顺序，也不是按代码位置。你写的 init() 可能在依赖项的 init() 前或后运行，导致空指针或未初始化状态被使用。
典型场景：A 包里 init() 初始化一个全局 db *sql.DB，B 包在自己的 init() 里调用 A.GetDB().Query(...) —— 但 B 的 init() 先跑了，A.db 还是 nil。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
init()中调用其他包的函数，尤其那些也依赖init()的 - 避免跨包初始化耦合；把初始化逻辑下沉到显式函数（如
A.InitDB(...)），由 main 显式调用 - 如果必须用
init()，确保它只做纯内存操作（比如注册 handler、设置 flag 默认值），不依赖外部状态
sync.Pool 不适合长期持有包级对象
有人想用 sync.Pool 缓存包级资源（比如 bytes.Buffer 或自定义结构体）来“避免重复分配”，但 sync.Pool 的对象可能被任意时候回收（GC 时、空闲超时），并不保证存活。拿它当长期持有的包级变量，等于埋雷。
错误用法：var bufPool = sync.Pool{New: func() interface{} { return &bytes.Buffer{} }} 然后在 HTTP handler 里 b := bufPool.Get().(*bytes.Buffer) —— 看似省分配，但若中间有 GC，bufPool 里对象全被清空，下次 Get() 返回新对象没问题；可要是你在 init() 里预热塞了几个进去，又假设它们永远存在，就错了。
-
sync.Pool是为短期、高频、可丢弃的临时对象设计的，不是对象池管理器 - 包级
sync.Pool可以用，但别依赖其中对象的生命周期；每次Get()后要重置状态（如b.Reset()） - 长期资源（数据库连接、配置对象、单例服务）该用显式初始化 + 懒加载就用那个，别塞进
sync.Pool
替代方案：用函数封装 + 显式初始化更可控
比起靠 init() 和裸全局变量硬扛，并发和初始化问题都更容易通过“延迟创建 + 显式控制”解决。Go 标准库很多地方也是这么做的（比如 http.DefaultClient 是变量，但真正初始化在网络请求时才发生）。
实操建议：
- 把包级变量改成私有（小写开头），提供
NewXXX()或MustXXX()函数返回实例 - 需要单例？用
sync.Once+ 指针变量，在函数内部做懒初始化，而不是在包级做 - 需要并发读写？把锁（
sync.RWMutex）或原子类型（atomic.Int64）作为字段封装进结构体，而不是裸露全局变量 - main 函数第一行就做关键初始化（比如
log.SetFlags(...)、db, _ = sql.Open(...)），比散落在各处的init()更易追踪
复杂点从来不在语法，而在谁在什么时候、以什么顺序、带着什么状态去碰那个变量。盯住初始化链和 goroutine 边界，比背规则有用得多。
