pandas.read_csv() 默认比csv.reader慢因类型推断等开销；提速需设dtype=str、header=None、usecols；校验用csv.Sniffer+reader；DictReader内存恒定，DataFrame全量加载；写入复杂需求必用csv.writer。
读取大文件时 pandas.read_csv() 比 csv.reader 慢很多？
不一定慢，但默认行为下确实常更慢——因为 pandas.read_csv() 默认做类型推断、列名解析、空值处理、索引生成等一整套操作，而 csv.reader 就是纯文本逐行切分。如果你只想要“把 CSV 行变成列表”，csv.reader 几乎总是更快，尤其在 10MB+ 文件上差距明显。
实操建议：
- 用
csv.reader时，确保用open(..., newline='')，否则 Windows 下可能多出空行（Python 3.6+ 必须加） -
pandas.read_csv()想提速，至少关掉三样：dtype=str（禁用类型推断）、header=None（无列名）、usecols（只读需要的列） - 如果只是校验格式或抽样，别用
pandas——csv.Sniffer().sniff()+csv.reader更轻量
csv.DictReader 和 pandas.DataFrame 处理带标题 CSV 的差异
两者都能按字段名访问数据，但语义完全不同：csv.DictReader 是迭代器，每行返回一个 dict，内存占用恒定；pandas.DataFrame 是全量加载到内存的二维结构，支持向量化操作但吃内存。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
把记录数组导出为带样式的 Excel(xlsx) 或带 BOM 的 CSV。支持列配置（表头/宽度/顺序）、表头冻结首行、斑马纹、布尔值转「是/否」、数组换行、CSV 中文防乱码。零依赖。触发词：导出 Excel、导出 CSV、记录转表格、列配置导出、数据导出、表格美化、JSON 转表格。
- 用
DictReader后直接list(reader)把全部数据读进内存——这反而比pandas更没优势 -
pandas读取含混合类型的列（如某列多数是数字但几行是字符串），会自动转成object类型，后续计算变慢且易出错 -
DictReader对重复列名不报错，但只会保留最后一个；pandas直接报ValueError: Duplicate names
写入 CSV：什么时候必须用 csv.writer 而不是 df.to_csv()
当你需要精确控制换行符、引号策略、编码或流式写入（比如边查数据库边写），csv.writer 是唯一靠谱选择。df.to_csv() 默认用系统换行符，且无法在写入中途修改字段内容（比如动态加时间戳），也不支持追加写入时跳过 header。
实操建议：
- 写入含换行符的字段（如用户评论），
csv.writer自动用双引号包裹，to_csv()默认也做，但若设了quoting=csv.QUOTE_NONE就会崩——而csv.writer可显式传quoting=csv.QUOTE_MINIMAL - 要写 GBK 编码文件（比如给老系统用），
open(..., encoding='gbk')+csv.writer直接可用；to_csv(encoding='gbk')在旧版 pandas（ - 写超大文件时，用
csv.writer配合buffered=True的open，比to_csv()的 chunksize 更可控
pandas 的 chunksize 参数真能省内存？
能，但仅限于“分块读取后立刻处理并丢弃”，一旦你把所有 chunk pd.concat() 起来，内存就又涨回去了。很多人以为设了 chunksize=1000 就万事大吉，结果最后还是 OOM。
性能与兼容性影响：
-
chunksize返回的是TextFileReader对象，不是DataFrame，不能直接调.head()或.plot() - 每个 chunk 独立做类型推断，可能导致同一列在不同 chunk 里 dtype 不一致（比如前 chunk 全数字，后 chunk 有字符串）
- 如果文件有 BOM 头，
chunksize模式下只有第一个 chunk 能正确识别编码，后面 chunk 可能解码失败
真正省内存的写法是：用 for chunk in pd.read_csv(..., chunksize=N)，每轮只做聚合/过滤/写磁盘，不做 concat，也不存 chunk 到 list 里。
