JS字符串性能优化需优先使用原生API、避免不可变性陷阱、按场景选结构：用trim()等原生方法提速40%–50%，拼接用数组join或模板字面量，超长文本分块+Worker处理，正则慎用以防回溯。
JS 字符串处理性能优化没有“一招鲜”，但有清晰的优先级和可落地的组合策略。核心是：**用对原生方法、避开不可变性陷阱、按场景选结构**。
优先调用原生方法，别自己造轮子
现代浏览器（包括 iOS Safari、Android Chrome、微信、UC）已全面支持 String.prototype.trim()、padStart()、replaceAll() 等原生 API。它们由引擎底层 C++ 实现，比等效的正则或循环逻辑快 40%–50%，内存占用更低。
- ✅ 直接用
str.trim()，别写str.replace(/^\s+|\s+$/g, '') - ✅ 用
str.replaceAll('a', 'b')替代str.replace(/a/g, 'b')（语义更准，V8 专有优化） - ✅ 多分隔符切割用
str.split(/[,;:\-]/)比多次split().join()更简洁高效
拼接大量文本时，用模板字面量或数组 join
字符串不可变，每次 += 都会创建新副本。10 万次拼接 1KB 文本，+= 可能触发 200+ 次垃圾回收，而优化方案几乎无暂停。
- ✅ 循环内拼接：收集到数组，最后
arr.join('')—— 时间复杂度从 O(n²) 降至 O(n) - ✅ 少量插值：直接用
`前缀${val}后缀`—— V8 会预计算总长并一次性分配内存 - ❌ 避免在热路径中用
concat()或反复+=，尤其处理日志、CSV、HTML 片段时
处理超长字符串，分块 + 流式 + Worker
单次加载并操作 10MB+ 文本极易引发内存峰值甚至崩溃。关键不是“怎么快”，而是“怎么稳”。
- ✅ 把大文本按 512KB–2MB 分块，逐块解析或编码（如 Base64）
- ✅ 结合
TextEncoder处理 UTF-8 字节，比unescape(encodeURIComponent())快 40% - ✅ 耗时操作（如全文搜索、格式转换）移到 Web Worker，保持主线程响应
谨慎使用正则，尤其避免灾难性回溯
正则不是万能钥匙。复杂量词嵌套（如 (A+)+B）在恶意输入下可能指数级卡死，且全局匹配 .match(/./g) 创建大量临时对象。
- ✅ 简单替换/检查：优先用
includes()、startsWith()、slice() - ✅ 必须用正则时：限制量词范围（如
A{1,50}），禁用贪婪模式（加?），用test()代替match()判断存在性 - ✅ 复杂提取：考虑
str.matchAll(/pattern/g)（返回迭代器，不一次性建数组）
