strtok不能直接处理const char*字符串，因为它会原地修改输入字符串，在分隔符位置写入'\0'，而字符串字面量存于只读内存区，修改将导致段错误；首次调用需传入可写字符串指针，后续必须传null以延续分割状态；其依赖静态变量保存扫描位置，故线程不安全，应改用strtok_r等可重入版本。
strtok 为什么不能直接处理 const char* 字符串
strtok 会原地修改输入字符串，在每个分隔符位置写入 \0，所以它要求第一个参数是可写的 char*。传入字符串字面量（如 "a,b,c"）或 std::string::c_str() 返回的 const char* 会导致未定义行为——常见表现是程序崩溃或段错误。
实操建议：
- 用栈上数组初始化：
char buf[] = "a,b,c";，再传buf - 用
std::vector<char></char>或std::string+&data()[0]（C++11 起保证连续）构造可写缓冲区 - 别对
std::string直接调c_str()后强转，这是高危操作
strtok 第一次调用和后续调用的区别
第一次调用必须传入待分割的字符串指针；之后所有调用必须传 nullptr，让 strtok 继续从上次结束位置往后找。混用（比如第二次又传原始字符串）会导致跳过中间字段或无限循环。
常见错误现象：只拿到第一个 token，后续全为 nullptr；或者反复拿到同一个子串。
示例片段：
char buf[] = "apple,banana,cherry";
char* tok = strtok(buf, ",");
while (tok != nullptr) {
printf("%s\n", tok);
tok = strtok(nullptr, ","); // 注意这里是 nullptr，不是 buf
}
strtok 的线程安全性与替代方案
strtok 内部用静态变量保存当前扫描位置，因此它不是线程安全的。多线程环境下同时调用会相互覆盖状态，结果不可预测。
如果你在多线程中需要分割字符串，必须改用：
-
strtok_r（Linux/glibc）：增加一个额外的char** saveptr参数，状态由调用方管理 -
strtok_s（MSVC）：类似，但参数顺序和语义略有不同 - C++11 起更推荐用
std::string配合find/substr手动切分，或用std::stringstream+getline（适合单字符分隔符）
性能影响：strtok 原地修改、无内存分配，比纯 C++ 方案快；但线程不安全这点在服务端代码里往往比性能更重要。
strtok 对连续分隔符和首尾空格的处理逻辑
strtok 把连续的分隔符视为一个整体，自动跳过；开头和结尾的分隔符也被忽略。例如 " , a ,, b , " 用 "," 分割，只会得到 " a " 和 " b " 两个 token——注意前后空格仍保留。
这意味着它不适合需要保留空字段的场景（比如 CSV 解析中 "a,,c" 应该产出三个字段）。这时候必须自己实现基于 find_first_not_of / find_first_of 的分割逻辑。
容易被忽略的地方：很多人以为 strtok 会“按分隔符个数拆”，其实它只关心“有没有”，不计数也不留空。如果业务逻辑依赖空字段占位，strtok 就不该出现在你的调用栈里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
