最可控的字符串分割方式是 std::string::find 配合 substr，因其能保留空字段、处理连续分隔符、避免内存重分配，且比 stringstream、Boost split 和 string_view 更精准可控。
std::string::find + substr 是最可控的分割方式
直接用 std::string::find 配合 substr 手动切，比依赖第三方或复杂算法更稳——尤其当你需要保留空字段、处理连续分隔符，或避免内存重分配时。
常见错误是写成 while (pos != std::string::npos) 却忘了更新 pos 为 found + sep.length()，导致无限循环；或者用 substr(pos, found - pos) 时没检查 found == std::string::npos 导致越界。
- 每次调用
find前确认起始位置pos≤ 字符串长度，否则行为未定义 - 若分隔符是单字符（如
' '），用find_first_of更快；多字符分隔符必须用find - 结果 vector 的
reserve()能减少 reallocation：粗略估计分割数 =count(sep) + 1
std::stringstream 不适合按任意字符串分割
std::stringstream 只支持单字符分隔（靠 operator>> 默认跳过空白），强行用它处理 "a;;b;;c" 或 "key=value" 会吞掉空段、错判边界。
典型误用：把整个字符串塞进 stringstream 后用 getline(ss, token, ';') ——这只能处理单字符分隔符 ';'，无法应对 "\t\t" 或 "::"。
立即学习“C++免费学习笔记（深入）”；
- 仅当分隔符确定为单字符（如空格、制表符、换行）且允许丢弃空字段时可用
- 性能上，
stringstream构造和状态维护开销明显高于纯find循环 - 遇到
"a,b,c,"这种末尾带分隔符的情况，getline不会产出最后一个空字符串
避免用 boost::algorithm::split（除非项目已强依赖 Boost）
虽然 boost::algorithm::split 写起来短，但它默认删除空字段、不支持多字符分隔符、且对输入做拷贝——在高频循环或大字符串场景下，堆分配和复制成本不可忽视。
错误认知是“Boost 就是高效”，实际它为了通用性牺牲了控制力：比如无法指定是否保留首尾空段，也无法复用已有 buffer。
- 若必须用 Boost，加
boost::algorithm::token_compress_off参数才能保留连续分隔符间的空段 - 分隔符为字符串时，得配合
boost::is_equal自定义谓词，代码反而更冗长 - 静态链接 Boost 会使二进制体积显著增大，嵌入式或资源敏感环境应绕过
需要高性能？考虑视图化分割（C++17 string_view）
如果只是遍历分割结果而不修改内容，用 std::string_view 替代 std::string 存储子串，能彻底避免内存分配。但注意：原始字符串生命周期必须长于所有 string_view 实例。
容易忽略的是 string_view 的 remove_prefix 和 substr 不改变原数据，但多次调用可能让逻辑变绕——不如直接记 start 和 end 下标清晰。
- 返回
std::vector<:string_view></:string_view>时，确保传入的std::string不会在视图使用前被析构 - VS2019 及更早版本对
string_view::data()的空字符串处理有 bug，必要时加if (!sv.empty())防护 - 跨线程传递
string_view分割结果前，必须确认原始字符串的线程安全生命周期
真正卡住人的往往不是“怎么切”，而是“切完之后要不要改、谁负责生命周期、空段算不算有效数据”。这些决策点比选哪个函数更重要。
