必须用逐字符状态机解析CSV：维护in_quotes标志，仅在外层逗号分割；引号内""转义为"；行尾\r\n需预处理；避免>>操作符，用getline或get单字符读取；长字段需reserve或vector缓存。
用 std::getline 配合状态机读取带引号的 CSV 字段
标准库没有内置 CSV 解析器，std::getline 默认按逗号切分完全不可靠——遇到 "apple, banana" 这种字段就直接崩。必须自己维护解析状态：是否在引号内、是否遇到转义引号、是否刚退出引号后碰到逗号。
关键不是“怎么切字符串”，而是“怎么跳过引号内的逗号”。每次读一个字符，用布尔变量 in_quotes 标记当前上下文，遇到 " 就翻转它；只有当 in_quotes == false 且当前字符是 , 时才视为字段分隔符。
- 别用
std::string::find扫描逗号——它无法区分引号内外 - 引号内连续两个
"（即""）表示一个字面量双引号，需合并处理 - 行末没有逗号，但字段可能以引号结尾，所以换行符也要参与状态判断
fgets 或 std::istream::get 比 operator>> 更可控
operator>> 会跳过空白、吞掉引号、误判字段边界，根本没法用。必须逐字符读取，才能精确控制引号配对和转义逻辑。
用 fgets 读整行再手动解析，或用 is.get(c) 单字符读取，两者都比流提取符可靠。前者适合内存充裕场景，后者适合大文件流式处理。
-
std::getline(is, line)可以用，但之后仍要遍历line字符串，不能直接ss >> field - 避免
is >> std::ws，它会吃掉后续字段开头的空格，破坏原始格式 - Windows 行尾
\r\n要提前 trim，否则\r可能混进最后一个字段
字段去引号和转义的边界条件必须显式检查
不是所有带引号的字段都要去掉引号——只有首尾都是 " 且中间无未闭合引号时才算合法引用字段。更麻烦的是 "a""b" 应解析为 a"b，而不是 a""b。
去引号操作必须放在字段收集完成之后，并校验首尾字符。转义处理则要在收集过程中边读边做：遇到 " 后紧跟另一个 "，就只存一个 " 并跳过下一个。
- 空字段
""是合法的，应返回空字符串，不是" -
"abc（缺右引号）属于格式错误，但很多解析器选择忽略并当作普通字段，你要决定是否报错 - 字段里有换行（RFC 4180 允许）？那必须用
std::getline读到匹配的结束引号，不能只认\n
性能敏感时避免频繁 std::string::push_back
每读一个字符就 field += c 或 field.push_back(c)，在长字段下会产生多次内存重分配。尤其当 CSV 里有几 MB 的单字段（如 Base64 编码内容），性能落差明显。
要么预估字段长度用 reserve()，要么改用 std::vector 缓存原始字节，最后一次性构造 std::string。对于纯 ASCII 字段，甚至可考虑 char* + 长度元数据，避免拷贝。
-
std::string的小字符串优化（SSO）对短字段友好，但超过约 15 字符就失效 - 不要在循环里调用
field.capacity()判断，它不反映真实分配开销 - 如果字段后续要转数字，优先用
std::from_chars直接解析char*区间，别先构造std::string
引号嵌套、跨行字段、BOM 头、编码混合——这些都不是“加个 flag 就能解决”的问题。真要健壮，就得接受：CSV 解析器不是工具函数，它是个状态机，而状态机的复杂度藏在边界分支里，不在主干路径上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
