近日，不少Python开发者在使用csv.writer模块编写CSV文件时，发现一个令人困惑的现象：在Windows操作系统上，每一行数据之间会莫名其妙地多出一个空白行。这一看似“诡异”的问题，实则源于Python底层对换行符处理的差异，以及Windows与类Unix系统（如Linux、macOS）行尾约定之间的历史遗留冲突。
问题重现：一行代码引发的空行
通常情况下，开发者会编写类似以下的代码：
import csv
with open('output.csv', 'w', newline='') as f:
writer = csv.writer(f)
writer.writerow(['姓名', '年龄'])
writer.writerow(['张三', 25])
如果省略newline=''参数，即在open()函数中未指定该参数，那么在Windows上运行程序生成的CSV文件，用记事本或Excel打开时，会发现实际内容变成了：
姓名,年龄
张三,25
每一个数据行之后紧跟着一个空行。在Linux或macOS上，同样的代码却不会出现此问题。这一差异让不少跨平台开发者感到头疼。
根源剖析：换行符的“混血”冲突
要理解这一问题，需要先了解Python的csv模块的工作机制。csv.writer在写入一行数据后，会自动附加一个行结束符（默认是\r\n，即回车+换行，符合Windows的CSV标准）。同时，open()函数在文本模式下写入时，也会对换行符进行自动转换：在Windows上，\n会被转换为\r\n；在Unix系统上则保持\n不变。
当这两层机制叠加时，问题就出现了：csv.writer写入\r\n，然后文件对象在文本模式下看到\n，又将其转换为\r\n，最终导致每一行末尾实际写入的是\r\r\n（两个回车加一个换行）。大多数CSV解析器和文本编辑器将这种双重回车视为行结束后的额外空行，于是多了一个空行。
更准确地说，csv.writer默认使用\r\n作为lineterminator，而文件以文本模式打开时，Python在Windows上会做一次\n到\r\n的转换，但csv模块写入的\r\n中的\n被额外转换后，变成了\r\n\r\n，即两个行结束符，中间恰好夹着一个空行。
官方解决方案：只需一行修改
Python官方文档早已明确指出：为了正确使用csv模块，应当以二进制模式或指定newline=''的方式打开文件。最推荐的做法是：
with open('output.csv', 'w', newline='') as f:
writer = csv.writer(f)
# 写入数据...
设置newline=''会禁止Python在文本模式下对换行符进行任何自动转换，从而让csv.writer完全控制行结束符的生成。这样写出的文件不会有重复的换行符。
另一种替代方案是以二进制模式打开：
with open('output.csv', 'wb') as f:
writer = csv.writer(f)
# 注意：二进制模式要求写入的数据为字节对象，通常仍需配合其他处理
但二进制模式较为繁琐，因为csv.writer默认写入的是字符串而非字节数据。因此，设置newline=''最为简洁通用。
跨平台陷阱与开发建议
许多新手开发者从未在Windows上调试过CSV写入代码，一旦从macOS迁移到Windows，就容易掉入这个“换行符陷阱”。实际上，这一问题从Python 2时代就已存在，直到Python 3的newline参数被明确引入。
此外，部分第三方库（如pandas的to_csv方法）也内建了line_terminator参数，允许开发者自行指定行结束符。但底层原理相同：如果文件不是以二进制或newline=''模式打开，在Windows上写入CSV时都可能出现多余的空行。
对于企业级项目，建议开发者始终在文件打开时显式写明newline=''，并养成跨平台测试的习惯。同时，在代码注释中标注“Fix Windows CSV blank line issue”，以提醒后续接手者。
行业回响：一个经典Bug的启示
这个问题在Stack Overflow上已有超过50万次浏览，被列为Python新手最常遇到的十大坑之一。甚至有开发者调侃：“不是在写CSV，而是在写一份空行表。” 微软的Power Query和Excel也会因这种双重换行而错误地解析数据，导致后续数据分析流程出现偏差。
虽然看似是个小问题，但它提醒我们：跨平台开发中，即便是一行换行符的差异，也可能带来数小时的调试时间。理解操作系统的文本处理哲学，才能写出真正鲁棒的代码——恰如那位程序员博客中所言：“我没有写bug，我只是在和Windows的历史遗留博弈。”