Beego 的 toolbox 模块提供开箱即用的健康检查与 pprof 调试，但不原生支持 Prometheus 指标；需手动集成 prometheus/client_golang，全局注册指标、挂载 /metrics handler，并确保监控复用业务资源句柄。
Beego 自带的 toolbox 模块能快速启用基础运行时监控，但原生不暴露 Prometheus 兼容的指标端点；要实现生产级指标收集，必须手动集成 prometheus/client_golang 并注册 HTTP handler。
用 toolbox 启用内置健康检查和 profile 调试
Beego 的 toolbox 是开箱即用的轻量监控入口，无需额外依赖，适合验证服务存活和快速排查 goroutine/内存问题。
-
toolbox.AddHealthCheck("database", &DatabaseCheck{})注册后，GET/healthcheck会返回各检查项状态（如*database:OK或错误详情） - 启用
profile需调用toolbox.StartProfile()，之后可通过/debug/pprof/下的子路径（如/debug/pprof/goroutine?debug=1）获取实时运行时快照 - 注意：默认 profile 端口与主服务端口一致，若启用了 Admin 模块（
EnableAdmin = true），/debug/pprof/会自动挂载；否则需显式调用StartProfile - 健康检查的
Check()方法不能阻塞太久，超时由客户端控制，Beego 本身不设超时逻辑
手动集成 Prometheus 指标暴露端点
Beego 不像 Gin 或 Echo 那样有成熟中间件生态，prometheus/client_golang 的 http.Handler 必须手动挂载到路由系统中，且不能依赖 Controller 生命周期。
- 在
main.go初始化阶段注册指标，例如：prometheus.MustRegister(prometheus.NewCounterVec(...)) - 创建独立 HTTP handler：用
promhttp.Handler()获取指标 handler，再通过 Beego 的beego.Handler("/metrics", promhttp.Handler())挂载到路径 - 不要在 Controller 的
Get()方法里调用promhttp.Handler().ServeHTTP()—— 这会绕过 Beego 的 context 和中间件，且无法正确设置 Content-Type - 如果使用了反向代理（如 Nginx），确保转发
/metrics请求时不修改 header，尤其避免缓存该路径
常见指标类型与 Beego 生命周期对齐方式
直接在 Controller 中定义指标变量会导致实例化混乱；指标应全局单例注册，更新动作才与请求生命周期绑定。
- 计数器（
Counter）适合统计总请求数、错误数：myReqCounter.WithLabelValues(c.Ctx.Input.Method(), c.Ctx.Input.URI()).Inc()放在Prepare()或Finish()中 - 直方图（
Histogram）用于响应时间：在Prepare()记录开始时间，在Finish()计算耗时并.Observe() - 避免在
Init()或func init()中读取 Beego 配置（如beego.AppConfig.String("port")），此时配置可能未加载完成；改用appconfig.DefaultConfig或延迟到main()后注册 - goroutine 数量、内存分配等运行时指标建议用
prometheus.NewGoCollector()和prometheus.NewProcessCollector()主动注册，它们不依赖 Beego，但需早于promhttp.Handler()初始化
真正容易被忽略的是指标一致性：比如 /metrics 端点返回的数据，和 /healthcheck 返回的状态，底层依赖的数据库连接对象是否是同一个实例？如果 health check 新建了连接而业务代码用 ORM 连接池，那监控就失去了意义。所有监控探针必须复用真实业务路径的资源句柄。
