一句话定义

列类型决定 KNIME 怎么理解这一列的值。同样是 86000，当成数字它可以求和比大小，当成文本它就只是五个字符。类型不对，后面所有操作都会以你没预期的方式工作。

怎么看：列名旁边的小图标。点开任意节点的输出表，每个列名左边都有一个类型图标。这是排查问题时第一个该看的地方 – 比重新配置节点快得多。

类型是从哪来的

读取节点靠扫描前若干行来猜每列是什么类型，扫描行数有上限。这个机制带来两个后果：

脏值藏在扫描范围之外，执行时才炸。前 1000 行全是干净数字，这列被定成数值列；第 3000 行冒出一个「N/A」，跑起来才报错。这解释了为什么同一条流程小文件没事、大文件出错。
换一批数据可能换一种行为。推断结果随数据变化，上个月能跑通的流程这个月可能就不行。所以数据结构固定的场景，建议在读取节点里手工指定列类型，别依赖推断。

症状	说明
排序结果乱七八糟	数字被当文本，按字符逐位比，9 会排在 86000 前面
运算符里没有「大于」	筛选条件的可选运算符随列类型变。只给你文本类的运算符，就是这列是文本
求和失败或结果异常	聚合方法对文本列不适用，或者给出拼接结果
关联一行都配不上，还不报错	左表的编码是文本、右表是数字，KNIME 认为不是同一个东西，全部匹配失败，输出空表

最后一条最阴险 – 前三个至少还看得出不对劲，它是安静地给你一张空表。

身份证号、银行账号、部门编码、邮政编码，一律指定为文本。

被当成数字会出两种事故。一是前导零消失，007 变成 7。二是超过 15 位的数字会被转成科学计数法，末几位直接失真，而且不可逆 – 你在下游做什么都救不回来。

判断标准很简单：这一列你会不会拿去做加减乘除？不会的话，它就该是文本，不管它看起来多像数字。

做法	什么时候用
在读取节点里手工指定	首选。从源头定死，不受推断结果波动影响
String to Number / Number to String	中途需要转换，或者关联前统一两边的类型
String to Date&;Time	文本日期转成真正的日期类型，否则日期排序永远不对
先清洗再转	值里有千分位逗号、货币符号、百分号时，先用 String Manipulation 去掉再转

点开上游节点的输出表，看列名旁边的图标 – 一秒钟的事，能省半小时。