CSV导入后数据挤在一行是因换行符不匹配：Windows用\r\n而解析器默认按\n切行，导致整表被当单行；需用十六进制工具确认换行符，pandas中显式指定lineterminator，PostgreSQL中统一换行符并用NEWLINE参数。
CSV 导入后所有数据挤在一行，大概率是换行符不匹配
excel、python pandas 或数据库导入工具读取 csv 时，若源文件用 \r\n（windows 风格），而解析器默认按 \n（unix 风格）切行，就会漏掉换行判断，导致整张表被当成单行字符串处理。这不是编码问题，是行终止符识别失败。
- 先用十六进制编辑器（如 VS Code 打开二进制模式）或
xxd file.csv | head查看末尾字节：出现0d 0a就是\r\n，只有0a是\n - 导出 CSV 的程序（如 Excel、Tableau、某些 BI 工具）默认用
\r\n；但 Linux 服务器上运行的脚本或数据库（如 PostgreSQLCOPY）可能只认\n - 不要依赖文件扩展名或“看起来有换行”——肉眼无法分辨
\r\n和\n，必须查原始字节
pandas read_csv 中显式指定 line_terminator
pd.read_csv() 默认用 Python 内置的 universal newlines 模式，多数情况能自动适配，但在某些压缩流、网络响应或混合换行符文件中会失效。最稳的方式是强制指定 lineterminator 参数。
- 确认是
\r\n：用pd.read_csv("data.csv", lineterminator="\r\n") - 确认是
\r（老 Mac）：用lineterminator="\r" - 注意：
lineterminator和sep无关，别和分隔符混淆；它只控制“哪串字符算一行结束” - 如果文件里本身字段含
\r\n（比如备注列写了换行），这种强制指定反而会出错——此时得先清理字段内换行，再统一换行符
PostgreSQL COPY 命令必须匹配 client_encoding 和 newline
PostgreSQL 的 COPY FROM 对换行符极其敏感，且不自动检测。即使客户端编码设对了，\r\n 在 binary 模式下也可能被截断为 \r，造成后续所有行拼成一行。
- 导入前确保文件换行符统一：用
dos2unix file.csv转成\n，或unix2dos file.csv转成\r\n - 执行
COPY时显式声明：COPY table FROM '/path/file.csv' WITH (FORMAT csv, HEADER true, DELIMITER ',', NEWLINE 'CRLF');—— 注意NEWLINE 'CRLF'是 PostgreSQL 12+ 才支持的语法；旧版本只能靠预处理换行符 - 如果从 stdin 导入（如
psql -c "\COPY ..." ），终端环境的行缓冲和 shell 处理可能二次转义 <code>\r，优先改用绝对路径 +NEWLINE显式控制
Excel 导出的 CSV 在非 Windows 环境下容易“隐形失联”
Excel（尤其 Windows 版）导出 CSV 时，不仅用 \r\n，还会在 UTF-8 文件头部偷偷加 BOM（ef bb bf），某些解析器（如旧版 MySQL LOAD DATA INFILE）看到 BOM 就误判首列为乱码，进而跳过换行识别逻辑，结果全塞进第一行。
- 用
file -i file.csv检查是否带 BOM：charset=utf-8-with-bom就是它 - 去除 BOM：用
sed -i '1s/^\xEF\xBB\xBF//' file.csv（Linux/macOS），或用 Python 重写：open("out.csv", "w", encoding="utf-8").write(open("in.csv", encoding="utf-8-sig").read()) - 更彻底的解法：Excel 导出时选“UTF-8 编码的 CSV（逗号分隔）”，但实际仍带 BOM；不如改用 LibreOffice 导出，或用 pandas
to_csv(..., encoding="utf-8")生成无 BOM 文件
换行符问题从来不是孤立存在的——它总和编码、BOM、工具链默认行为、甚至 SSH 终端设置耦合在一起。排查时别只盯着“有没有换行”，要抓原始字节、看工具文档里 NEWLINE 或 lineterminator 这类关键词，否则修完 A 又冒出来 B。
