regionmatches() 更省内存是因为它不创建新字符串对象，仅在原字符数组上通过索引偏移和逐字符比较完成匹配，避免 substring().equals() 频繁分配对象导致的 gc 压力。
regionMatches() 为什么比 substring().equals() 更省内存
直接用 substring() 截取再比较，会创建新字符串对象，对大字符串（比如几 MB 的日志片段或 XML 内容）频繁调用时，GC 压力明显上升。而 regionMatches() 完全不分配新对象，它只在原字符数组上做索引偏移和逐字符比对——只要传入的起始位置、长度合法，底层就是 Arrays.equals(char[], int, char[], int, int) 那一套逻辑。
实操建议：
- 确保
toffset和otherOffset都 ≥ 0，且各自加上len不越界（否则抛IndexOutOfBoundsException） - 若需忽略大小写，用带
ignoreCase参数的重载，但注意：它内部会调用Character.toLowerCase()，对非 ASCII 字符（如中文、德语变音符号）行为稳定，但比纯字节比较慢一丢丢 - 避免在循环里反复计算偏移量，把
start、end提前算好再传入
区分两种重载：boolean regionMatches(...) vs int regionMatches(...)
Java 标准库只有返回 boolean 的两个重载：regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len) 和 regionMatches(int toffset, String other, int ooffset, int len)。不存在返回 int 的版本——如果看到别人代码里写了 regionMatches(...) 返回整数，那要么是自定义封装方法，要么是看错了 API。
常见错误现象：
- 误以为能返回匹配位置或长度，结果编译失败：找不到对应方法签名
- 把
String.indexOf()和regionMatches()混用，想“先找位置再比”，其实没必要——你已经知道要比较哪一段了 - 传错
len：比如想比 5 个字符却传了6，导致越界异常；或者传了0，虽然合法但容易掩盖逻辑漏洞
和 equals()、compareTo() 在性能与语义上的关键差异
regionMatches() 是局部比较，equals() 是全串等值判断，compareTo() 是字典序比较——三者目的不同，不能互相替代。拿 regionMatches() 去替代 substring().equals() 是合理优化；但拿它去替代 str1.equals(str2) 就得先确认你真的只需要比其中一段。
使用场景举例：
- 解析协议头：检查 HTTP 请求行是否以
"GET "开头 →req.regionMatches(0, "GET ", 0, 4) - 跳过 BOM：读取 UTF-8 文件后，判断前 3 字节是不是
EF BB BF→ 构造一个含 BOM 的临时字符串，用regionMatches(0, bomStr, 0, 3) - 字段对齐校验：两个超长 CSV 行，只比第 3 列（已知起始/结束索引），不碰其余部分
注意 charAt() 边界和 surrogate pair 的隐含风险
regionMatches() 按 char 索引操作，不是按 Unicode 码点。如果字符串含 emoji 或某些生僻汉字（即需要两个 char 表示的代理对），而你恰好把偏移量卡在代理对中间，比出来的结果可能不符合预期——比如本意是跳过一个 ?（U+1F40D，占 2 个 char），却只跳了 1 个 char，导致后续区域错位。
实操建议：
- 若业务明确涉及 emoji 或国际化文本，优先用
String.codePointCount()和String.offsetByCodePoints()计算真实码点偏移，再转成char索引传给regionMatches() - 简单场景（如纯 ASCII 协议字段、数字 ID）可忽略此问题，
char索引完全够用 - 别依赖
regionMatches()做“模糊匹配”或“子串搜索”——它不支持通配符、正则，也不返回位置
