string::substr(pos, count)中pos为起始下标（0≤pos≤str.length()合法，pos>str.length()抛异常），count为要取的字符数；误用为区间[i,j]会导致空串或崩溃。
substr 的两个参数到底怎么填
string::substr 只接受两个参数：pos（起始位置）和count（要取的字符数），不是“起始+结束”下标。填错pos会直接抛std::out_of_range，尤其当pos == str.length()时是合法的（返回空串），但pos > str.length()就崩。
常见错误现象：传了str.substr(i, j)以为是在截[i, j]区间，结果要么空，要么崩溃。
-
pos必须满足0 ；越界立即异常 -
count超出剩余长度时，自动截到末尾，不会报错——这是安全的 - 想从第 3 个字符开始取 5 个：用
str.substr(2, 5)（注意下标从 0 开始） - 想取从第 4 个到倒数第 2 个之间的子串？得自己算长度：
str.substr(3, str.length() - 3 - 2)
为什么 substr(0, n) 有时比 substr(0) 还慢
substr(0) 是无参重载，语义上等价于“从开头到结尾”，底层可能复用原字符串的缓冲区（C++11 后多数实现支持 SSO，且不强制拷贝）；而substr(0, n)明确要求长度，编译器无法跳过边界检查和新分配逻辑。
性能影响真实存在，尤其在高频调用、短字符串场景下。实测 clang 15 + libstdc++ 中，substr(0) 比 substr(0, s.size()) 快约 15–20%（小字符串，循环 1e6 次）。
立即学习“C++免费学习笔记（深入）”；
- 如果只是想复制整串，优先用
s.substr(0)或直接赋值string copy = s - 需要精确长度控制时，才用双参数形式
- 不要为了“看起来更明确”而写
substr(0, s.length())——多一次计算，多一次检查
用 substr 提取文件名后缀容易漏掉点
典型场景：从路径 "./src/main.cpp" 中取 "cpp"。直接找最后一个 '.' 然后 substr(pos + 1) 是常见写法，但没考虑 pos == string::npos 或 pos == s.length() - 1（即以点结尾，如 "log."）。
错误现象：程序在某些路径下 crash 或返回空串，调试发现 pos + 1 越界。
- 必须先判断
pos != string::npos - 再判断
pos + 1 ，否则 <code>substr(pos + 1)抛异常 - 更稳妥写法：
size_t pos = s.find_last_of('.'); if (pos != string::npos && pos + 1 - 注意
find_last_of和find_last_not_of不是一回事，别混用
substr 在 C++17 后的移动语义陷阱
C++17 要求 std::string 移动构造/赋值不抛异常，但 substr 本身仍是可能抛 std::out_of_range 的操作——它不参与移动优化，也不受 noexcept 保证约束。
这意味着：你在 noexcept 函数里调用 substr，只要参数不可控（比如来自用户输入的索引），就破坏了异常承诺，编译器可能静默忽略或触发未定义行为。
- 若函数声明为
noexcept，绝不能无防护调用substr - 必要时改用
string_view：它有substr且不抛异常（越界返回空 view），但前提是源数据生命周期可控 - 或者手动做范围检查，把
substr包进try/catch——虽然笨，但明确
事情说清了就结束。最常踩的坑不在语法，而在对 pos 合法性的直觉误判，以及把 substr 当成纯函数来用，忘了它本质是个带边界检查的内存操作。
