应使用Microsoft.VisualBasic.FileIO.TextFieldParser而非string.Split(',')解析CSV，因其自动处理引号包裹、双引号转义（""→"）和跨行字段；需设置TextFieldType=Delimited、SetDelimiters(",")及HasFieldsEnclosedInQuotes=true。
CSV字段含双引号时，string.Split(',') 会直接失效
因为标准csv允许字段用双引号包裹（比如 "john, jr.","2024-03-15","123 ""main"" st"），此时用 split(',') 会把带逗号的字段错误切开。这不是“分得不够细”，而是逻辑上就不该用字符串分割——它根本不知道引号配对和转义规则。
实操建议：
- 别手写解析器，除非你明确要控制每个字节；C# 标准库有更稳妥的选择
-
Microsoft.VisualBasic.FileIO.TextFieldParser是.NET内置、轻量、专为CSV设计的解析器，无需额外NuGet包（.NET Core 3.1+ / .NET 5+ 默认可用） - 它自动处理：引号包裹、引号内双引号转义（
""→"）、跨行字段（当启用了HasFieldsEnclosedInQuotes = true）
用 TextFieldParser 正确读取带引号的CSV行
关键不是“怎么拆”，而是“怎么按CSV语义读”。它把整行当作一个记录，内部按RFC 4180兼容方式解析字段，比手动状态机可靠得多。
实操建议：
- 必须设置
TextFieldType = FieldType.Delimited和SetDelimiters(",") - 必须开启
HasFieldsEnclosedInQuotes = true，否则它不会识别引号包裹逻辑 - 输入流需是
TextReader（如StringReader或StreamReader），不能直接传字符串 - 示例片段：
using Microsoft.VisualBasic.FileIO;
using (var parser = new TextFieldParser(new StringReader(@"""a,b"",""c""""d""",e"))) {
parser.TextFieldType = FieldType.Delimited;
parser.SetDelimiters(",");
parser.HasFieldsEnclosedInQuotes = true;
string[] fields = parser.ReadFields(); // → ["a,b", "c\"d", "e"]
}
为什么不用 System.Text.Json 或 Newtonsoft.Json 解析CSV
它们是JSON解析器，不是CSV解析器。强行用JSON反序列化CSV字符串，等于把 "a,b","c""d",e 当作JSON数组去parse，结果必报错：JsonReaderException: Expected start of object or array。
常见错误现象：
- 把CSV行拼成类似
["a,b","c""d",e]再喂给JsonSerializer.Deserialize—— 这不是修复，是制造新格式错误 - 忽略CSV中无引号字段（如末尾的
e）不加引号是合法的，但JSON要求所有字符串必须引号包裹 - 引号转义规则不同：CSV用
""表示字面量双引号，JSON用\"；混用会导致解析错位
性能与兼容性：什么时候该换 CsvHelper
TextFieldParser 足够应对单次小批量（几千行以内）、无复杂映射的场景。但遇到这些情况，它就吃力了：
- 需要绑定到强类型对象（如
class Order { public string Name { get; set; } }） - 字段顺序不固定、有Header行、需跳过空行或注释行
- 要处理GB2312/Shift-JIS等非UTF-8编码，且不想手动包装
StreamReader - 吞吐量要求高（>10万行/秒），且能接受引入NuGet依赖
这时用 CsvHelper 更稳：csv.GetRecords 自动对齐Header、支持自定义转换器、可配置引号/转义/空值策略。但它不是“更高级的Split”，而是另一套抽象层级——别指望它让 Split 变好使，它是用来替代手动解析流程的。
容易被忽略的一点：CSV没有唯一标准，Excel导出、PostgreSQL COPY、Python csv.writer 的默认行为都略有差异。真正健壮的处理，永远得先确认数据来源的生成规则，而不是只盯着自己写的那几行代码。
