来自 #136 的架构级评审建议。不阻塞合入，仅供参考是否有更好的架构解法。
💡 [建议 · 性能] 快照读路径每次调用访问所有 atomic 变量 pkg/metrics/metrics.go
问题根因：Take() 遍历全部 8 个 atomic.Load + 1 个回调函数调用。每 10s 调用一次，频次极低，当前不是问题。但如果 future 把 Take() 接上 HTTP /metrics 端点（每秒可能拉多次），堆 8 次 Load 在 x86 上仍轻（约 8×ns 级），但在 ARM 弱序平台上可能会有可见的缓存抖动。
为什么低级解法不够：不做任何事也可以——10s 间隔完全感受不到。但 10s 快照是作为 headless 默认值，未来若接 Prometheus pull 模型（scrape 间隔可能 15s 或更短），每 10s 再被拉一次，这个函数会跑在两条路径上。
架构级方案：用 atomic.Value 缓存一份不可变的 Snapshot 副本，后台 goroutine 每 10s 读取原始计数器构造一次快照并 Store 到 atomic.Value；Take() 只做一次 Load。这样 Take() 从 O(n_atomic) 降为 O(1)。但收益甚微——当前 8 次 Load 的开销约 20-30ns，每 10s 一次。不推荐现在改，仅记录为「若未来接 HTTP pull 时可考虑的优化」。
代价/收益：代价是额外 8 字节的 atomic.Value + 后台 ticker 写路径多一次拷贝构造；收益是 Take() 从 O(8×Load) 降为 O(1×Load)，仅在接入高频拉取路径时才有价值。
💡 [建议 · 性能] 快照读路径每次调用访问所有 atomic 变量
pkg/metrics/metrics.go问题根因：
Take()遍历全部 8 个atomic.Load+ 1 个回调函数调用。每 10s 调用一次，频次极低，当前不是问题。但如果 future 把Take()接上 HTTP /metrics 端点（每秒可能拉多次），堆 8 次Load在 x86 上仍轻（约 8×ns 级），但在 ARM 弱序平台上可能会有可见的缓存抖动。为什么低级解法不够：不做任何事也可以——10s 间隔完全感受不到。但 10s 快照是作为 headless 默认值，未来若接 Prometheus pull 模型（scrape 间隔可能 15s 或更短），每 10s 再被拉一次，这个函数会跑在两条路径上。
架构级方案：用
atomic.Value缓存一份不可变的 Snapshot 副本，后台 goroutine 每 10s 读取原始计数器构造一次快照并Store到atomic.Value；Take()只做一次Load。这样Take()从 O(n_atomic) 降为 O(1)。但收益甚微——当前 8 次 Load 的开销约 20-30ns，每 10s 一次。不推荐现在改，仅记录为「若未来接 HTTP pull 时可考虑的优化」。代价/收益：代价是额外 8 字节的
atomic.Value+ 后台 ticker 写路径多一次拷贝构造；收益是 Take() 从 O(8×Load) 降为 O(1×Load)，仅在接入高频拉取路径时才有价值。