substring(int beginIndex)合法索引范围是0到字符串长度（含），如"abc".substring(3)返回""，但substring(4)越界；空串时s.length()-1为-1会抛异常，需先判空；substring(begin,end)为左闭右开区间，长度等于end-begin。
substring(int beginIndex) 怎么用才不会越界
这个重载方法只传一个起始位置，截取从 beginIndex 到字符串末尾的所有字符。容易出错的地方是：索引从 0 开始，但最大合法值是字符串长度（不是长度减 1）。比如 "abc".length() 是 3，"abc".substring(3) 返回空字符串 ""，不报错；但 "abc".substring(4) 就抛 StringIndexOutOfBoundsException。
常见误判场景：想取最后一个字符，写成 s.substring(s.length()-1) —— 这其实是对的；但若 s 是空串 ""，s.length()-1 就是 -1，直接崩。
- 安全写法：先判空或长度，再调用
- 注意：空字符串、null 都要单独处理，
substring不处理 null - 性能上无额外开销，底层是共享原字符串的 char 数组（Java 7u6 之后已改为复制，避免内存泄漏）
substring(int beginIndex, int endIndex) 的区间到底是左闭右开还是左闭右闭
答案是左闭右开：beginIndex 包含，endIndex 不包含。也就是说，结果长度 = endIndex - beginIndex，且 endIndex 必须 ≥ beginIndex，也必须 ≤ 字符串长度。
典型翻车现场："hello".substring(1, 3) 返回 "el"，不是 "ell"；有人误以为第二个参数是“取几个”，写成 s.substring(i, i+2) 却没检查 i+2 ，一越界就挂。
立即学习“Java免费学习笔记（深入）”；
-
endIndex可以等于s.length()，此时等价于单参版本 - 如果
beginIndex == endIndex，返回空字符串""，合法 - Android 上低版本（API substring(0, 0) 有极个别兼容性问题，但现代 JDK / Android 已无碍
为什么 substring 后的字符串有时还和原字符串共用底层数组
Java 7u6 之前，substring 内部不复制 char 数组，只是新建一个 String 对象，指向原数组的某一段 offset + count。这意味着：即使你只截了 2 个字符，只要原字符串很大（比如读了一个 MB 级日志），这个小子串就一直 hold 着整个大数组，导致内存泄漏。
7u6 及之后改了实现：所有 substring 都会显式复制对应范围的字符。所以现在不用再手动加 new String(s.substring(...)) 来“断连”了——那行代码反而多一次复制，纯属过时习惯。
- 如果你在维护老 JDK 6 项目，仍需警惕该问题
- 可通过反射查看
value字段确认是否共享（不推荐生产用） - 现代 GC 对短生命周期小字符串很友好，不必为这个微优化提前构造
替代方案：用 String 方法切分比 substring 更安全的场景
当你要按固定分隔符（如 "|"、","）截取，或者要跳过前缀（如去掉 "prefix_"），硬算下标容易错。这时候优先考虑 startsWith + substring 组合，或更声明式的 replaceFirst / split。
例如去前缀：s.startsWith("v1_") ? s.substring(3) : s 比 s.substring(3) 直接调用安全得多；又如取中间字段："a|b|c".split("\|")[1] 比手算两个 indexOf 加两个 substring 更直观（但注意 split 正则开销略高，且空字段处理需留意）。
- 正则类方法（
split,replaceFirst）会编译 Pattern，高频调用建议复用 Pattern 实例 -
substring是零分配（JDK 8+）、零正则、纯下标操作，性能最稳 - 真正复杂的切分逻辑（如嵌套结构、忽略引号内分隔符），别硬刚 substring，该上 parser 就上
事情说清了就结束。最常被忽略的是：空字符串和 null 的边界检查，不是语法问题，是运行时崩点。
