业务方要求报表里“再加一个字段”，开发排期两周。这类需求反复出现，正是元数据驱动报表要解决的问题。它的核心并不在于页面多少，而在于把“报表由哪些字段构成”这件事从代码里抽出来；关键在于能否让配置代替开发。
具体来说，一张报表涉及的信息不止是数据本身：有哪些字段可查、字段显示成什么名字、属于什么类型、能不能筛选、能不能排序汇总、能不能作为计算列、哪些角色能看到、哪些角色能导出。传统做法把这些写死在页面和查询语句里，改一次就要动一次代码。元数据驱动则是把这些描述信息单独维护成一份结构化清单，页面渲染、查询生成和权限校验都读取这份清单。于是加字段、改别名、调整汇总方式，改的是配置，不是程序。
需要强调的是，它并不等于“把字段全开放给业务”。真正可用的元数据驱动，前提是有一份由管理员维护的可控字段清单，业务在这份清单范围内自由组合、保存视图。这个边界往往是成败关键。字段无限开放短期用着痛快，长期会带来两个后果：查询越来越慢，两个人用同一个字段名算出两个数。前者是性能问题，后者是口径问题，后者更难修。
从成本结构看，贵的地方也在这里。元数据层用户看不见，工作量却实打实：字段范围越开放，权限校验、查询性能、测试和维护的成本越高。行业里常见的报价区间中，业务能自建视图、配汇总、选图表，同时后台带字段级权限和导出审计的形态，大致落在十万元到三十万元这一档。差价主要买的是“让业务自己配置”的能力，以及围绕它建立的权限与治理机制，并不在于页面数量。
至于要不要上，判断标准其实不复杂。如果报表需求长期稳定、就那么几张管理层固定看的表，固定报表更划算；如果数据源本身还很乱、口径没统一、字段缺失，先做数据治理，否则元数据驱动只是把混乱放大到业务侧。反之，部门多、报表需求密集、IT 排期长期排不上、口径相对稳定，这套东西的边际价值才会显现。
落地前有一件事比选方案更重要：把要看的报表列清楚，标明每张表的数据来自哪、涉及哪些字段、谁能看、谁能导。这份清单越具体，元数据的设计才有依据，报价也才不会被后期加项撕开口子。
