Go 用 chan T 模拟 Future：返回 channel 的函数即 Go 风格 future，支持阻塞等待、超时、select 多路复用，关闭 channel 表示完成；避免 WaitGroup+回调导致的嵌套、错误传递难和不可取消问题。
Go 里没有 Future，但可以用 chan 模拟出等效行为
Go 原生不提供 Future 或 Promise 类型，因为它的并发模型以 goroutine + channel 为核心。强行套用其他语言的 Future 接口（比如 Java 的 CompletableFuture）反而容易写出阻塞、泄漏或竞态代码。
真正实用的做法是：把异步计算封装成返回 chan T 的函数，调用方通过接收该 channel 获取结果 —— 这就是 Go 风格的 “future”。
-
chan T天然支持阻塞等待、超时控制、select 多路复用 - 避免手动管理状态（如
isDone、get()抛异常等），channel 关闭即代表完成 - 不要用
sync.WaitGroup+ 回调模拟 Future：回调嵌套深、错误传递麻烦、无法取消
func doAsync() 是最简可行的 Future 封装
一个典型的异步计算函数，返回只读 channel，内部启动 goroutine 执行耗时逻辑，并在完成后发送结果：
func fetchUserID() <-chan int {
ch := make(chan int, 1)
go func() {
defer close(ch) // 必须 close，否则 range/ch <- 会永久阻塞
id, err := callHTTPAPI() // 模拟网络请求
if err != nil {
// 错误怎么传？见下个副标题
return
}
ch <- id
}()
return ch
}- 返回类型用
<-chan T（只读 channel），防止调用方误写入 - channel 容量设为 1：避免 goroutine 启动后立刻阻塞在发送上（无缓冲 channel 要求接收方已就绪）
- 必须
defer close(ch)：否则接收方无法判断“已完成但无值”（比如失败退出） - 别在函数内直接
return <-ch：这会同步阻塞，失去异步意义
错误不能丢，chan error 或 chan Result 二选一
只用 chan T 无法区分“成功返回零值”和“出错没返回”，这是最常踩的坑。
立即学习“go语言免费学习笔记（深入）”；
- 方案一：返回两个 channel ——
func() (<-chan T, <-chan error)。简单，但调用方需自己select，易漏处理错误分支 - 方案二（推荐）：定义
type Result[T any] struct { Value T; Err error }，返回<-chan Result[int]。一次接收，语义清晰，错误必检 - 千万别用 panic 替代 error：goroutine 内 panic 不会传播到主流程，且 recover 成本高、难调试
示例：
type Result[T any] struct {
Value T
Err error
}
<p>func fetchUser() <-chan Result[User] {
ch := make(chan Result[User], 1)
go func() {
defer close(ch)
u, err := db.QueryUser(123)
ch <- Result[User]{Value: u, Err: err}
}()
return ch
}超时、取消、重试要靠 context.Context，不是靠 Future 自身
Go 的异步操作生命周期管理统一交给 context.Context，而不是让 Future 实现 cancel() 方法。所有可能阻塞的操作（HTTP、DB、channel receive）都应接受 ctx 参数。
- 启动 goroutine 前，用
ctx, cancel := context.WithTimeout(parent, 5*time.Second) - 在 goroutine 内部，用
select监听ctx.Done()，及时退出并关闭 channel - 调用方用
select等待结果或超时，而不是给 channel 加 timeout 包装器 - 不要自己实现带 cancel 的 Future 结构体：它会和 context 机制重复，且难以与标准库生态（如
http.Client）对齐
关键点：channel 是数据管道，context 是控制信号。混用二者（比如往 channel 发送 cancel 指令）会让逻辑分散、难以测试。
Future 模式在 Go 里本质是“如何安全地把 goroutine 的执行结果交出来”。重点不在接口长得像不像 Java，而在 channel 是否关闭、错误是否可判、context 是否生效 —— 这些细节漏掉一个，线上就可能卡死或 panic。
