原型式继承不适用于数据可视化大屏的指标派生链路构建，因其本质是业务逻辑建模，需依赖数据血缘、计算图谱、元数据管理、指标定义中心及DAG引擎支撑。
原型式继承本身不适用于数据可视化大屏中的指标派生链路构建。
指标派生链路的本质是业务逻辑建模，不是对象继承关系
数据大屏中“招生率→报到率→首年留存率→就业率”这类链路，反映的是教育管理流程中各环节的因果与转化关系，属于业务语义建模范畴。原型式继承（如 JavaScript 中 Object.create()）用于对象间属性和方法的复用，它描述的是“是什么”（is-a）或“能做什么”（has-behavior）的关系，无法表达“从A经过B得到C”的计算依赖、时序约束或口径校验逻辑。
真正支撑派生链路的技术机制是数据血缘与计算图谱
一个可靠的指标派生链路需要明确记录：原始字段来源、清洗规则、聚合维度、时间窗口、口径说明、负责人。这依赖于：
- 元数据管理平台：自动捕获 SQL 或 ETL 脚本中的输入表、输出字段、转换函数，形成可追溯的血缘图；
- 指标定义中心：以声明式方式配置指标（如“就业率 = 就业学生数 / 毕业学生数”，并绑定分母分子各自的计算逻辑）；
- 计算引擎支持 DAG 执行：如 Flink 或 Spark 支持按依赖顺序调度任务，确保上游指标更新后下游自动重算。
若强行套用原型式继承，反而会引入维护风险
例如用构造函数模拟“基础指标→衍生指标→组合指标”，看似有层级，实则掩盖了关键问题：
- 无法体现不同指标的时间粒度差异（月度招生 vs 年度就业）；
- 无法处理口径冲突（如“毕业生数”在教务系统与学工系统统计口径不一致）；
- 一旦某环节逻辑变更，所有下游实例需手动同步，极易遗漏或出错。
更务实的做法：用配置驱动替代代码继承
在 Axure 原型或实际大屏系统中，应通过可视化配置实现链路表达：
- 在指标卡片上标注“由【XX指标】经【XX公式】生成”，点击可跳转溯源；
- 在数据模型层，用 JSON Schema 描述指标依赖关系，供前端渲染拓扑图；
- 在后台服务中，将派生逻辑封装为可注册的计算函数（如
computeEnrollmentToEmploymentRatio），而非继承某个“BaseMetric”类。
