channel不支持延迟加载，它仅是通信机制；延迟加载应使用sync.Lazy（Go 1.21+）或sync.Once实现，核心是按需初始化与状态缓存。
channel 本身不支持延迟加载，别被“管道”字面意思误导
很多人看到 channel 能阻塞 goroutine，就以为它能“延迟执行某段逻辑”，比如等某个资源初始化完再干活。但 channel 只是通信机制，它不负责初始化、不管理状态、也不自动触发函数调用。你往里塞一个值，或从里取一个值，仅此而已。所谓“延迟加载”，本质是「按需初始化 + 状态缓存」，这和 channel 的职责完全不重叠。
真正该用 sync.Lazy（Go 1.21+）或 sync.Once 实现延迟加载
Go 官方在 1.21 引入了 sync.Lazy，就是为了解决这个高频需求。它把初始化逻辑封装成一个零参数函数，首次访问时才执行，并保证只执行一次：
var expensive = sync.Lazy{Fn: func() any {
time.Sleep(100 * time.Millisecond) // 模拟耗时初始化
return &ExpensiveResource{}
}}
// 后续任意位置：
res := expensive.Load().(*ExpensiveResource)
如果你还在用 Go 1.20 或更早版本，就得手写 sync.Once + 指针字段：
- 字段必须是
*T类型（不能是值），否则Load()返回副本，无法共享状态 - 别在
init()函数里提前触发Load()，否则失去“延迟”意义 - 如果初始化函数可能 panic，
sync.Lazy会缓存 panic，后续调用直接 re-panic —— 这是设计行为，不是 bug
为什么有人误用 channel 做延迟加载？典型错误场景
常见反模式：开一个 goroutine 去初始化，用 channel 等结果返回。比如：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan *ExpensiveResource, 1)
go func() { ch <- newExpensive() }()
res := <-ch // 看似“延迟等到了”，实则隐患一堆
问题在于：
- 每次都要新建
channel和 goroutine，开销远大于sync.Lazy - 如果
newExpensive()失败（panic/return nil），就永久阻塞，没超时、没取消、没法重试 - 无法复用已初始化的结果 —— 下次还得走一遍 goroutine + channel 流程
- 若多个地方并发读
ch，谁先读到谁受益，其余人要么阻塞要么漏数据，根本不是“加载一次、全局可用”
channel 在延迟加载链路中唯一合理的位置：协调初始化完成信号
只有当延迟加载逻辑本身需要通知外部“我好了”，且接收方不关心加载结果内容（只关心时机），channel 才有存在价值。例如：
- 服务启动时，要等配置加载、DB 连接池 ready、Redis client 初始化完毕，才开始接受 HTTP 请求
- 这时可以用
done := make(chan struct{})，在所有初始化 goroutine 全部成功后close(done)，主 goroutine等待 - 注意：
channel这里只是“门禁开关”，不是“加载器”。真正的加载逻辑仍由sync.Lazy或显式函数承担
真正容易被忽略的是：延迟加载的边界必须清晰。如果一个结构体里混着 sync.Lazy 字段和普通字段，又没文档说明哪些字段是 lazy 的，后期维护者很可能在构造函数里就直接解引用，导致 panic。这点比选什么同步原语更重要。
