CSV是数据流动的底层管道，仅靠换行符和分隔符实现跨系统交换，不支持样式、公式、嵌套结构或类型约束；处理时需严控编码、引号转义、引擎选择与空值逻辑。
CSV 文件不是“一种可选格式”，而是数据流动的底层管道——它不负责样式、公式或类型约束，只确保字段能被不同系统原样接收和拆解。
为什么 Excel 和数据库都认 CSV？
因为 CSV 没有格式解析负担：Excel 读它时只做两件事——按 \n 切行、按 , 切列；MySQL 导入时也只依赖字段顺序和分隔符位置。只要双方约定好换行符（\r\n 还是 \n）和引号转义规则（比如字段含逗号时用 "..." 包裹），就能跳过协议协商直接交换数据。
- Windows 系统默认用
\r\n换行，Linux/macOS 用\n；混用会导致某一行“消失”或变成乱码 - 字段里含逗号、换行或双引号时，必须用双引号包裹，且内部双引号要写成两个：
"Shanghai ""Pudong"" Area" - Python 的
pandas.read_csv()默认用engine='c'，遇到不规范 CSV（如缺失引号）会报ParserError；加engine='python'可绕过部分校验，但速度下降 3–5 倍
什么时候不该用 CSV？
当数据本身需要携带结构语义时，CSV 就力不从心了：它无法表达嵌套对象、数组、空值含义（NULL 还是空字符串？）、时间时区、单元格样式或公式。这些信息一写进 CSV 就丢失，再导出回 Excel 时全变文本。
- 导出带公式的 Excel 表 → 不要用 CSV，改用
.xlsx或openpyxl直接写 - 日志中含 JSON 字段（如
{"user_id":123,"tags":["a","b"]}）→ CSV 会把它当普通字符串切开，后续解析得靠额外逻辑兜底 - 字段类型需强约束（如某列必须是日期）→ CSV 不校验，错误数据会静默入库，直到下游报错
用 Python 处理 CSV 时最常踩的坑
pandas.read_csv() 看似简单，但默认行为在真实数据里经常翻车：
- 自动推断
int64列，遇到空值就转成float64（因 NaN 是 float），再存回 CSV 会多出.0 - 中文路径或含 BOM 的 UTF-8 文件，不加
encoding='utf-8-sig'会读成乱码 - 大文件（>500MB）不设
chunksize，直接read_csv()会 OOM；设了又得自己拼pd.concat()，忘了重置索引就产生重复行号 -
sep=','不等于“一定用逗号”——有些系统导出用分号;或制表符\t，硬写逗号会把整行当一列
真正难的从来不是“怎么读 CSV”，而是“怎么确认它被读对了”：字段数是否一致、空值是否被误判、特殊字符是否逃逸完整、编码是否全程统一。这些细节一旦出错，下游所有分析都建立在流沙之上。
