sentry-go 的 init() 必须在 main() 开头调用，以确保 panic 捕获、http 中间件和 goroutine 错误均被上报；需配合 httpintegration、configurescope 补全请求上下文，并区分 recover()（兜底 panic）与 captureexception()（主动上报 Error）。
为什么 sentry-go 的 Init() 必须在 main 启动早期调用
因为 Sentry 的 panic 捕获依赖于 recover() 和全局 panic handler 注册，如果 Init() 晚于 goroutine 启动或 HTTP server 启动，那些提前崩溃的 goroutine 就不会被上报。常见现象是：本地能报错，部署后 404 或 panic 完全静默。
-
Init()要放在main()函数最开头，甚至早于日志库初始化 - 不要在 init() 函数里调用
Init()—— 它会阻塞包初始化，且无法处理init()阶段的 panic - 若用
gin或echo，中间件注册前就得确保 Sentry 已就绪，否则中间件内 panic 不会上报
HTTP 请求上下文怎么自动带上用户 ID 和路由信息
默认的 sentry-go 不会提取 http.Request 里的路径、method、User-Agent 或自定义 header，得手动塞进 scope。否则所有错误都显示为 GET /，根本没法定位问题接口。
- 用
sentry.HTTPIntegration可自动附加基础请求字段（method、url、status code），但不包括 header 或用户身份 - 在中间件里调用
sentry.ConfigureScope()，把r.Header.Get("X-User-ID")或 JWT 解析出的user_id写进SetTag("user_id", ...) - 避免在 scope 里写敏感字段（如 Token、密码），Sentry 控制台默认可公开访问
goroutine 崩溃了，为什么 Sentry 没收到？
Go 的 goroutine panic 默认不传播到主线程，sentry-go 的全局 handler 对它无效。你看到的只是日志里一闪而过的 panic: xxx，然后程序继续跑，错误却石沉大海。
- 所有可能 panic 的 goroutine，必须显式套
defer sentry.Recover() - 更稳妥的做法是封装一个
go sentry.Go(func(){...})辅助函数，在内部统一 recover +CaptureException() - 注意：不要对
time.AfterFunc或http.HandlerFunc这类系统启动的 goroutine 盲目加 recover —— 它们已有自己的错误处理逻辑，重复 recover 可能掩盖真实问题
CaptureException() 和 Recover() 到底该用哪个
这两个不是互斥替代关系，而是分工不同：Recover() 是帮你从 panic 中捞出来并上报；CaptureException() 是主动上报已捕获的 error，比如数据库超时、第三方 API 返回非 2xx 等业务异常。
立即学习“go语言免费学习笔记（深入）”；
- 遇到
if err != nil，用sentry.CaptureException(err)，别用Recover() - 在 defer 里用
sentry.Recover()，仅用于兜底未被捕获的 panic -
CaptureException()不会终止当前执行流，Recover()本身不抛异常，但你要自己决定是否 return 或 log
Sentry 在 Go 里真正难的不是接入，而是让每个 panic、每个 error、每个 goroutine 都落到它的视野里 —— 这需要在启动顺序、中间件位置、goroutine 封装、scope 生命周期上做一连串精确控制，漏掉任意一环，监控就变成盲区。