Go中无语言级异步抽象，异步调用需手动用goroutine+channel实现，须管理生命周期、错误传递、超时取消及资源清理。
Go 里没有“异步调用”这个概念，只有 goroutine + channel 的协作模型
Go 不像 JavaScript 有 async/await，也不像 Python 有 asyncio，它压根不提供语言级的“异步 I/O 抽象”。所谓“异步调用”，在 Go 中实际是：启动一个 goroutine 去执行耗时操作（比如 HTTP 请求、文件读写、数据库查询），再通过 channel 或回调函数把结果传回来。关键在于——你得自己管理生命周期和错误传递。
常见误操作包括：
- 启动
goroutine后完全不管，导致 panic 没人 recover、资源没释放 - 用无缓冲
channel等待结果，但主 goroutine 已退出，造成死锁 - 把阻塞操作（如
time.Sleep）直接扔进 goroutine 就以为是“异步”，却忽略了上下文取消和超时控制
用 goroutine + channel 实现带超时和取消的 HTTP 异步请求
这是最典型的异步场景：发起一个 HTTP 请求，不阻塞主线程，同时支持超时和主动取消。核心是组合 context.WithTimeout 或 context.WithCancel 与 http.Client 的 Do 方法。
实操要点：
-
http.Client必须设置Timeout字段或传入带 deadline 的context.Context，否则底层连接可能永远挂起 - 不要用
http.Get这类快捷函数——它们不接受context，无法取消 - 结果 channel 应为带缓冲的（如
make(chan result, 1)），避免 goroutine 因发送阻塞而泄漏
type result struct {
data []byte
err error
}
<p>func asyncHTTPGet(ctx context.Context, url string) <-chan result {
ch := make(chan result, 1)
go func() {
defer close(ch)
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
ch <- result{err: err}
return
}
defer resp.Body.Close()
data, err := io.ReadAll(resp.Body)
ch <- result{data: data, err: err}
}()
return ch
}别用 select 盲等 channel，要配合 context.Done()
很多初学者写异步等待逻辑时，只写 select { case r := <-ch: ... }，这会永久阻塞。真实服务中必须响应取消或超时。
正确做法是始终把 <-ctx.Done() 放进 select 分支，并检查 ctx.Err() 类型来区分是超时还是被取消：
-
ctx.Err() == context.DeadlineExceeded→ 超时 -
ctx.Err() == context.Canceled→ 被显式取消（如父 goroutine 退出） - 收到结果后，记得用
default或select非阻塞方式清空 channel，防止后续 goroutine 发送卡住
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>ch := asyncHTTPGet(ctx, "<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>")
select {
case r := <-ch:
if r.err != nil {
log.Printf("request failed: %v", r.err)
} else {
log.Printf("got %d bytes", len(r.data))
}
case <-ctx.Done():
log.Printf("request canceled: %v", ctx.Err())
}并发任务编排：用 sync.WaitGroup 还是 errgroup.Group？
批量发起多个异步请求并等待全部完成时，sync.WaitGroup 是基础方案，但它不处理错误传播和上下文取消。生产环境更推荐 golang.org/x/sync/errgroup。
差异点很实在：
-
errgroup.Group自动继承传入的context.Context，任意子 goroutine 返回错误或上下文取消，其余任务会自动中止 - 它只返回第一个非
nil错误，适合“任一失败即整体失败”的场景（如事务型调用） - 如果需要收集所有错误，就得自己用
sync.Mutex+ 切片存错，errgroup不负责这个
g, ctx := errgroup.WithContext(context.Background())
urls := []string{"https://a.com", "https://b.com", "https://c.com"}
<p>for <em>, url := range urls {
url := url // 避免循环变量捕获
g.Go(func() error {
resp, err := http.DefaultClient.Get(url)
if err != nil {
return err
}
defer resp.Body.Close()
</em>, err = io.Copy(io.Discard, resp.Body)
return err
})
}</p><p>if err := g.Wait(); err != nil {
log.Printf("one request failed: %v", err)
}真正难的不是启动 goroutine，而是决定什么时候停、怎么清理、错误要不要重试、失败了是否影响其他流程。这些逻辑不会自动发生，得一行行写进去。
