Go 的 goroutine 一旦在 channel 接收、网络 Read 或数据库查询上阻塞，如果没有外界干预，它可能一直等下去。很多项目里出现的内存泄漏和响应延迟，归根到底都是有 goroutine 卡在某个不会返回的调用上。给这些操作加超时，不能只在外层加一个定时器然后继续往下走，因为被阻塞的 goroutine 并不会因为外层返回而自动结束。
要理解这一点，需要先分清两种阻塞：一类是 channel 收发，一类是系统调用或网络 IO。对于 channel，select 可以同时监听数据和定时器；对于网络 IO，select 无法直接接管，只能依赖连接对象提供的 SetDeadline 或 Close 方法。安全的超时机制通常由两个部分组成：context 负责传递取消信号，具体阻塞操作负责响应这个信号。下面先从一个直观的反面例子说起。
为什么外层定时器不能真正中断阻塞
很多开发者的第一反应是用 time.After 加 select 来等待一个结果。这个模式对 channel 接收有效，因为它把等待数据和等待超时放在同一个 select 里，任何一个先就绪就会返回。但问题在于，select 只能阻塞在它自己的 case 上，它没有办法打断另一个 goroutine 正在执行的阻塞调用。比如某个 goroutine 正在执行 conn.Read，主 goroutine 的 select 即使超时返回，那个 conn.Read 还在原地等待。如果返回后不再引用那个 goroutine，它就会变成一个无人管理的泄漏。
还有一种更隐蔽的情况是 channel 发送阻塞。一个 goroutine 试图向无缓冲 channel 发送结果，但接收方已经超时退出，那么这个发送会永远阻塞。下面的代码模拟了这种场景：blockingWork 需要 10 秒才能返回，select 在 2 秒后超时，但 blockingWork 的 goroutine 并没有被通知停止，最终会卡在 result 发送上。运行这段代码后，程序主流程虽然退出，但 goroutine 还在，这就是典型的资源泄漏。
package main
import (
"fmt"
"time"
)
func blockingWork(result chan<- string) {
// 模拟一个不受控的阻塞操作
time.Sleep(10 * time.Second)
result <- "done"
}
func main() {
result := make(chan string)
go blockingWork(result)
select {
case res := <-result:
fmt.Println(res)
case <-time.After(2 * time.Second):
fmt.Println("timeout")
}
// 2 秒后返回，但 blockingWork 的 goroutine 仍然在 sleep，10 秒后向 result 发送数据
// 由于没有接收者，会阻塞在 result <- "done"，goroutine 泄漏
}
要解决这个问题，需要让被调用的 goroutine 自己也能感知取消。也就是说，不能只让调用方 select 超时，还要把取消信号传递给执行阻塞操作的那一方。这是 context 包要解决的核心问题。接下来看如何用 context 和 select 把阻塞点改造成可取消的。
用 context 与 select 改造 channel 阻塞调用
context.WithTimeout 会返回一个 ctx 和一个 cancel 函数。ctx.Done() 返回一个 channel，当超时到达或 cancel 被调用时，这个 channel 会被关闭。对于原本阻塞在 channel 接收的 goroutine，可以把接收操作放进 select，同时监听 ctx.Done()。这样只要取消信号一到达，接收方就能立刻返回，不再继续等待。下面的 receiveWithTimeout 函数封装了这个模式。当 ctx 取消时，它返回 ctx.Err()，否则返回接收到的数据。
package main
import (
"context"
"fmt"
"time"
)
func receiveWithTimeout(ctx context.Context, ch <-chan int) (int, error) {
select {
case v := <-ch:
return v, nil
case <-ctx.Done():
return 0, ctx.Err()
}
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
ch := make(chan int)
go func() {
time.Sleep(5 * time.Second)
ch <- 42 // 如果超时已经返回，这里会阻塞；要避免泄漏需要配合 select 处理发送
}()
v, err := receiveWithTimeout(ctx, ch)
if err != nil {
fmt.Println("failed:", err)
return
}
fmt.Println("got:", v)
}
不过光有接收方的 select 还不够。如果发送方持续在 ch <- 42 上阻塞，接收方超时返回后发送方仍然会卡住。要避免这种泄漏，发送方也必须监听 ctx.Done()。我们可以把发送动作写成一个 sendWithCancel 函数，让它在发送和取消之间做 select。只要 ctx 被取消，发送方就不再执行发送。配合带缓冲 channel 使用效果更好，因为发送方不会因为接收方已经离开而永久阻塞。
这里有一个细节需要注意：select 的多个 case 都满足时，Go 会随机选择。因此在取消信号和发送条件同时满足的瞬间，sendWithCancel 有可能还是执行了发送。如果业务上要求严格不发送，需要在发送前再次检查 ctx.Err()，或者把 channel 的缓冲和关闭语义设计成幂等。对于大多数场景，只要保证 goroutine 最终退出，偶尔多发送一个值到带缓冲 channel 是可以接受的。但必须保证这个发送不会阻塞，所以通常使用容量为 1 的缓冲 channel，或者发送方自己再套一层 select 处理阻塞。
网络 IO 与数据库查询的超时落地
channel 操作可以被 select 直接管理，但网络 IO 不是 channel，select 无法监听一次 conn.Read 是否返回。要让一个阻塞在网络读取上的 goroutine 响应取消，需要借助 net.Conn 的 SetReadDeadline 或 SetDeadline。这些方法会给底层连接设置一个绝对截止时间，一旦到达，正在进行的 Read 或 Write 会立即返回一个超时错误。因此，当 context 取消时，我们可以在另一个 goroutine 中调用 conn.SetDeadline(time.Now())，强制让阻塞读立刻结束。
一个常见的模式是启动一个辅助 goroutine 执行真正的 Read，主 goroutine 用 select 同时等待读取完成和 ctx.Done()。如果 ctx 先触发，主 goroutine 调用 SetDeadline 打断读取，再等待辅助 goroutine 退出。这样可以确保不会留下一个还阻塞在 Read 上的 goroutine。下面给出一个 TCP 读取的示例，注意示例中的地址只是演示，实际使用时请替换成真实服务地址。
package main
import (
"context"
"fmt"
"net"
"time"
)
func readWithContext(ctx context.Context, conn net.Conn, buf []byte) (int, error) {
done := make(chan struct{})
var n int
var readErr error
go func() {
n, readErr = conn.Read(buf)
close(done)
}()
select {
case <-done:
return n, readErr
case <-ctx.Done():
// 通过设置截止时间来打断阻塞的 Read
_ = conn.SetDeadline(time.Now())
<-done // 等待读取 goroutine 退出
return 0, ctx.Err()
}
}
func main() {
conn, _ := net.Dial("tcp", "ipipp.com:80")
defer conn.Close()
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
buf := make([]byte, 1024)
n, err := readWithContext(ctx, conn, buf)
fmt.Println(n, err)
}
HTTP 客户端方面，net/http 已经原生支持 context。http.NewRequestWithContext 创建的请求会在 context 取消时自动关闭底层连接并返回错误。在服务端 handler 里，可以通过 request.Context() 判断客户端是否已经断开连接，从而提前停止耗时计算。数据库查询也一样，database/sql 的 QueryContext、ExecContext 都会把 context 传递给驱动。驱动如果支持取消，会向数据库发送取消命令或关闭连接；如果不支持，database/sql 会等待查询结束后再返回，但 ctx 取消后的结果会被丢弃。所以选择驱动时最好确认它对 context 的支持程度。
区分超时与主动取消，避免泄漏
context 取消的原因有两种：一种是 DeadlineExceeded，表示超时；另一种是 Canceled，表示主动调用了 cancel。业务代码不要把两者混为一谈。比如在记录日志或返回错误码时，可以用 errors.Is(err, context.DeadlineExceeded) 判断是否超时，用 errors.Is(err, context.Canceled) 判断是否被主动取消。很多系统会对超时和主动取消做不同处理，比如超时可能需要告警，而主动取消只是正常流程。
另一个常见的坑是没有及时调用 cancel。context.WithTimeout 内部会创建一个 timer，如果不调用 cancel，timer 会一直保留到超时才被释放。在高并发下，大量未释放的 timer 会增加运行时开销。因此应该养成 defer cancel() 的习惯。同时，父 goroutine 返回后子 goroutine 如果还在运行，需要注意 context 的传播：如果父 goroutine 没有把 cancel 传给子 goroutine，子 goroutine 可能永远收不到取消信号。cancel 函数的作用域必须覆盖所有需要被取消的 goroutine。
对于 channel 发送方，可以统一使用 sendWithCancel 模式；对于网络读取，使用 SetDeadline 打断；对于数据库和 HTTP，使用支持 context 的 API。这样就能把超时和取消从调用方一直延伸到最底层的阻塞点。最后还要提醒，即便 context 已经取消，也不要假设阻塞操作会立刻返回，有些系统调用或驱动实现会有延迟，因此在取消后如果还需要回收资源，最好等待辅助 goroutine 通过 done channel 确认退出后再继续。
package main
import (
"context"
"fmt"
"time"
)
func sendWithCancel(ctx context.Context, ch chan int, value int) bool {
select {
case ch <- value:
return true
case <-ctx.Done():
return false
}
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
ch := make(chan int, 1)
go func() {
time.Sleep(3 * time.Second)
sendWithCancel(ctx, ch, 42)
}()
select {
case v := <-ch:
fmt.Println("received:", v)
case <-ctx.Done():
fmt.Println("timeout or canceled:", ctx.Err())
}
}
总结一下，Go 里安全为阻塞操作设置超时并实现取消，核心不在于给每个函数套一层 select，而在于把取消信号传递到最接近阻塞的位置。channel 操作用 select 监听 ctx.Done()，网络 IO 用 SetDeadline 打断，数据库和 HTTP 使用原生支持 context 的 API。配合 defer cancel()、发送方同步监听取消、等待辅助 goroutine 退出，可以最大程度避免 goroutine 泄漏和资源占用。这套组合模式可以复用到大多数并发场景中。
Go超时控制context包goroutine取消修改时间：2026-09-23 21:39:30