std::getline默认按'\n'读行，不解析制表符；需先按行读取再用stringstream以'\t'分割字段，注意处理BOM、换行差异及空字段丢失问题。
为什么 std::getline 读不出完整的制表符分隔行？
因为默认的 std::getline 用换行符 '\n' 当分隔符，但不会自动处理行内制表符；它只负责“按行切”，切完之后，你拿到的是一整行字符串（含多个 '\t'），后续得自己拆。很多人误以为它能直接按 '\t' 切字段，其实不能。
常见错误现象：
— 读出来整行是 "Alice\t25\tEngineer"，但没进一步解析，就当一个字符串用了
— 用 std::getline(in, field, '\t') 却发现第一字段后就卡住或漏数据——那是因为文件末尾没跟 '\t'，最后一个字段后面是 '\n'，不是 '\t'
- 正确做法：先用
std::getline(in, line)按行读，再用std::stringstream对line做字段切分 - 别对整个文件流反复调用
std::getline(..., '\t')，容易因换行/制表混用导致偏移 - 注意 Windows 换行是
"\r\n"，若文件带'\r'，要提前去掉，否则第一个字段可能含'\r'
用 std::stringstream 拆 '\t' 字段时，operator>> 为什么吃掉空字段？
operator>> 是格式化输入，会跳过所有空白（包括 '\t' 和开头空格），所以 "a\t\tc" 会被读成 "a"、"c"，中间空字段直接消失。这不是 bug，是设计如此。
使用场景：你需要保留空字段（比如 CSV/TXT 中表示缺失值的连续 \t\t）时，就不能用 >>。
立即学习“C++免费学习笔记（深入）”；
- 改用
std::getline(ss, field, '\t')—— 它按字面字符切，不跳空白，能捕获空字符串 - 记得每次切完检查
ss.fail()或ss.eof()，因为最后一字段后是'\n'，不是'\t'，getline可能失败但仍有有效数据 - 示例：
std::stringstream ss(line); std::string a, b, c; std::getline(ss, a, '\t'); std::getline(ss, b, '\t'); std::getline(ss, c);—— 最后一个不用指定 delimiter，让它吃到流末
遇到中文路径或含 BOM 的 UTF-8 文件，std::ifstream 直接打不开或首字段乱码？
标准 C++ iostream 不原生支持宽字符路径，也不自动识别 UTF-8 BOM（"\xef\xbb\xbf"）。Windows 下用中文路径会失败；带 BOM 的文件，前三个字节被当正文，导致首字段多出乱码。
- 路径问题：Windows 上优先用
std::wifstream+std::filesystem::path，或把路径转为 UTF-8 后用_setmode(_fileno(stdin), _O_U16TEXT)类机制（较重，非必要不推） - BOM 问题：打开后先读 3 字节判断是否
"\xef\xbb\xbf"，是则跳过；或者用std::ifstream::peek()预检 - 更稳的做法：用第三方库如
utf8cpp或直接上std::fstream二进制模式读，自己处理编码（多数工程中，约定文件为无 BOM UTF-8 更省事）
性能敏感时，反复构造 std::stringstream 真的慢吗？
是的，尤其在每行几十字段、百万行规模下，std::stringstream 构造/析构+内存分配有可观开销。它本质是带缓冲的 std::stringbuf，不是零成本抽象。
可替代方案不多，但有明确优化点：
- 复用同一个
std::stringstream：每次ss.str(line); ss.clear();，比新建快 10%–20% - 避免
std::getline(ss, ...)多次调用：改用const char*手动扫描'\t'和'\n'，配合std::string_view（C++17+）切片，零拷贝 - 如果字段数固定且已知（如 3 列），直接用
std::find_first_of定位'\t'位置，比流式解析快一倍以上
真正难处理的是混合换行、嵌套制表、引号包裹字段这些——这时候该换 csv-parser 库，别硬刚 stringstream。
