应使用 errors.Is(err, context.DeadlineExceeded) 判断超时错误，因其可穿透包装、语义准确；不可用 == 或字符串匹配，且需区分 context.Canceled。
怎么判断错误是不是 context.DeadlineExceeded
Go 里超时错误不是字符串匹配，而是类型判断。直接用 == 比较错误值会失败，因为 context.DeadlineExceeded 是一个私有结构体变量，每次调用 context.WithTimeout 生成的错误不共享底层地址。
正确做法是用 errors.Is —— 它专门处理这种“错误是否属于某类”的场景：
if errors.Is(err, context.DeadlineExceeded) {
// 处理超时
}
- 别用
err == context.DeadlineExceeded：在 Go 1.13+ 中一定返回false - 别用
strings.Contains(err.Error(), "deadline")：依赖字符串易崩，且不同语言环境可能变 -
errors.Is能穿透多层包装（比如fmt.Errorf("wrap: %w", err)），errors.As不适用这里
为什么 context.DeadlineExceeded 和 context.Canceled 不能混用
它们语义完全不同：DeadlineExceeded 表示时间到了自动结束；Canceled 表示被主动取消（比如调用 cancel()）。虽然都导致 ctx.Err() 非空，但业务响应逻辑往往不同。
常见误操作是只检查 ctx.Err() != nil 就统一当超时处理，结果把用户主动中断当成服务超时上报，掩盖真实问题。
立即学习“go语言免费学习笔记（深入）”；
- 必须分开判断：
errors.Is(err, context.DeadlineExceeded)vserrors.Is(err, context.Canceled) - HTTP handler 中，超时通常返回
504 Gateway Timeout，而取消应返回499 Client Closed Request（如果支持）或静默丢弃 - 日志里务必打上具体错误类型，否则排查时无法区分是下游慢还是前端关了连接
在 http.Client 请求中捕获超时错误的典型陷阱
http.Client 自身的 Timeout 字段和 context 超时叠加时，错误来源容易混淆。实际报错可能是客户端超时、DNS 解析超时、TLS 握手超时，或 context 截断 —— 它们都可能表现为 context.DeadlineExceeded，但根因不同。
- 优先用
context控制请求生命周期，而不是设http.Client.Timeout：后者无法被外部 cancel，且与Do的 context 冲突 - 如果用了
http.DefaultClient，它的默认Timeout是 0（无限制），此时全靠 context 控制，务必确保传入的 context 有 deadline - 错误链里可能嵌套多个
net/http底层错误，仍要用errors.Is(err, context.DeadlineExceeded)，不要依赖err.(*url.Error).Err手动展开
自定义函数返回超时错误时，怎么让调用方能正确识别
如果你封装了一个带 context 的函数（比如 FetchData(ctx context.Context, url string) ([]byte, error)），它内部调用 http.Do 后直接返回原错误，那调用方能用 errors.Is 判断；但如果中间做了错误包装，就可能断掉这个链。
- 用
%w格式化错误：return nil, fmt.Errorf("fetch failed: %w", err)，这样errors.Is仍能穿透 - 避免用
%v或%s：比如fmt.Errorf("fetch failed: %v", err)会丢失原始错误引用 - 如果必须构造新错误（如脱敏），至少保留原始类型信息到字段里，再提供辅助方法，但不如直接用
%w简单可靠
最常被忽略的一点：超时错误只在 ctx.Err() 非空时才可能产生，但很多函数忘了在开头加 select { case 快速退出，导致即使超时了还在做无谓计算，错误延迟返回甚至压根不返回。
