regionMatches() 更适合局部匹配，因其不创建新字符串对象，直接在原字符串底层数组上逐字符比较，避免内存分配和复制开销；而 substring() + equals() 在 Java 9+ 必然拷贝且需额外遍历，性能更差。
regionMatches() 为什么比 substring() + equals() 更适合局部匹配
因为 regionMatches() 不创建新字符串对象，直接在原 String 的底层 char[]（或 byte[]，Java 9+）上做逐字符比较，避免了内存分配和复制开销。而 substring() 在 Java 8 及之前会共享原数组（看似轻量），但 Java 9+ 改为**必然拷贝**，且后续再调用 equals() 还要额外遍历 —— 两步变三步，GC 压力和 CPU 时间都更高。
实操建议：
- 只要目标是「检查某段是否等于某固定短串」，优先用
regionMatches()，别先切再比 - 注意：
regionMatches()的起始索引和长度必须落在源字符串有效范围内，否则抛StringIndexOutOfBoundsException，需提前校验 - 若需忽略大小写，用带
ignoreCase参数的重载（boolean regionMatches(boolean ignoreCase, int toffset, String other, int ooffset, int len)），它内部用Character.toLowerCase()逐字符比对，比先转小写再比更省内存
如何安全传参：toffset、ooffset、len 三者关系怎么算
这是最常出错的地方：三个参数不是“任意填”，而是强约束的。例如想检查 text 从索引 5 开始的 3 个字符是否等于 pattern 的前 3 个字符，不能只写 text.regionMatches(5, pattern, 0, 3) 就完事 —— 必须确认 5 + 3 ≤ text.length() 且 0 + 3 ≤ pattern.length()，否则运行时崩溃。
实操建议：
- 把长度校验写进匹配逻辑前：用
Math.min(len, text.length() - toffset)动态截断？不行 ——regionMatches()要求len精确匹配，多传或少传都会导致语义错误 - 正确做法：先判断
toffset >= 0 && toffset + len = 0 && ooffset + len ，不满足直接返回 <code>false - 如果
pattern是编译期已知的字面量（如"http"），可把len写死为"http".length()，避免 magic number
模糊搜索中结合 regionMatches() 的典型模式：滑动窗口匹配
在实现类似「字符串中是否存在连续子串近似匹配某关键词」时（比如日志行里找 "ERROR" 但允许前后有空格或括号），regionMatches() 常作为内层校验函数嵌入循环。它的低开销让这种 O(n×m) 暴力扫描在中小数据量下依然可控。
实操示例（查找不区分大小写的 "error"，允许前后最多 1 个空白字符）：
String line = "[ ERROR ] connection failed";
String target = "error";
int targetLen = target.length();
for (int i = 0; i <= line.length() - targetLen; i++) {
// 跳过开头空白
if (Character.isWhitespace(line.charAt(i))) continue;
// 检查从 i 开始 targetLen 长度是否匹配（忽略大小写）
if (line.regionMatches(true, i, target, 0, targetLen)) {
System.out.println("Found at index: " + i);
break;
}
}注意点：
- 这里没做前置边界检查，因为循环条件
i 已隐含保证 <code>i + targetLen - 若需支持更多“模糊”规则（如通配符、编辑距离），
regionMatches()就不再适用，得换用Pattern或 Levenshtein 算法 - Java 21 的
String.strip()或trim()不解决局部匹配问题，别误用
regionMatches() 在不同 JDK 版本下的行为差异
Java 9 引入紧凑字符串（compact strings），String 内部可能用 byte[] 存 ASCII 字符。此时 regionMatches() 会根据编码自动选择路径：纯 Latin-1 字符走 byte 比较，含 Unicode 则回退到 char 比较。性能差异明显，但对外透明。
实操提醒：
- 不要依赖
regionMatches()对 surrogate pair（如 emoji）的处理细节 —— 它按 code unit 比较，不是按 code point；若 pattern 含 emoji，确保传入的len是codePointCount()而非length() - Android 上（尤其旧版本）
regionMatches()实现略有不同，若跨平台，请用Build.VERSION.SDK_INT >= Build.VERSION_CODES.O做兜底 - 在 hotspot JIT 下，简单
regionMatches()调用常被内联，但若混用大量条件分支，可能影响优化效果
真正难的不是调用这个方法，而是想清楚你要比的是「字节序列」「字符序列」还是「语义等价」——regionMatches() 只管前者，后两者得靠别的机制补全。
