用带缓冲的chan（容量1）模拟Future：启动goroutine计算后立即写入结果，结构体含error字段统一处理成败，接收方用val, ok :=读取，无需手动close。
用 chan 模拟 Future：最轻量、最 Go 的做法
Go 里没有原生 Future 或 Promise，但用带缓冲的 chan 就能实现等效行为——启动 goroutine 计算，结果通过 channel 返回。这不是“模拟”，而是 Go 推荐的并发模型落地方式。
常见错误是直接用无缓冲 chan 等待结果，导致调用方阻塞在发送端（goroutine 还没启完就试图写入），或忘记关闭 channel 导致接收方永远卡住。
- 始终用带缓冲的
chan（容量为 1）：make(chan Result, 1)，确保 goroutine 能立刻写入不阻塞 - 结果结构体建议包含
error字段，统一处理成功/失败路径 - 不要在 goroutine 外部手动
close()channel——接收方用val, ok := 判断是否已送达即可
type Result struct {
Data string
Err error
}
<p>func asyncCompute() <-chan Result {
ch := make(chan Result, 1)
go func() {
// 模拟耗时计算
data, err := heavyWork()
ch <- Result{Data: data, Err: err} // 缓冲 channel，不会阻塞
}()
return ch
}</p><p>// 使用
resCh := asyncCompute()
result := <-resCh // 阻塞直到结果就绪
if result.Err != nil {
log.Println("fail:", result.Err)
}
用 sync.WaitGroup + sync.Once 做延迟初始化型 Future
当“稍后获取结果”意味着多次读取同一份异步计算结果（比如配置加载、连接池初始化），不能每次 都触发新 goroutine。这时要的是「首次访问才计算，之后复用」，不是纯异步任务调度。
典型坑是只用 sync.Once 却忽略结果缓存，导致每次调用都得重新等待；或者用 WaitGroup 但没暴露等待接口，调用方无法感知完成状态。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
sync.Once负责保证初始化函数只执行一次 - 结果必须存在字段里（如
*Result或atomic.Value），不能仅靠 closure 捕获 - 提供
Get()方法：若未完成则阻塞等待；已完成则立即返回缓存值
type LazyFuture struct {
once sync.Once
mu sync.RWMutex
res *Result
err error
}
<p>func (f <em>LazyFuture) Get() (</em>Result, error) {
f.once.Do(f.compute)
f.mu.RLock()
defer f.mu.RUnlock()
return f.res, f.err
}</p><p>func (f *LazyFuture) compute() {
res, err := heavyWork()
f.mu.Lock()
f.res = &Result{Data: res}
f.err = err
f.mu.Unlock()
}
别碰 context.Context 里的 Done() 当作 Future 结果通道
ctx.Done() 只表示“该停了”，不是“算完了”。拿它当 Future 用，会导致逻辑错乱：超时或取消时你根本不知道计算是否成功、结果在哪、有没有部分写入 channel。
真实场景中，context 应该和 Future 协同，而不是替代它。比如给异步任务传入 ctx 实现可取消，但结果仍走独立 channel。
- 错误示范：
select { case —— 这不是获取结果，是放弃等待 - 正确组合：goroutine 内部监听
ctx.Done()主动退出，同时把中间结果或错误发到结果chan - 如果任务本身不可取消（比如纯 CPU 计算），
context只用于控制等待时长，不介入计算过程
第三方库 gofuture 或 futures 的实际价值很有限
这些库多数只是对 chan + sync.Once 做了封装，加了一层 Get()、IsDone() 方法。但 Go 生态里没人会为 Future 写单元测试，也不会 mock 它——因为它的行为就是 channel 行为。
引入依赖反而增加维护成本：比如 gofuture 的 Future.Get() 默认阻塞，但没提供带 context 的变体；某些版本 panic 在 nil channel 上；还有人误以为它支持链式调用（Then()），其实 Go 不支持协程链式语法糖。
- 除非团队强制统一 Future 接口（例如对接 Java 服务需保持语义一致），否则没必要用
- 真要抽象，自己写一个 20 行以内的
Future[T]类型更可控 - 泛型支持后，
type Future[T any] struct { ch chan Result[T] }就够用了，无需复杂继承树
事情说清了就结束。真正难的不是怎么写 Future，是怎么判断某个计算确实需要异步化——很多所谓“稍后获取”的场景，其实只是 IO 等待，用 net/http 默认 client 就行；而 CPU 密集型任务，Go 的 goroutine 并不加速，该上 runtime.LockOSThread 或扔给 worker pool 才是正解。
