必须检查 sentry.Init 返回值并显式调用 sentry.Flush：初始化失败会静默忽略，DSN 格式错误或网络不通导致不上报；panic 默认捕获，error 需手动 CaptureException；goroutine panic 需自行 recover 并上报；Release 字段缺失会导致归组异常。
怎么初始化 Sentry 客户端不报 sentry.Init 失败
多数人卡在第一步：调用 sentry.Init 后程序没报错但错误完全不上报。根本原因是客户端初始化失败被静默吞掉，或者 DSN 配置无效却没检查返回值。
必须检查 sentry.Init 的返回值，它返回一个 error，不是 nil 就说明初始化失败（比如 DSN 格式错误、网络不通、Sentry 服务不可达）：
if err := sentry.Init(sentry.ClientOptions{
Dsn: "https://xxx@o123.ingest.sentry.io/456",
}); err != nil {
log.Fatal(err) // 别忽略！
}- DSN 必须是完整 URL，不能只写域名或少协议头
- 开发环境建议加
Environment: "development"，避免和生产数据混在一起 - 若用 Docker 或内网部署，确认容器能访问
o123.ingest.sentry.io（DNS + 网络策略）
panic 和普通 error 怎么都让 Sentry 捕获到
Sentry 默认只捕获 panic，error 值不会自动上报 —— 这是最大误区。你写的 if err != nil { return err } 不会触发任何上报。
手动上报需显式调用 sentry.CaptureException 或 sentry.CaptureMessage：
立即学习“go语言免费学习笔记（深入）”；
if err != nil {
sentry.CaptureException(err)
return err
}- panic 会被
sentry.Init自动恢复并捕获，前提是没被其他 recover 拦截 - HTTP handler 中建议用中间件封装，统一处理
recover()并调用sentry.CaptureException - 不要对每个
err都上报，高频低价值错误（如用户输入校验失败）会刷爆 quota
为什么本地跑通了，上线后 Sentry 控制台看不到错误
常见于 Go 二进制部署后：进程崩溃快、日志没刷出、或 Sentry 缓冲未 flush 就退出。
Sentry 默认异步发送事件，进程 exit 前必须显式调用 sentry.Flush，否则事件丢在内存里：
defer sentry.Flush(2 * time.Second) // 推荐放在 main 函数末尾
- 若用
os.Exit(0)或信号强制退出，defer不执行 → 错误丢失 - 在
syscall.SIGTERM处理中也要加sentry.Flush - 检查
Release字段是否填了（如v1.2.3），否则错误会归到No Release分组，容易被忽略
Go 的 goroutine panic 为什么 Sentry 捕不到
标准 sentry.Init 只 hook 主 goroutine 的 panic。新开 goroutine 里 panic，会直接 crash 进程，且 Sentry 来不及捕获。
必须手动为每个 goroutine 加 recover 包裹，并转发给 Sentry：
go func() {
defer func() {
if r := recover(); r != nil {
sentry.CaptureException(fmt.Errorf("panic in goroutine: %v", r))
}
}()
// ...业务逻辑
}()- 更稳妥的做法是封装一个
SafeGo工具函数，统一处理 recover + Sentry 上报 - 注意：goroutine panic 后状态不可靠，别试图继续用共享变量或 channel
- 如果用
errgroup.Group，需在Go方法外再包一层 recover
Sentry 在 Go 里不是“装上就灵”的监控，它的上报链路比 HTTP 日志长得多：触发 → 捕获 → 序列化 → 缓冲 → 网络发送 → flush。任一环节断开，错误就消失，而你往往看不到任何提示。最常漏掉的是 sentry.Flush 和 DSN 初始化失败的检查。
