Base64 解码本身不会 panic，只返回 error；真正 panic 来自忽略该 error 后对 nil 或非法切片的误用，因此应优先检查解码错误而非依赖 recover。
recover 不能处理 Base64 解码截断引发的恐慌——因为 Base64 解码本身 不会 panic，它只返回错误。
你遇到的“崩溃”，大概率是后续代码在未检查 base64.StdEncoding.DecodeString() 返回的 error 时，直接用了解码失败得到的 []byte{}（比如传给 json.Unmarshal、强制类型断言、或当作非空切片访问索引），才真正触发了 panic（如 index out of range 或 invalid memory address）。
所以问题本质不是“recover 怎么捕获 Base64 解码 panic”，而是：如何避免因忽略解码错误导致的下游 panic，并在必要时用 recover 做兜底。
base64.DecodeString 从不 panic，只返回 error
base64.StdEncoding.DecodeString() 和 base64.URLEncoding.DecodeString() 的行为非常明确：
立即学习“go语言免费学习笔记（深入）”；
- 输入合法：返回解码后的
[]byte和nil - 输入非法（如长度非 4 倍数、含非法字符、填充过多/过少）：返回
nil和非nil的error（通常是encoding/base64.CorruptInputError） - 它永远不会触发运行时 panic
你可以放心地写：
decoded, err := base64.StdEncoding.DecodeString("SGVsbG8=")
if err != nil {
// 处理解码失败，比如返回 HTTP 400
return fmt.Errorf("invalid base64: %w", err)
}
// 此时 decoded 是安全可用的
如果跳过 err != nil 检查，却对 decoded 做 decoded[0] 或 json.Unmarshal(decoded, &v)，那 panic 就发生在那行，和 Base64 无关。
真正需要 recover 的场景：你主动让解码后数据“出事”了
比如你在解析 Base64 后的 JSON 时没校验长度，直接解包：
func handleRequest(data string) {
decoded, _ := base64.StdEncoding.DecodeString(data) // ❌ 忽略 err
var payload struct{ ID int }
json.Unmarshal(decoded, &payload) // ✅ 这里可能 panic：decoded 是 nil → 传给 json 包导致 panic
}
这种情况下，recover 可以兜住，但属于设计缺陷的补救，不是正确用法。
正确做法是：
- 永远检查
base64.DecodeString的err - 对解码结果做必要校验（如非空、长度合理、符合预期格式）
- 把
recover留给真正不可控的深层调用（比如第三方库内部 panic）
若你坚持加 recover，必须满足：
-
defer func() { recover() }()写在同一 goroutine、panic 发生前的函数内 - 不要指望它修复状态：一旦
json.Unmarshal(nil, &v)panic，recover后v仍是零值，且不能再对同一个nil切片重复调用json.Unmarshal
容易踩的坑：把 recover 当 error 处理器用
-
recover()无法区分是 Base64 相关 panic 还是其他 panic（比如空指针、map 并发写入） - 它返回
interface{}，直接r.(error).Error()会二次 panic —— 必须先if r != nil，再用switch r.(type)安全处理 - 在 HTTP handler 中滥用
recover而不记录日志，会导致线上问题静默丢失上下文
最稳妥的路径始终是：
decoded, err := base64.StdEncoding.DecodeString(input)
if err != nil {
http.Error(w, "bad base64", http.StatusBadRequest)
return
}
if len(decoded) == 0 {
http.Error(w, "empty payload", http.StatusBadRequest)
return
}
// 后续处理...
recover 是最后一道物理防线，不是替代错误检查的逻辑开关。Base64 截断问题，99% 应该在 if err != nil 分支里解决，而不是等它崩到 runtime 层再捞。
