Polars LazyFrame扫描TSV行数与wc -l结果不符的问题

不同工具的统计逻辑、TSV解析规则完全不同，这是导致结果差异的核心原因，具体拆解如下：

1. wc -l 和解析类工具（Polars/vroom）的本质区别 #

wc -l根本不关心TSV格式，它只数文件里的换行符数量：

• 如果你的TSV里有带引号的跨行字段（比如某个字段值包含换行，用引号包起来，这是合法的TSV格式），wc -l会把字段里的换行当成新行，统计数自然比实际数据行数多。
• 如果文件最后一行没加换行符，wc -l会少算一行；要是末尾有多余的空换行，又会多算。

2. Polars不同操作的行数差异 #

Polars是按TSV规则解析数据，统计的是实际有效数据行，差异来自这些细节：

• 默认解析时，Polars会合并带引号的跨行字段，自动跳过空行，还会过滤格式错误的行（比如分隔符数量不对的行），所以统计数肯定比wc -l少。
• 开streaming=True时，Polars是逐块读数据，对格式错误的容忍度更低——非流式可能会尝试修复部分有小问题的行，流式直接跳过，所以行数从7126095降到7125569。
• 分组聚合求和时，product_category为空的行不会被计入统计（sum函数忽略空值），所以结果7125553比流式统计的行数还少。

3. Polars和vroom的行数差异 #

俩都是解析TSV的工具，但默认配置和错误处理不一样：

• 空行处理：vroom默认可能不会跳过所有空行，而Polars默认skip_empty_rows=True，这会导致统计数有差距。
• 格式错误行：比如遇到未闭合的引号、分隔符缺失的行，vroom和Polars的过滤规则不同，有的行vroom能解析，Polars直接过滤，反过来也有可能。
• 编码问题：如果文件里有编码混乱的字符（比如混合了ASCII和UTF-8），俩工具的解码方式不一样，部分行的解析结果就会有差异。

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