必须检查sentry.init()返回值并配置完整dsn、environment和release，否则错误将静默丢失；panic需defer sentry.recover()配合attachstacktrace:true还原堆栈，普通error须用sentry.captureexception()以支持聚类。
sentry.Init 必须在 main 函数最开头调用
初始化失败会静默丢弃所有上报，不是“没报错”，而是根本没发出去。很多人写完 sentry.Init() 就跑，结果线上错误全看不见。
- 必须检查返回值：
if err := sentry.Init(...); err != nil { log.Fatal(err) } - DSN 必须是完整 URL：
https://abc123@o123.ingest.sentry.io/456，漏协议头或路径都会导致 Init 失败 - 开发环境加
Environment: "development"，避免和生产数据混在一起 - 建议开启
Debug: true，它会在控制台打印初始化状态和发送日志，比盲猜快得多 - 不要在
init()函数里调用Init()—— 会阻塞包初始化，且无法处理init()阶段的 panic
panic 和 error 上报方式完全不同
Sentry 默认只捕获未被拦截的 panic，if err != nil 这类普通 error 完全不会自动上报——这是最常被误解的一点。
- 遇到业务错误（如数据库超时、HTTP 调用失败）：显式调用
sentry.CaptureException(err) - 兜底未捕获 panic：在 HTTP handler 或 goroutine 入口处
defer sentry.Recover() - 高频低价值 error（如参数校验失败）别全量上报，否则很快刷爆 quota
-
CaptureException()不终止执行流；Recover()本身不 panic，但你要自己决定是否 return 或 log
goroutine panic 不会上报，除非你手动处理
Go 的 goroutine panic 不传播到主线程，sentry.Init 注册的全局 panic handler 对它无效。你只会看到日志里一闪而过的 panic: xxx，然后程序继续跑，Sentry 控制台空空如也。
- 所有可能 panic 的 goroutine，必须显式套
defer sentry.Recover() - 更稳妥的做法是封装一个
sentry.Go(func(){})辅助函数，在内部统一 recover +CaptureException() - 不要对
time.AfterFunc或框架启动的 goroutine（如http.HandlerFunc）盲目加 recover —— 它们已有自己的错误处理逻辑 - 如果用了
sentry.Flush做优雅退出，recover后必须等 flush 完再 exit，否则 panic 日志可能被截断
进程退出前不调 sentry.Flush，错误就丢了
Sentry 默认异步发送事件，缓冲区里的数据不会自动刷出。进程直接退出（比如 os.Exit(0)、收到 SIGTERM）时，defer 不执行，所有待上报事件永久丢失。
- 在
main函数末尾加defer sentry.Flush(2 * time.Second) - 若注册了
syscall.SIGTERM处理器，也要在里面显式调一次sentry.Flush() -
Release字段必须填（如v1.2.3），否则错误归到No Release分组，排查时容易被忽略 - HTTP 请求上下文要手动补全：用
sentry.HTTPIntegration可带 method/url/status，但用户 ID、X-Request-ID等需在中间件里用sentry.ConfigureScope()注入
真正难的不是接入，而是让每个 goroutine、每个中间件、每次 os.Exit 都按预期触发上报。漏掉任意一环，错误就静默消失。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
