不能。go 的 recover 仅对同 goroutine 中 defer 内调用且由 panic 触发的场景生效；哈希计算本身不因空数据 panic，但对 nil *hash.hash 调用 write 或在已关闭哈希对象上调用方法会 panic。
recover 能捕获哈希计算时的 panic 吗？
不能直接捕获。Go 的 recover 只对当前 goroutine 中由 panic 触发的、且在 defer 函数内调用的场景生效；而哈希计算（如 sha256.Sum256、hash.Hash.Write）本身不会因空数据 panic——它接受 nil 或空切片，返回正常结果。真正触发 panic 的常见原因是：对 nil 的 *hash.Hash 指针调用 Write，或在已关闭/重用的哈希对象上调用方法。
哪些哈希操作会真实 panic 并需要 recover？
典型可 panic 场景集中在指针误用和状态非法上，不是“空数据”本身：
-
var h hash.Hash; h.Write([]byte{})→h是nil，调用方法 panic：panic: runtime error: invalid memory address or nil pointer dereference - 重复调用
h.Sum(nil)后继续h.Write()（部分哈希实现不禁止，但标准库如sha256.digest在Sum后内部状态置为 closed，再Write会 panic） - 在已
reset()的哈希对象上误用未初始化字段（极少见，多见于自定义实现）
怎么安全地包裹哈希逻辑并 recover？
必须确保 recover 在同一 goroutine、同一函数的 defer 中，且 panic 发生在该函数调用栈内。下面是一个可运行的防护模式：
func safeHash(data []byte) (sum [32]byte, ok bool) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("哈希过程 panic: %v\n", r)
ok = false
}
}()
h := sha256.New() // 不要传 nil，也不要用未初始化的 *sha256.digest
h.Write(data) // data 为 nil 或 []byte{} 都合法
sum = h.Sum256()
ok = true
return
}
注意点：
- 必须用
sha256.New()等工厂函数获取实例，避免手动构造nil指针 - 不要把
h提取到外部作用域再传入，防止被意外置nil -
recover对协程间 panic 无效，若哈希逻辑跑在新 goroutine 里，recover完全不起作用
比 recover 更推荐的做法是什么？
主动防御远比事后 recover 可靠：
- 永远用
hash.NewXXX()创建对象，不用零值或显式nil指针 - 对输入参数做前置检查：
if data == nil { data = []byte{} }，消除歧义 - 避免复用哈希对象；每次计算新建实例（标准库哈希对象不保证并发安全，且状态易混乱）
- 若需高性能批量计算，用
sha256.Sum256(data)这类无状态函数，它根本不涉及指针或方法调用，不可能 panic
真正难防的是开发者自己绕过类型系统强行传 nil 或破坏哈希对象生命周期——这种问题用 recover 掩盖，反而会推迟暴露 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
