字符串拼接与正则表达式在性能敏感场景易互相拖累：低效拼接（如循环中+=）导致频繁内存分配，叠加贪婪正则回溯会引发双重性能塌方；应优先用+左结合、批量用join()、正则复用并避免.*等失控模式。
字符串拼接和正则表达式本身不直接冲突，但它们在内存、执行路径和性能敏感场景下容易互相拖累——比如用低效拼接生成长字符串后立刻交给糟糕正则去匹配，就可能触发双重性能塌方。
拼接方式选错，正则还没开始就卡住
大量使用 += 拼接（尤其在循环中）会产生频繁的内存分配与拷贝。例如拼接 10,000 次 50 字符的字符串，在旧引擎（如 IE7）中耗时可能超 200ms；生成的巨长字符串再交给一个带贪婪量词的正则处理，回溯次数会指数级增长，极易卡顿或阻塞主线程。
- 避免
str += 'a' + 'b' + 'c'：它隐含临时字符串创建，多一次拷贝 - 优先用
str = str + 'a' + 'b' + 'c'：左结合，基础字符串只参与一次连接计算 - 批量拼接（>100 次）一律改用
arr.push(...); arr.join('')：一次性分配最终内存，无中间拷贝
正则写法放大拼接缺陷
拼接出的字符串若含大量空白、换行或嵌套结构（如 HTML 片段），而正则又没做约束，就会引发“回溯失控”。典型例子：/<div>[\s\S]*/ 匹配不闭合的 div 时，<code>[\s\S]* 会反复试探、回退，时间复杂度接近 O(2ⁿ)。
- 别用
.*或[\s\S]*匹配任意内容，改用否定字符类，如[^ 替代 <code>.*?匹配标签间文本 - 对已知结构的字符串（如拼接生成的 JSON 或 HTML），优先用
.indexOf()、.split()或 DOM 解析，而非通用正则 - 正则对象务必复用：把
const re = /.../g提到循环外，避免重复编译
平衡点：按场景分层处理
不是所有地方都要极致优化，关键是识别瓶颈层级：
- 用户输入级拼接（如表单组合提示语）：用
+完全够用，可读性优先 - 模板渲染级拼接（如生成千行 HTML）：必须用
join()，且拼接后若需提取字段，改用DOMParser或结构化解析，绕过正则 - 日志/数据清洗类正则：提前剪裁字符串长度（如
str.slice(0, 10000)），再交给正则，避免处理无效长尾
本质上，拼接是“构建”阶段，正则是“解析”阶段。构建得松散，解析就吃力；解析太暴力，构建再快也白搭。稳住一端，另一端才有优化空间。
