处理大型数据时应避免字符串全量加载和正则全局匹配，改用流式读取、迭代器匹配及结构化拼接，并通过堆快照定位内存瓶颈。
处理大型数据时，字符串和正则操作极易引发内存激增甚至崩溃，核心问题不在语法本身，而在底层机制：字符串不可变性导致频繁复制，正则全局匹配生成大量中间对象，而引擎对长文本缺乏流式支持。
避免一次性加载全文本
无论 Java、JavaScript 还是 Python，把几 MB 以上的文件直接读成一个字符串是高危操作。UTF-16（JS）或 UTF-8/16（Java/Python）编码会放大内存占用，V8 中 50MB 文件可能占 100MB 堆空间，Java 的 String 还额外保留 char 数组和哈希码缓存。
- JavaScript：用
fs.createReadStream()+Transform流，配合TextDecoder按需解码子段，不构造完整字符串 - Java：改用
BufferedReader分块读取 char 数组，或Files.lines()返回惰性 Stream - Python：用
open(..., buffering=8192)控制缓冲区大小，逐行或按块read(n)，避免read()全量加载
慎用正则全局匹配与捕获
正则不是万能加速器——str.match(/./g) 或 re.findall(r'.+', text) 会在内存中生成数万元素的列表，每个元素都是独立字符串引用，GC 压力陡增。复杂模式还可能触发回溯爆炸，时间复杂度达 O(2ⁿ)。
- 只提取关键字段时，优先用非贪婪捕获组
re.search(r'key:\s*(\w+)', text)，而非findall - 需多轮匹配大文本，改用
re.finditer()（Python）或RegExp.prototype.exec()（JS）迭代器，按需生成结果 - Java 中避免
String.replaceAll()处理超长文本，改用Matcher.appendReplacement()流式构建结果
用结构代替字符串拼接
高频 += 或 StringBuilder.append() 看似自然，实则掩盖了内存分配成本。每次拼接都可能触发新数组分配、旧内容拷贝，尤其在循环中形成“内存雪崩”。
- JavaScript：收集片段进数组
parts.push(chunk)，最后parts.join('')—— 数组内存开销远低于字符串链 - Java：明确初始化
StringBuilder容量，如new StringBuilder(estimatedSize)，避免多次扩容 - Python：用
''.join(list_of_strings)替代循环+=；若需格式化，优先str.format()或 f-string 而非%拼接
定位真实内存瓶颈
process.memoryUsage() 或 psutil 只给总量，无法定位哪段字符串或哪个正则调用在“吃内存”。必须结合堆快照分析：
- Chrome DevTools → Memory → Heap Snapshot → 筛选
String构造器，看长字符串是否被闭包、DOM 引用意外持有 - Java：用
jmap -histo:live <pid>查看 String 实例数量，再用 VisualVM 加载 heap dump，按 retained size 排序 - Python：启用
tracemalloc，在关键路径前后take_snapshot()，对比差异定位分配源头
