解析Spark StringIndexer约束：inputCols与outputCols为何不能相同？

• 数据类型冲突的硬约束
  StringIndexer的核心作用是将字符串（或离散数值）列转换为整数索引列，输入输出的数据类型完全不同（比如StringType → IntegerType）。Spark的DataFrame schema不允许同一列同时存在两种数据类型，因此复用列名会直接触发schema校验错误。而Imputer的输入和输出都是数值类型（如DoubleType），类型完全匹配，覆盖列名不会产生schema冲突。

• 防止不可逆的数据丢失
  StringIndexer生成的索引是对原始字符串的映射替换，一旦覆盖原列，原始字符串数据会被彻底清除——后续要做特征回溯、关联原始业务数据都会变得不可能。这种限制是刻意的防护机制，强制用户保留原始列，避免不可逆的误操作。而Imputer只是填充缺失值，输出是对原列有效数据的补全，即便覆盖也不会丢失任何关键信息，风险极低。

• 避免索引映射的歧义
  StringIndexer的索引映射规则（比如"apple"→0、"banana"→1）是在拟合阶段基于输入列的唯一值生成的。如果允许输入输出列同名，后续管道执行（比如重新拟合或处理新数据）时，系统会混淆：到底是基于原始字符串列还是已转换的索引列来生成映射？这种歧义会直接导致错误的索引结果。而Imputer的填充逻辑（均值/中位数）仅依赖输入列的数值分布，不存在这类依赖混淆问题。

• API设计的场景区分原则
  Spark的转换器设计会根据操作的“破坏性”做区分：对于不可逆转换操作（如StringIndexer、OneHotEncoder），强制使用新列名是为了引导用户谨慎处理数据；对于增强型转换操作（如Imputer、StandardScaler），允许覆盖原列是因为操作是对原数据的补充而非替换，不会带来不可逆风险。这种设计是为了平衡灵活性和数据安全性。

内容的提问来源于stack exchange，提问作者jsn