可视化产品做久了，配置面板会越来越长。字号、间距、图例，每一项都有一个合理需求。问题是，用户搭趋势图时，通常只想选数据、定时间、看到结果，不想在空白页面上把全部选项学一遍。

最近做设计器和组件需求，我不再只看能删掉多少配置项。配置怎样参与任务、值从哪里来、改变依赖以后如何处理，更影响实际使用。

配置入口跟着任务走

数据和时间范围决定图表是否有意义，线宽和边距通常是在结果出来以后调整。把它们同层铺开，会让用户在还没看到结果时做一堆暂时无从判断的选择。

常见路径可以缩成选数据、确认字段、看图表，然后按需要调整外观和联动。这个顺序不一定对应三个页签，也不意味着高级功能被删掉。熟练用户仍要能直接找到日常使用的选项。

默认值应覆盖常见情形。选了时间序列数据，可以给出合理图表和时间轴；单位、时间粒度与聚合方式涉及数据含义，推断不确定就说明或确认，不能用一个看起来顺眼的默认值蒙混过去。

一个值必须知道自己从哪里继承

标题字号可能来自系统、主题、页面和组件。如果打开面板时就把最终值写回组件，继承关系会消失，之后换主题也不会变化。

type Setting<T> =
  | {mode: "inherit"}
  | {mode: "override"; value: T};

function resolve<T>(local: Setting<T>, inherited: T): T {
  return local.mode === "override" ? local.value : inherited;
}

inherit 表示跟随上层，override 表示用户固定了值。即使固定值恰好与当前主题相同，也不等于继承。重置应恢复 inherit，而不是填回某个数字。

面板显示“来自主题”，用户才知道换主题是否会影响它。默认值的调整也跟随文档或主题版本管理，不能升级一次就悄悄改变老页面的效果。

配置失效不能靠隐藏控件处理

换数据源后，旧参数可能不再存在；聚合方式变化后，比较模式可能失效；绑定导航器后，一些值由外部输入决定。控件藏起来，旧值却继续影响渲染，这比直接报错更难排查。

属性定义需要类型、范围、默认来源、可见条件和失效行为。失效时是保留但不生效，还是清除，都要有统一约定。界面与服务端共用稳定的校验规则，交互文案另行维护。

结构合法以后，还要检查组件与数据类型的组合。表单能提交，不能代替业务配置可用。

用任务比较改造结果

我准备拿几条常用建图路径做对照，记录首次完成需要主动做的选择、停住的位置，以及熟练用户多走的步骤。必填、默认、依赖和高级入口都包含在记录里。

没有这些观察，就很难判断面板变短究竟是省了操作，还是把同样的工作藏到了别处。配置改造要交付的是可完成的任务路径：常见任务少做无关选择，必要能力仍可找到，失效值不再暗中影响结果。