expvar.newint 创建的变量需显式注册才能出现在 /debug/vars 页面，因其默认不自动注册；http handler 无鉴权，应重挂载并加访问控制；expvar 不支持直方图且 float 非原子，高并发下数据不准；go 1.21+ json 数值转字符串，前端需解析适配；expvar 仅为调试工具，非生产级指标系统。
expvar.NewInt 为什么没出现在 /debug/vars 页面里
因为 expvar.NewInt 创建的变量默认不会自动注册到全局变量表，必须显式调用 expvar.Publish 或直接用 expvar.Get + Register 才能被 /debug/vars 暴露。常见错误是只声明不注册，导致页面里查不到。
- 正确做法：用
expvar.NewInt("http_requests_total")后，立刻调用expvar.Publish("http_requests_total", counter) - 更省事的方式：直接用
expvar.Register注册已命名的变量，比如expvar.Register(&counter)（前提是该变量实现了expvar.Var接口） - 注意
expvar.NewMap和expvar.NewString同理，不注册就不可见
HTTP handler 被 expvar 自动注册后，如何避免暴露敏感信息
expvar 默认把所有注册的变量挂到 /debug/vars，而这个路径没有访问控制。如果服务跑在公网或混合网络环境，直接暴露运行时内存、goroutine 数、自定义计数器可能泄露业务逻辑或攻击面。
- 不要依赖默认路径：用
http.Handle("/metrics", expvar.Handler())显式挂载，并配合中间件做鉴权（如检查Authorizationheader 或 IP 白名单） - 避免注册含敏感内容的结构体：比如用户 ID 计数器、未脱敏的错误消息字段；应先做聚合或哈希再上报
- 生产环境建议关闭
/debug/vars默认 handler，只保留你明确需要的指标端点
用 expvar 记录 HTTP 请求耗时，为什么直方图数据不准确
expvar 原生不支持直方图（histogram），强行用 expvar.NewFloat 累加总和 + 单独计数器算平均值，会丢失分布特征，且并发更新时存在竞态——Float 的 Add 方法不是原子的。
- 替代方案：用
sync/atomic维护uint64类型的纳秒级耗时总和与请求数，再封装成自定义expvar.Var实现String()返回平均值 - 若需分位数（p90/p99），得换 prometheus/client_golang；
expvar本身能力有限，别硬扛 - 注意
expvar.Float的Add是非线程安全的，高并发下数值会漂移
Go 1.21+ 中 expvar.Handler() 返回的 JSON 格式变了，前端解析失败怎么办
Go 1.21 起，expvar.Handler() 输出的 JSON 把数字类型统一转为字符串（例如 "memstats":{"heap_alloc":"12345678"}），是为了避免 JavaScript number 精度丢失。但旧监控脚本若用 JSON.parse() 后直接当数字用，就会报 NaN。
立即学习“go语言免费学习笔记（深入）”；
- 前端需适配：对所有数值字段做
parseInt(val, 10)或parseFloat(val) - 后端兼容：可自己写个 wrapper handler，对响应 body 做正则替换（不推荐，维护成本高）
- 更稳妥的做法：用
go.opentelemetry.io/otel/exporters/stdout/stdoutmetric或 Prometheus 替代，expvar本质是调试工具，不适合长期做指标管道
expvar 的设计初衷是开发期快速观测，不是生产级指标系统。它不支持标签、采样、远程推送，也不保证并发安全——这些地方一不留神就掉坑里。
