Go expvar怎样暴露可读取的运行指标为什么结果为空或不符合预期

Go 的 expvar 适合给服务加一条轻量的运行指标出口：变量注册在进程内，HTTP 端返回 JSON。遇到“结果为空”时，先看现象再改代码：返回 404 通常是自定义 ServeMux 没挂载处理器；能返回 JSON 但数值不变，通常是业务路径没有更新变量；启动即 panic，则多半是同名变量重复注册。

自定义 ServeMux 为什么会让 /debug/vars 变成 404

空白页面和 404 不是“指标没有值”，而是请求根本没有到达 expvar 处理器。导入 expvar 会为默认路由器准备标准入口，但代码如果改用 http.NewServeMux()，服务接收请求的是另一套路由表，需要把 expvar.Handler() 明确挂进去。

package main

import (
    "expvar"
    "fmt"
    "log"
    "net/http"
    "sync/atomic"
)

var requestTotal = expvar.NewInt("demo_requests_total")
var lastState = expvar.NewString("demo_last_state")
var inFlight atomic.Int64

func main() {
    mux := http.NewServeMux()
    // 自定义 ServeMux 不会自动继承默认路由，必须显式挂载 expvar 处理器。
    mux.Handle("/debug/vars", expvar.Handler())
    mux.HandleFunc("/work", func(w http.ResponseWriter, r *http.Request) {
        // 读取接口只接受 GET；业务接口也先拒绝不需要的方法。
        if r.Method != http.MethodGet {
            http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
            return
        }
        inFlight.Add(1)
        defer inFlight.Add(-1) // 离开请求时恢复进行中的数量。
        requestTotal.Add(1)
        lastState.Set("ok")
        fmt.Fprintln(w, "work accepted")
    })
    // Func 在读取 /debug/vars 时再取值，适合展示原子计数等动态状态。
    expvar.Publish("demo_in_flight", expvar.Func(func() any { return inFlight.Load() }))
    log.Println("listen on :8080")
    if err := http.ListenAndServe(":8080", mux); err != nil {
        log.Fatal(err) // 服务退出时保留原因，便于定位启动失败。
    }
}

这里故意没有再次调用 http.Handle("/debug/vars", ...)。如果服务使用默认路由器，可以直接把它作为 ListenAndServe 的第二个参数；如果使用自定义路由器，就只在自定义路由器上注册一次。两种写法不要混用。

用 GET 读取，先区分“没有数据”和“没有更新”

服务启动后先请求业务路径，再读取指标：

# 先制造一次业务计数，确认更新路径会被执行。
curl -s http://127.0.0.1:8080/work

# expvar 的读取入口使用 GET，返回 JSON 文本。
curl -s -X GET http://127.0.0.1:8080/debug/vars

返回对象中通常会包含运行时注册的 cmdline、memstats 和示例中的自定义名称。若能看到 demo_requests_total，但它始终是 0，检查请求是否真的走到 /work；若 demo_last_state 没变化，检查是否存在提前返回的分支。

注册变量后为什么仍然读不到最新数值

NewInt 和 NewString 只是把变量放进全局名称表，不会替你猜测业务事件。计数器要在成功路径调用 Add，状态要在状态真正改变时调用 Set。动态值可以用 expvar.Func，它在读取时执行函数，适合展示原子变量当前值，但函数本身应保持快速、无副作用。

还要注意名称的生命周期：expvar.Publish 发现同名变量时会触发 panic。不要在每次请求里注册变量，也不要让多个包用同一个通用名称。推荐在包初始化或明确的启动阶段集中完成注册，业务函数只负责更新已经拿到的变量指针。

expvar 的适用边界与收尾检查

expvar 的优点是标准库、接入轻、返回 JSON，适合内部诊断、冒烟检查和少量运行计数。它没有完整监控系统常见的标签维度、直方图聚合、鉴权和远程存储能力。生产环境暴露 /debug/vars 前，应把它放在受控网络或认证后的管理入口，不要直接公开到公网。

• 路由层：确认实际服务使用的 mux 与 /debug/vars 注册在同一套路由表。
• 数据层：确认名称唯一，更新动作在成功路径执行，动态函数不做慢查询。
• 协议层：使用 GET 读取，遇到 404 先查路由，遇到静态旧值再查更新时机。

常见问题

只导入 expvar 就一定能访问 /debug/vars 吗？

只有请求走默认路由器时才可直接依赖它的标准注册。使用自定义 ServeMux 时，应显式挂载 expvar.Handler()。

为什么用 POST 读取 expvar 没有预期结果？

读取入口按 GET 设计；把读取请求改为 GET，并检查反向代理是否保留了路径。

expvar 能替代 Prometheus 指标吗？

不能简单替代。expvar 适合轻量 JSON 诊断；需要标签、聚合、告警和长期保存时，应选择专门的监控方案。