Go中判断错误是否临时应优先检查Temporary()方法，需通过类型断言安全调用；net.Error的Timeout()和Temporary()均true才真正可重试；context.DeadlineExceeded不可重试；自定义错误须显式实现Temporary()。
怎么判断一个 Go 错误是临时的还是永久的
Go 里没有统一的“临时错误”类型，但标准库用 net.Error 和 os.PathError 等实现了 Temporary() 方法，这是最常见、最可靠的判断入口。别依赖错误字符串匹配或自定义字段，那容易漏判或误判。
实际场景中，临时错误多出现在网络连接、DNS 解析、I/O 超时等可重试环节；永久错误则是路径不存在、权限拒绝、协议不支持等无法靠重试解决的问题。
-
net.Error是最典型的临时错误接口，Timeout()和Temporary()都返回true才算真正可重试（比如net.OpError） -
os.PathError的Temporary()永远返回false，哪怕底层是ENOTCONN—— 它只表示路径层面失败，不反映连接状态 - 第三方库如
database/sql的sql.ErrNoRows不实现Temporary()，但它也不是永久性故障，属于业务逻辑正常分支，别拿它当重试依据
为什么直接断言 Temporary() 方法会 panic
因为不是所有错误都实现了该方法。Go 的接口断言要求类型**明确实现**，而像 fmt.Errorf("xxx") 或 errors.New("xxx") 返回的错误值，压根没实现 Temporary()，直接调用会触发 panic。
正确做法永远是类型断言 + 安全调用，而不是先假设存在再调用：
立即学习“go语言免费学习笔记（深入）”；
if tempErr, ok := err.(interface{ Temporary() bool }); ok && tempErr.Temporary() {
// 可重试
}
注意：不要写成 err.(net.Error).Temporary() —— 如果 err 不是 net.Error 类型，这行就 panic。
context.DeadlineExceeded 算不算临时错误
不算。它是 context 包返回的不可恢复错误，类型是 *url.Error 或纯 error，不实现 Temporary()，也不应被重试。它代表调用方主动终止，不是底层系统暂时不可用。
常见混淆点：
-
context.DeadlineExceeded和net/http中的Client.Timeout触发的net/url.Error是两回事：后者可能包装了net.OpError，才可能临时 - HTTP 请求超时若由底层 TCP 连接中断导致（如
read: connection reset by peer），错误链里可能含net.OpError，这时才值得检查Temporary() - 单纯 context 超时，重试只会更快失败，还可能放大上游压力
自己封装错误时如何支持 Temporary()
如果你在写客户端库或封装底层调用，想让使用者能安全判断临时性，就让自定义错误类型显式实现 Temporary() bool 方法。别靠嵌套或转发——必须自己声明实现。
示例：
type MyClientError struct {
Err error
IsTemp bool
}
func (e *MyClientError) Error() string { return e.Err.Error() }
func (e *MyClientError) Temporary() bool { return e.IsTemp }
关键点：
- 不要把
Temporary()实现成 “只要底层错误有这个方法就返回 true”，得结合语义：比如你封装的是幂等查询，即使底层报了Temporary()，你也可能选择不重试（因业务已保证最终一致） - 如果错误来自
net.Error，建议透传其Temporary()结果；如果是新错误（如配置校验失败），一律返回false - 别在
Temporary()里做耗时操作或加锁，它会被高频调用
临时错误判断真正难的不是语法，而是理解错误来源和重试边界——同一错误在不同上下文里，临时性可能完全不同。比如 connection refused 在服务启动初期是临时的，在运维下线后就是永久的。代码只能告诉你“能重试”，不能替你决定“该不该重试”。
