ParserError 根本原因是 pandas.read_csv() 解析时某行字段数与预期列数不一致，典型报错为“Expected x fields in line y, saw z”，主因是分隔符、引号、换行符或缺失值处理与实际数据不匹配。
ParserError 常见触发场景和根本原因
ParserError 本质是 pandas.read_csv() 在解析 CSV 行时，发现某一行的字段数与预期列数不一致。最典型的现象是报错信息里带 Expected x fields in line y, saw z。这不是编码问题，也不是文件损坏，而是分隔符、引号、换行符或缺失值处理逻辑与实际数据不匹配。
常见诱因包括：
- CSV 中某行字段含未转义的换行符（比如单元格里写了多行文本，又没用双引号包裹）
- 字段内容本身含逗号（但未用双引号包围），导致 pandas 错判列边界
- 文件末尾有多余空行或不完整行（如只有部分字段就断了）
- 使用了非标准分隔符（如
\t或|），却没显式指定sep
绕过解析失败：用 error_bad_lines=False 还是 on_bad_lines？
旧版 pandas（error_bad_lines=False 跳过异常行，新版已弃用，必须改用 on_bad_lines='skip' 或 on_bad_lines='warn'。
但要注意：on_bad_lines='skip' 是「静默丢弃」，不会告诉你哪几行被跳过了——如果数据质量关键，这反而掩盖问题。更稳妥的做法是先定位坏行：
立即学习“Python免费学习笔记（深入）”；
import pandas as pd
try:
df = pd.read_csv("data.csv")
except pd.errors.ParserError as e:
print(e) # 直接输出哪一行、预期多少列、实际看到多少列
再配合 lineterminator 或手动用 Python 内置 csv 模块逐行检查，比盲目跳过更可靠。
从源头修复：控制分隔符、引号和换行行为
真正稳定的解法不是跳过错误，而是让 read_csv() 理解你的数据格式。关键参数组合如下：
- 如果字段含换行或逗号，确认源文件是否用双引号包裹字段 → 加
quotechar='"'和quoting=csv.QUOTE_MINIMAL（需import csv） - 如果字段内有真实换行符，必须设
lineterminator='\n'（默认其实也是，但某些 Windows 导出 CSV 会混用\r\n，可试lineterminator='\r\n'） - 如果分隔符不是逗号，必须显式写
sep='|'或sep='\t'，别依赖自动推断 - 遇到末尾不完整行，加
skip_blank_lines=True（默认 True），但对“半截字段”无效；此时可加engine='python'（比默认c引擎容错更强，只是稍慢）
当所有参数都失效：降级用 csv 模块 + 手动清洗
pandas.read_csv() 的设计目标是快和通用，不是鲁棒。遇到 Excel 导出的畸形 CSV、日志拼接的伪 CSV、或嵌套 JSON 当字段的混合体，硬调参数往往徒劳。
这时直接切到 Python 原生 csv 模块，按需处理：
import csv
rows = []
with open("data.csv", newline="", encoding="utf-8") as f:
reader = csv.reader(f, delimiter=",", quotechar='"', skipinitialspace=True)
for i, row in enumerate(reader):
if len(row) != expected_col_count: # 比如你知道该有 5 列
print(f"Bad row {i}: {row}")
continue # 或做自定义修复，如拼接下一行
rows.append(row)
df = pd.DataFrame(rows[1:], columns=rows[0]) # 假设首行为 header
这种写法可控性最强，也最容易加日志、计数、字段校验——只是多写几行，但省去反复试参的时间。
解析 CSV 的难点从来不在“怎么读”，而在“数据到底长什么样”。哪怕加了 quoting 和 engine='python'，只要源数据没统一规则，就总有漏网之鱼。动手前先用 head -n 20 data.csv 或 VS Code 打开看真实结构，比查文档更快。
