抽象基类强制子类实现reportthroughput方法以确保吞吐指标必报，throughputmetrics支持上下文注入与线程安全计数，上报通道由基类统一委托，启动时通过反射校验+空载测试兜底。
在流程引擎中，让每个节点主动、统一地上报吞吐指标（如每秒处理任务数、平均响应耗时、失败率等），不能靠约定或文档提醒，而要靠架构约束。抽象方法正是实现这种强制性的核心手段——它把“上报行为”从可选项变成编译期必须项。
定义带吞吐上报契约的抽象节点基类
所有具体节点（如设备采集节点、数据校验节点、PLC写入节点）都必须继承同一个抽象基类。该基类声明一个abstract方法，例如：
-
reportThroughput(ThroughputMetrics metrics)：参数为标准化吞吐指标对象，含
processedCount、errorCount、lastLatencyMs等字段 - 该方法不提供默认实现，子类必须重写，否则编译失败
- 基类在
execute()执行结束前自动调用此方法，确保每次运行必上报
吞吐指标对象需支持运行时上下文注入
单纯定义上报方法还不够——指标值得有来源。因此ThroughputMetrics不应是空壳，而应具备：
- 构造时绑定当前
Execution实例，可提取processInstanceId、nodeId、startTime等元信息 - 内置计时器钩子：
startTimer()在节点进入时触发，recordEnd()在执行完成时自动计算耗时并累加 - 线程安全的原子计数器（如
AtomicLong processed），避免多实例并发时统计错乱
上报通道由抽象层统一接管，子类不可绕过
上报动作本身（比如发到Prometheus Pushgateway、写入本地RingBuffer、触发MQ消息）不能由各子类自由决定。正确做法是：
- 抽象基类持有一个
ThroughputReporter接口引用，由DI容器注入（如Slickflow的AutoExecutionContext或自研调度器提供） - 子类在
reportThroughput()中只负责填充metrics字段，不接触网络、IO或序列化逻辑 - 基类在调用完子类的
reportThroughput()后，立即委托reporter.report(metrics)完成实际发送
运行时验证与兜底机制
光靠编译约束还不够，工业场景需防“带病上线”。可在引擎启动时增加校验：
- 扫描所有已注册节点类型，检查是否全部实现了
reportThroughput（反射+注解标记） - 在流程实例首次运行前，对每个节点执行一次空载
reportThroughput(new DummyMetrics())，验证不抛异常 - 若某节点未实现或上报失败，引擎拒绝加载该流程定义，并记录ERROR日志和告警
