StreamReader逐行读取最稳，因其可控性强，能手动处理空行、双引号包裹等RFC 4180规则场景，避免第三方库在编码、BOM、字段换行等细节上的兼容性问题。
用 StreamReader 逐行读取最稳，别一上来就用第三方库
CSV 文件结构简单，但字段含逗号、换行、引号时，正则或字符串分割会直接崩。原生 StreamReader + 手动解析（跳过空行、处理双引号包裹）反而可控。.NET 自带的 Microsoft.VisualBasic.FileIO.TextFieldParser 虽能自动处理引号转义，但它依赖 VB 运行时，在 .NET Core/.NET 5+ 项目里需额外引用 Microsoft.VisualBasic.Core 包，容易被 CI 环境拒掉。
- 只读纯文本 CSV（无复杂转义）：用
File.ReadAllLines()简单，但大文件（>10MB）会爆内存 - 需要流式处理或带编码识别（如 GB2312）：必须用
StreamReader，显式指定Encoding.UTF8或Encoding.Default - 字段里有回车符（
\r\n）？那一定得按 RFC 4180 规则解析——只有被双引号包裹的字段内才允许换行，否则每行就是一条记录
TextFieldParser 怎么用才不报 MalformedLineException
这个类默认把连续逗号当成多个空字段，但遇到末尾多逗号（a,b,c,,）或开头空字段（,a,b）时，只要没设 HasFieldsEnclosedInQuotes = true，它就会在解析引号时错位，然后抛 MalformedLineException。
- 必须设置
parser.TextFieldType = FieldType.Delimited和parser.SetDelimiters(",") - 如果 CSV 可能含中文引号或字段含逗号，一定要开
parser.HasFieldsEnclosedInQuotes = true - 遇到 BOM 头（
EF BB BF）导致首字段乱码？用new StreamReader(path, Encoding.UTF8)构造再传给TextFieldParser，别让它自己猜编码
用 System.Data.OleDb 读 CSV 是个坑
通过 Provider=Microsoft.ACE.OLEDB.12.0 把 CSV 当数据库查，听着高级，实则限制极多：Windows-only、需装 Access Database Engine、列名超 255 字符截断、数字字段自动转成科学计数、日期格式全靠注册表瞎猜。更糟的是，它默认把第一行当列名，但如果第一行恰好是数据（没标题），就得加 HDR=NO，这时列名变成 F1, F2……根本没法维护。
- 仅适合临时脚本跑一次、且 CSV 格式极其规范（英文列名、无空格、无特殊字符）
- 连接字符串里的
Extended Properties="Text;HDR=YES;"必须写全，漏了Text;会连不上 - 路径不能含中文或空格，否则驱动直接拒绝——得用短路径名（
C:\Temp\csv~1.txt）或改注册表启用长路径支持
第三方库选 CSVHelper 还是 ChoETL？
CSVHelper 文档全、社区大，但默认把空字符串映射成 null（对 string 类型），而你模型里如果字段是 string? 没问题，可要是 string（不可空），它就抛异常；ChoETL 更轻量，支持流式写入和动态列，但配置项藏得深，比如跳过前 N 行得用 .WithFirstLineHeader(false).Configure(c => c.IgnoreEmptyLine = true)。
- 要类型安全映射到 class：用
CSVHelper，但务必调用csv.Read()前设csv.Context.RegisterClassMap，不然字段名对不上() - CSV 列顺序不固定、或者列名带空格/特殊符号：用
ChoETL的WithField("User Name", "UserName")显式绑定 - 大文件导出场景下，
CSVHelper的WriteRecords()默认缓冲整个对象列表，OOM 风险高；得换成Write()+IEnumerable流式推送
真正难的不是读出来，而是判断哪一行该算“有效数据”——比如 Excel 导出的 CSV 常在开头塞几行说明文字，或者结尾加统计行。这种时候，别指望库自动跳过，得自己在 StreamReader 循环里加 if (line.StartsWith("//") || line.Trim() == "") continue;。规则越业务相关，越得手写判断。
