字符串和正则操作不当会导致内存飙升甚至OOM，主因是字符串不可变性、正则全局匹配产生大量中间对象及缺乏流式支持；应采用分块读取、迭代匹配、预估容量拼接及避免隐式引用等优化手段。
字符串和正则操作本身不“重”，但不当用法会让内存占用飙升甚至触发 OOM。根本原因在于：字符串不可变性导致频繁复制，正则全局匹配生成大量中间对象，而多数语言缺乏对长文本的流式支持。
避免一次性加载全文本
几 MB 的文件直接 read() 或 fs.readFileSync() 成字符串，极易踩坑。UTF-8/16 编码会放大实际内存占用，V8 中 50MB 文件可能占满 100MB 堆空间；Java 的 String 还额外缓存哈希值和字符数组。
- JavaScript：用
fs.createReadStream()+Transform流，配合TextDecoder按需解码小块 - Java：优先用
BufferedReader分块读取 char 数组，或Files.lines()返回惰性Stream - Python：打开文件时指定
buffering=8192，用read(n)或逐行迭代，禁用read()
慎用正则全局匹配与捕获
str.match(/./g) 或 re.findall(r'.+', text) 会在内存中构建数万元素的列表，每个都是独立字符串引用，GC 压力陡增。复杂模式还可能引发回溯爆炸，时间复杂度达 O(2ⁿ)。
- 只提取关键字段时，用非贪婪捕获组：
re.search(r'key:\s*(\w+)', text) - 需多轮匹配大文本，改用
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)，格式化优先选f-string而非%拼接
警惕隐式引用与缓存陷阱
内存泄漏常不报错，而是缓慢爬升——大字符串被意外“钉”在堆上无法回收。
- Java：检查是否将大字符串塞进静态 Map 或单例缓存；
StringBuilder.toString()后长期持有引用也危险 - 正则：高频 Pattern 必须声明为
private static final，禁止在循环或请求中动态编译 - JavaScript：带
g标志的正则有状态，lastIndex不重置易导致引用残留；matchAll()迭代器未消费完也会锁住内存
