go不支持future/promise，应使用chan+goroutine组合实现异步任务：返回只读channel作为结果句柄，调用方通过接收channel获取结果，天然支持select且更轻量。
Go 里没有 Future 或 Promise，别硬套概念
Go 的并发模型不走回调链或状态机那一套，Future 和 Promise 在 Go 中既无标准库支持，也不符合惯用法。强行封装一层“类 Promise”对象，往往带来额外 goroutine、channel 管理负担和状态同步问题，反而掩盖了 Go 原生并发的清晰性。
真正要解决的，是「异步启动任务、稍后取结果」这个需求。Go 的答案很直接：用 chan + goroutine 组合，配合结构体封装，就能干净实现等效行为。
用 chan 实现最简 Future：只读通道即结果句柄
核心思路是把结果塞进一个只读 channel，调用方通过接收该 channel 获取结果（阻塞或带超时）。这比返回 struct + Wait() 方法更轻量，也天然支持 select。
func DoAsync() ：返回 <code>，调用方无法关闭或写入，语义明确- 内部启动 goroutine 执行耗时操作，完成后往 channel 发送结果（或错误）
- 如果需要区分成功/失败，建议发送
struct{ v T; err error }，避免多 channel 同步难题 - 不要在函数内 close(channel)，除非明确约定“零值可作结束信号”，否则容易触发 panic: send on closed channel
<pre class="brush:php;toolbar:false;">func FetchUser(id int) <-chan struct{ user User; err error } {
ch := make(chan struct{ User; error }, 1)
go func() {
u, err := db.GetUser(id) // 模拟 IO
ch <- struct{ User; error }{u, err}
}()
return ch
}
<p>// 使用
result := FetchUser(123)
select {
case r := <-result:
if r.err != nil {
log.Println("fail:", r.err)
} else {
fmt.Printf("got: %+v", r.user)
}
case <-time.After(3 * time.Second):
log.Println("timeout")
}</p>为什么不用第三方 promise 库？
社区确实有类似 gofuture、go-promise 的包，但它们普遍存在几个现实问题：
立即学习“go语言免费学习笔记（深入）”；
- 多数依赖反射或 interface{}，丢失类型安全，编译期无法检查字段访问
- 为支持
.Then()链式调用，隐式启动新 goroutine，导致调度不可控、panic 传播路径变长 - 与
context.Context集成差，超时/取消需额外包装，而原生chan+select天然兼容 - 当你要组合多个异步操作（比如 allSettled / race），手写
sync.WaitGroup+chan反而更直观、内存占用更低
复杂场景下：用结构体封装 + Wait() 是可行折中
如果你必须复用同一个异步结果多次（比如多次调用 Get()），或者需要主动轮询状态（如 UI 更新进度），这时返回 channel 就不够用了。可以定义一个轻量结构体：
<pre class="brush:php;toolbar:false;">type Future[T any] struct {
mu sync.RWMutex
val *T
err error
ready bool
once sync.Once
fn func() (T, error)
}
<p>func (f <em>Future[T]) Get() (T, error) {
f.once.Do(func() {
v, err := f.fn()
f.mu.Lock()
f.val, f.err, f.ready = &v, err, true
f.mu.Unlock()
})
f.mu.RLock()
defer f.mu.RUnlock()
if !f.ready {
var zero T
return zero, errors.New("not ready")
}
return </em>f.val, f.err
}</p>注意点：
once.Do 保证初始化只执行一次，避免重复 IO 或计算- 不要在
Get()内部加超时逻辑——那是调用方的事；Future 本身只负责“最多算一次” - 如果
fn可能阻塞很久，建议让调用方传入context.Context并在fn内部处理取消，而不是在 Future 层做 context 绑定
真正难处理的，是结果依赖另一个 Future 的场景（比如 Promise.then(nested)）。这时候别嵌套 Future，改用两个 goroutine + channel 管道更可控——Go 不鼓励“异步套异步”的表达方式，它更希望你把控制流摊平。
