panic信息中不能直接打印敏感字段，因为默认会完整输出调用栈和panic值，导致用户id、手机号、token等明文泄露至日志系统；应使用safeerror封装并脱敏，recover时统一处理，输入数据需前置清洗，第三方库panic要控制入参，goroutine内panic需结合traceback裁剪与预防为主。
panic 信息里为什么不能直接打敏感字段
因为 panic 触发时默认会打印完整调用栈和 panic 值，如果 panic 值是包含用户 ID、手机号、token 的结构体或 map，这些内容就会原样暴露在日志甚至终端里。生产环境日志可能被同步到 ELK、Sentry 或人工排查时直接可见，等于把敏感数据“主动推送”出去。
常见错误现象：panic: user={ID:12345 Phone:138****1234 Token:abc123...} 这类输出在日志系统里一搜一大片。
- panic 值如果是自定义 struct，Go 默认用
fmt.Sprint打印，不走String()方法（除非显式调用） - 即使用了
log.Panic，底层仍是调用fmt.Sprint，不会自动过滤 - recover 后再格式化输出，也得自己控制 panic 值的序列化逻辑，否则白 recover
用 recover + 自定义 error 包装替代原始 panic 值
核心思路：不让敏感数据成为 panic 的直接参数，而是封装成可控的 error 类型，在 recover 时做脱敏处理。
使用场景：HTTP handler、gRPC server、定时任务等需要稳定退出且不泄密的入口点。
立即学习“go语言免费学习笔记（深入）”；
- 定义一个带脱敏能力的
SafeError类型，实现Error()方法，内部对敏感字段做掩码 - 触发异常时，用
panic(&SafeError{...})而非panic(user) - 在顶层
defer/recover中判断 panic 值是否为*SafeError，是则记录err.Error()，否则按默认方式处理（如 log.Printf("%+v", r)）
示例：
type SafeError struct {
Msg string
UserID string `redact:"true"`
Phone string `redact:"true"`
}
<p>func (e *SafeError) Error() string {
return fmt.Sprintf("safe-error: %s, uid: %s, phone: %s",
e.Msg,
redactString(e.UserID),
redactString(e.Phone),
)
}</p><p>func redactString(s string) string {
if len(s) == 0 {
return ""
}
return s[:min(4, len(s))] + "****"
}
全局 panic 捕获时如何避免日志泄露调用栈细节
Go 的 runtime.Stack 默认返回完整函数名和文件路径，比如 /home/user/project/internal/handler.go:123 —— 这些路径可能暴露项目结构、开发机用户名、内部模块命名习惯。
性能 / 兼容性影响：频繁调用 runtime.Stack 有轻微开销，但比 panic 不受控导致安全事件代价小得多。
- 不要直接
log.Printf("panic: %+v\n%s", r, debug.Stack()) - 用
runtime.Callers+runtime.CallersFrames手动提取帧信息，并过滤掉绝对路径、只保留函数名和行号偏移 - 对
Frames中每个Frame，检查Func.Name()是否含 internal/、vendor/ 等关键词，决定是否记录 - 生产环境可完全关闭源码路径，只留
main.main、http.HandlerFunc.ServeHTTP这类通用标识
第三方库 panic 怎么办（比如 json.Unmarshal、database/sql）
这类 panic 无法通过包装 error 规避，因为它们是运行时 panic（如 invalid memory address），不是你主动 throw 的值。
关键判断：它们本身不带业务敏感数据，但 panic 上下文（比如你传进去的 map[string]interface{}）可能含敏感键值。
- 对输入数据做前置清洗：进
json.Unmarshal前，用redactMap函数递归抹掉已知敏感 key（"phone","id_card","token"） - 避免把原始请求 body 直接传给
panic- prone 函数；先解包、校验、脱敏，再构造干净结构体 - database/sql 的
Scan不会 panic，但Row.Scan(&v)中v若是未初始化指针，会 panic —— 这类属于代码缺陷，应通过静态检查（如staticcheck）提前发现，而不是靠运行时脱敏
真正难处理的是 panic 发生在你没控制权的 goroutine 里（比如 http.Server 启动的子协程），这时候唯一可靠的方式是启动前设置 debug.SetTraceback("single") 并配合日志字段裁剪策略 —— 但别指望它能防住所有泄露，重点还是减少 panic 触发面。
