用 context.WithTimeout 包装函数可实现超时控制，但必须在函数内部主动响应 ctx.Done() 或检查 ctx.Err()，否则 goroutine 泄漏；包装器应接收 timeout 参数并 defer cancel()，避免硬编码、误用 TODO() 或混用 panic 恢复。
用 context.WithTimeout 包一层就完事了
Go 里没有“装饰器”语法，但用 context 实现超时控制非常直接：把原函数包装成接受 context.Context 的版本，再用 context.WithTimeout 控制生命周期。核心不是加壳，而是让被调用逻辑主动响应取消信号。
常见错误是只传 context.WithTimeout 返回的 ctx，却忘了在函数内部检查 ctx.Err() 或用 select 等待它——超时后 goroutine 还在跑，内存和连接全 leaked。
- 所有阻塞操作（如
http.Client.Do、time.Sleep、channel receive）必须能接收ctx.Done() - 不要在包装器里启动新 goroutine 去等超时，除非你手动处理 cancel 后的清理
- 如果原函数不支持 context，得重写或用
sync.Once+ channel 模拟，但会丢失真正的可中断性
封装成高阶函数：返回函数的函数
所谓“通用包装器”，本质就是个接受 func(context.Context) error 并返回 func() error 的工厂函数。它不碰业务逻辑，只管超时和取消。
典型场景是给一堆无 context 参数的老接口统一加保护，比如数据库查询、第三方 HTTP 调用、本地文件读取。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
func WithTimeout(f func(context.Context) error, timeout time.Duration) func() error {
return func() error {
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()
return f(ctx)
}
}- 注意
cancel()必须 defer，否则超时前 panic 会导致 context 泄漏 - 别用
context.TODO()替代context.Background()，前者是占位符，不是默认值 - 如果原函数需要返回非 error 类型（比如
string），包装器就得改用泛型或返回interface{}，但会失去类型安全
超时时间传参还是硬编码？看调用方是否可控
硬编码 5 * time.Second 在工具函数里很危险——不同接口容忍度差十倍。真正通用的包装器应该把 timeout 当参数透传。
容易踩的坑是把 timeout 设得太短：DNS 解析、TLS 握手、慢网关都可能单独耗掉几百毫秒，而 context.WithTimeout 是从调用那一刻开始计时，不是从网络请求发出那一刻。
- 对外部服务调用，timeout 至少留出 1~2 秒缓冲；对本地计算类函数，100ms 足够
- 避免用
time.Now().Add(...)构造 deadline，必须用WithTimeout或WithDeadline，否则 cancel 机制失效 - 如果上层已有 context（比如 HTTP handler 的
r.Context()），别再套Background()，直接用context.WithTimeout(parent, ...)
panic、recover 和超时不能混着来
有人想在包装器里 recover() 捕获 panic 再假装是超时失败，这是错的。panic 不等于超时，且 recover 只对同 goroutine 有效——而 context.WithTimeout 触发的是父 goroutine 的 cancel()，子 goroutine 若没监听 ctx.Done()，它根本收不到任何信号。
真实问题常出现在：goroutine 启动后没等 ctx.Done() 就直接执行耗时操作，结果超时了，主流程返回了，但后台 goroutine 还在往已关闭的 channel 发数据，触发 panic。
- 超时控制和错误恢复是两层事：前者管资源生命周期，后者管程序健壮性
- 若必须处理 panic，应在最内层函数做，而不是指望包装器兜底
- 测试时用
time.Sleep(2 * timeout)配合select看是否真能及时退出，比单测返回值更关键
事情说清了就结束。超时不是加个 timer 就行，关键是让每层调用都参与协作——从 http.Client.Timeout 到自定义函数里的 select，漏一层，整个链路就不可控。
