版本支持：v2.16.1+

单次开销

• 未引入 liteflow-metrics 时接近零。 chain 钩子调用本就存在于 Chain.execute()；node 新钩子在 NodeComponent.execute() 的 finally 中只多一次"空列表"判断，不分配、不遍历。
• 引入后亚微秒级，通常 < 1%。 Meter 实例在模块内按 tag 组合缓存（ConcurrentHashMap），每次执行只做一次字符串拼 key 的缓存查找 + timer.record(...)（几次 LongAdder.add，量级约几十纳秒）、一个小样本对象、每线程栈的一次入/出栈；出错时再有一次 Counter 自增。

相对 NodeComponent.execute() 本就存在的 CmpStep、StopWatch、两次 LOG.info，以及用户业务逻辑（常含 DB / IO），新增开销可忽略。

真正的风险点是时间序列基数

• 每个 (chain,scope,status) / (node,type,status) 组合驻留一个小 Meter（几百字节）并导出一条时间序列。
• 选定的 chain + node 两级 → 内存 ≈ O(chain 数 + node 数)，几千个量级仅几 MB。
• 已规避高基数陷阱：未采用"node-in-chain 三级"组合；exception tag 只取类 simpleName，基数有界；不含 requestId、完整异常 message 等。
• 超高吞吐场景下若需进一步压成本，active（LongTaskTimer）是最可做成可选 / 移除的一项，用 MeterFilter 裁掉即可（见分位与直方图）。