报错原文
Configure failed: Column “原值” not found in input table
Input table doesn’t contain the selected column “所属部门”
引号里就是丢失的那一列。注意是 Configure failed 而不是 Execute failed – 这条错在执行之前就报出来了，节点直接变红，根本没跑。
为什么没执行就能报错
节点在配置阶段只看得到上游的表结构 – 列名和列类型的清单，看不到任何一行数据。你在某个节点里选了「原值」这一列，这个选择被记在节点配置里。一旦上游的表结构里不再有这一列，它立刻就知道对不上了。
红的是两个，但真正的原因在前面那个黄灯节点。排查要找第一个变红的，再往上看它的输入。
四个常见来源
| 上游动作 | 为什么会触发 |
|---|---|
| Column Filter 排除了这一列 | 最常见。清理列的时候顺手多删了一个 |
| Column Renamer 改了列名 | 列还在，但名字变了，对下游来说等于没了 |
| GroupBy 或 Pivoting 改写了列名 | 输出列名带上了聚合方法，比如变成 Sum(原值) |
| 换了一批数据，源文件列名不一样 | 这个月的报表模板改了，或者导出时多了一个空格 |
最后一种最难查，因为工作流一个字都没改。先点开读取节点的输出表，把列名和上个月的对一遍。人工填报的表格最容易出这种事。
怎么定位
- 找第一个变红的节点。后面跟着红的都是被连带的，改它们没用。
- 点开它上游节点的输出表，看列名那一行。报错里点名的那一列在不在？不在，就继续往上一个节点看 – 一直找到这一列还存在的地方，问题就出在那个节点上。
- 确认是删掉了还是改名了。列数少了一列是删掉，列数没变但名字不一样是改名。两种修法不同。
怎么修
-
列是被误删的
回到 Column Filter 把它加回来。顺便检查「以包含为准 / 以排除为准」这一项 – 如果选了以包含为准，源数据以后新增的列都会被丢弃，同类问题还会再来一次。
-
列名变了，但列还在
打开报红的那个节点，重新选一遍列。如果下游有好几个节点都受影响，一个个改会很烦 – 更稳的做法是在改名的地方之后统一接一个 Column Renamer，把列名固定成一套下游认得的名字。
-
上游是 GroupBy 或 Pivoting
这类节点的输出列名不受你控制，还会随聚合方法和数据取值变化。紧跟着接一个 Column Renamer 把列名定死，等于给下游立了一份稳定契约。这是这类报错最治本的做法。
-
源数据列名变了
先确认是不是多了空格或者全角半角差异 – 这两种肉眼看不出来。真是模板改了，就在读取节点之后加一步改名，把新列名映射回流程原本认识的名字，流程主体不用动。
怎么预防
- 凡是会改写列名的节点（GroupBy、Pivoting、Joiner），后面紧跟一个 Column Renamer。
- 删列尽量集中在一处、尽量靠前，别在流程中段东删一个西删一个。
- 源数据不稳定时，读取之后立刻加一步列名规范化，把不确定性挡在流程入口。
