std::string 没有 split() 是因标准委员会刻意克制，避免强加不通用的默认行为；C++20 推荐用 std::string_view + std::views::split_view 实现零拷贝拆分。
为什么 std::string 没有 split() 成员函数？
因为 C++ 标准委员会认为“分割字符串”这件事没有唯一合理的默认行为：按单字符切？按子串切？保留空段？要不要跳过连续分隔符？是否需要正则？不同场景下答案完全不同。强行塞进标准库，反而会让接口变得笨重或误导使用者。
所以它被刻意留白——不是遗漏，是克制。你看到的缺失，其实是设计选择。
std::string_view + std::ranges::split_view 是目前最接近“标准答案”的方案（C++20）
这是目前最轻量、零拷贝、语义清晰的拆分方式，适合只读遍历场景：
std::string s = "a,b,c,,d";
auto v = std::string_view{s};
auto parts = v | std::views::split(',') | std::views::transform([](auto r) { return std::string_view{r}; });
注意几个关键点：
立即学习“C++免费学习笔记（深入）”；
-
std::views::split返回的是视图，不分配内存；但后续std::string_view{r}依赖原字符串生命周期，不能脱离s单独保存 - 它会把
"a,b,c,,d"拆成 5 段（包括两个空段），不会自动跳过空片段 - C++20 要求编译器支持（GCC 10+、Clang 12+、MSVC 19.30+），老项目用不了
手写一个安全、可控的 split() 函数要注意什么？
多数人直接用 find() + substr() 循环，但容易掉进这些坑：
-
std::string::find()找不到时返回std::string::npos，如果没检查就传给substr()，会触发未定义行为（常见 crash） - 用
std::vector<:string></:string>存结果时，默认构造每个std::string会额外分配内存；若已知总长，可先 reserve 再 emplace_back(std::string{...}) 避免多次扩容 - 分隔符是
std::string而非单字符时，别用find_first_of——它匹配任意一个字符，不是子串匹配；该用find - 如果输入含大量空段且业务上要过滤，别在循环里反复
if (!part.empty())，而是后处理或用条件视图（如std::views::filter）
第三方库（如 abseil、Boost）的 Split 为什么看起来更“好用”？
它们靠牺牲通用性换易用性。比如：
-
absl::StrSplit(str, ',')默认跳过空段，absl::SkipEmpty()是显式策略，但底层仍是预分配 vector + find/substr -
boost::algorithm::split支持多种 token_compress 模式，但参数多、头文件重、编译慢 - 它们都回避了“谁拥有结果内存”的哲学问题——直接返回
std::vector<:string></:string>，简单粗暴，也意味着每次调用都有堆分配开销
真正复杂的不是怎么切，是怎么定义“切完之后每一段该怎么活”。有人要 view，有人要 copy，有人要 in-place modify，标准库不替你做这个决定。
