直接返回 err.Error() 危险，因会泄露数据库名、文件路径等敏感信息；应使用 fmt.Errorf("msg") 剥离原始错误，或定义 SafeError 类型分离公私错误信息，并通过中间件统一拦截处理。
为什么直接返回 err.Error() 是危险的
Go 程序中常见写法是把底层错误直接拼进 HTTP 响应或日志，比如 http.Error(w, err.Error(), http.StatusInternalServerError)。这会让攻击者看到数据库驱动名、文件路径、SQL 查询片段、第三方服务地址等敏感信息。生产环境一旦暴露 file="/etc/passwd" 或 host=internal-db:5432，就等于递上入侵地图。
用 fmt.Errorf 包装并丢弃原始错误链
若无需向上层传递可恢复的错误上下文（比如中间件、重试逻辑），最简方案是彻底剥离原始错误：用 fmt.Errorf("something went wrong") 替代 fmt.Errorf("something went wrong: %w", err)。后者保留了 %w，会透出原始错误；前者只留一层干净字符串。
常见误用：
return fmt.Errorf("failed to parse config: %w", err) // ❌ 泄露原始 err
return fmt.Errorf("failed to parse config") // ✅ 安全，无上下文
注意：errors.Is() 和 errors.As() 在这种写法下失效，所以仅适用于终端错误（如 HTTP handler 最终响应）。
立即学习“go语言免费学习笔记（深入）”；
用自定义错误类型实现可控的错误展示
当需要区分“对用户显示什么”和“对日志记录什么”时，定义一个结构体错误更可靠：
type SafeError struct {
PublicMsg string
PrivateErr error
}
func (e *SafeError) Error() string {
return e.PublicMsg
}
func (e *SafeError) Unwrap() error {
return e.PrivateErr
}
使用方式：
- HTTP handler 中调用
e.Error()返回给前端 - 日志系统中用
log.Printf("internal error: %+v", e.PrivateErr) - 仍可用
errors.Is(err, someKnownErr)判断原始错误类型（因实现了Unwrap）
关键点：不要在 PublicMsg 里拼接 e.PrivateErr.Error()，否则前功尽弃。
HTTP handler 中统一错误拦截与转换
避免每个 handler 都手动判断错误类型，用中间件统一处理：
func ErrorMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if rec := recover(); rec != nil {
http.Error(w, "internal server error", http.StatusInternalServerError)
log.Printf("panic: %v", rec)
}
}()
next.ServeHTTP(w, r)
})
}
再配合一个错误响应包装函数：
func WriteError(w http.ResponseWriter, err error) {
var safeErr *SafeError
if errors.As(err, &safeErr) {
http.Error(w, safeErr.Error(), http.StatusInternalServerError)
return
}
// 兜底：所有未标记的错误都转为通用提示
http.Error(w, "something went wrong", http.StatusInternalServerError)
}
这样能确保没有遗漏的 err 直接暴露到客户端。
真正难的是错误分类边界——哪些该标记为 *SafeError，哪些该透传（比如 404、400 这类业务错误），这个决策比代码本身更影响安全水位。
