expvar 默认不启动独立http服务，需显式注册到http.servemux或框架路由（如gin用gin.wraph），路径为/debug/vars；仅暴露通过expvar.publish或expvar.newxxx注册的变量，类型须为int64、float64等支持类型；生产环境必须限制监听地址并禁用公网访问，避免敏感信息泄露。
Expvar 默认端口和 HTTP 处理器怎么注册才不冲突
Expvar 本身不启动独立 HTTP 服务，它依赖你已有的 http.ServeMux 或 http.DefaultServeMux。如果你用的是 Gin、Echo 或其他 Web 框架，expvar.Handler 不会自动挂载，必须显式注册——否则访问 /debug/vars 直接 404。
常见错误是直接调用 http.ListenAndServe 后没把 expvar 注册进去，或者框架屏蔽了 /debug/ 路径（比如 Gin 默认不透传以 /debug/ 开头的请求）。
- 使用标准库时，在
http.ListenAndServe前加：http.Handle("/debug/vars", expvar.Handler()) - 用 Gin 时，需启用
gin.DebugMode并手动注册：r.GET("/debug/vars", gin.WrapH(expvar.Handler())) - 用 Echo 时，用
e.GET("/debug/vars", echo.WrapHandler(expvar.Handler())) - 避免路径冲突：确保没有中间件拦截或重写
/debug/前缀（尤其注意反向代理或网关层）
自定义变量注册后为什么在 /debug/vars 里看不到
Expvar 只暴露已通过 expvar.Publish 或 expvar.NewXXX 显式注册的变量；全局变量、局部变量、结构体字段默认不参与序列化。而且，类型必须是 expvar 支持的（int64、float64、string、map[string]interface{} 或实现了 expvar.Var 接口的类型）。
常见陷阱是用了 expvar.NewInt() 但没赋值，或用 expvar.NewMap() 后忘了调用 .Set() —— 这些变量在 JSON 输出里会显示为 null 或被忽略。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确注册计数器：
reqCount := expvar.NewInt("http_requests_total")，之后用reqCount.Add(1) - 注册 map 类型：
stats := expvar.NewMap("service_stats")，再stats.Set("uptime_sec", expvar.Func(func() interface{} { return time.Since(startTime).Seconds() })) - 避免用
map[string]int直接 publish：必须包装成expvar.Map或expvar.Func - 变量名不能含空格或特殊字符，否则 JSON 解析可能出错或被截断
生产环境暴露 /debug/vars 是否安全
Expvar 默认无鉴权、无加密、无限速，暴露在公网等于把内存统计、goroutine 数、自定义指标全交出去。曾经有团队因未收敛路径，被扫描器批量采集 /debug/vars 导致敏感业务逻辑被逆向推测。
它不是设计来对外服务的，而是调试辅助工具。Kubernetes liveness/readiness 探针也不该依赖它——它不保证低延迟，且 goroutine dump 可能阻塞。
- 务必限制监听地址：不要用
":8080"，改用"127.0.0.1:8080"或内网 IP - 在 ingress 或 service mesh 层做路径级屏蔽（如 Istio VirtualService 中 drop
/debug/） - 若必须开放，至少加一层反向代理鉴权（如 Nginx basic auth），或改用 Prometheus metrics + /metrics 端点
- 注意：expvar 输出包含
cmdline、memstats等，可能泄露启动参数或内存布局
和 Prometheus metrics 共存时要注意什么
Expvar 和 Prometheus 都是指标暴露机制，但底层不兼容：expvar 是 JSON 格式、无类型声明、无标签支持；Prometheus 要求文本格式 + 显式类型（counter/gauge/histogram）。强行把 expvar 转成 Prometheus 格式（比如用 expvarmon 或自定义 exporter）容易丢精度、漏维度、无法表达直方图。
更现实的做法是分场景：expvar 保留给本地运维 debug（如快速看 goroutine 数），Prometheus 用于长期监控告警。两者端口可以不同，但别让同一个端点同时响应两种格式。
- 不要在
/metrics上复用 expvar.Handler()，也不要试图用 expvar 包生成 prometheus 文本 - 如果已有大量 expvar 自定义指标，可用
github.com/mndrix/expvarmon抓取并转发，但它不支持 label、histogram，仅适合简单数值同步 - goroutine 数、heap allocs 等基础指标，优先走 Prometheus client_golang 的
runtime.ReadMemStats，比 expvar 更稳定、可配采样 - 注意：expvar 的
memstats字段名和 Prometheus 的go_memstats_*不一致，直接映射易出错
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
