不能彻底屏蔽堆栈，但可通过panic恢复路径的三处拦截点控制其输出、暴露和写入：recover中禁用debug.PrintStack/log.Fatal；Fiber Recovery中间件禁用StackTraceHandler写响应；HTTP handler中避免error.Error()直接返回未包装错误。
不能彻底屏蔽，但可以控制堆栈是否输出、是否暴露给客户端、是否写入响应体——关键在 panic 恢复路径的三处拦截点。
recover 里别调用 debug.PrintStack 或 log.Fatal
很多同学以为只要不写 debug.PrintStack() 就不会输出堆栈，其实错在 recover 流程里还可能隐式触发日志或响应写入。
- 显式调用
debug.PrintStack()或log.Fatal()会把堆栈打到os.Stderr，若服务 stdout/stderr 被重定向（如 systemd），可能漏掉；更糟的是，它不经过任何中间件，直接污染日志流 - 真正要防的是：recover 后又调用了
w.Write()、ctx.Status().Send()或其他响应写入逻辑，导致 panic 错误文本被拼进 HTTP 响应体 - 正确做法是 recover 后只做两件事：记录（用
log.Error()或结构化日志）、重置响应（见下一条）
Fiber 的 Recovery 中间件必须禁用 StackTraceHandler 写响应
如果你用 Fiber 框架，fiberRecover.Config.EnableStackTrace = true 只是开启堆栈捕获能力，不等于堆栈会发给客户端——真正泄露靠的是 StackTraceHandler 是否往 ctx.Response() 写内容。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查你的
StackTraceHandler实现：里面绝不能出现ctx.Send()、w.Write()、ctx.JSON()等任何响应写入调用 - 常见错误：handler 里写了
ctx.Status(500).JSON(map[string]string{"error": fmt.Sprintf("%v", err)})—— 这会把原始 panic 文本塞进 JSON，完全暴露内部细节 - 安全写法：只调用
logger.Error("panic recovered", "stack", string(debug.Stack()))，然后显式执行ctx.Response().Reset()
HTTP handler 中避免 error.Error() 直接返回
堆栈泄露不只来自 panic，更多来自未包装的底层错误被直接序列化返回。
立即学习“go语言免费学习笔记（深入）”；
- 第三方库（如
pgx、redis）报的错误自带驱动细节，err.Error()一调就全吐出去。必须提前用fmt.Errorf("db query failed: %w", err)包装，再用类型断言过滤 - 中间件里拦截
*AppError类型时，确保其Error()方法不返回原始 error 字符串，而是固定提示如"internal server error" - 开发环境可加
"debug": true字段附带堆栈，但生产环境必须删掉该字段，且禁止对任意error调用%+v格式化后返回
最易被忽略的点：debug.Stack() 返回的字节切片默认上限 4KB，超长会被截断；你以为屏蔽了堆栈，其实只是截断后剩下一截不可读的乱码，仍可能包含路径、函数名等敏感信息——别依赖截断当防护，得从源头掐断写入响应体的路径。
