老旧双核CPU运行HTML过滤工具时最常卡在JS解析和DOM遍历环节，应避免DOMParser、innerHTML+正则等高开销路径，改用textContent提取纯文本、白名单字符串拼接、固定正则replace及Web Worker分离任务。
老旧双核CPU（如Intel Pentium Dual-Core E2140、AMD Athlon II X2）运行HTML过滤类工具时，最常卡在JS解析和DOM遍历环节，不是因为函数写得不对，而是默认选了高开销路径。直接用 innerHTML + 正则替换或全量 DOMParser 解析，很容易把单核推到100%，拖慢整个系统响应。
避免使用 DOMParser 和 innerHTML 配合正则清洗
这类组合看似“标准”，实则对双核老CPU极不友好：DOMParser 会触发完整 HTML 语法树构建，即使只过滤一段文本；而正则匹配带 g 标志的多行HTML字符串，在V8旧版本（如Chrome 65–75）中极易引发回溯爆炸，主线程卡死超过2秒是常态。
- 改用
textContent直接提取纯文本内容（跳过所有标签解析），再做基础字符替换，耗时稳定在毫秒级 - 若必须保留部分标签（如
<p>、<strong>），优先走白名单字符串拼接：先用split(/<\/?[^>]+>/g)切片，再逐段判断标签名是否在允许列表中，最后用join('')组装——不建DOM、不调用浏览器解析器 - 禁用任何依赖
document.createElement+appendChild的“安全渲染”逻辑，老CPU上创建10个节点就可能触发一次强制重排
用原生 replace() 替代第三方HTML过滤库
像 DOMPurify 或 sanitize-html 这类现代库，底层大量使用 WeakMap、Array.from() 和 for...of，在无 JIT 优化的老V8或SpiderMonkey（Firefox ESR 115）中执行效率极低。它们还自带大量防御性检查，对双核设备纯属冗余负担。
- 手写三行
replace()就能覆盖90% XSS风险：input.replace(/<script[^>]*>[\s\S]*?<\/script>/gi, '').replace(/on\w+\s*=\s*["'][^"']*["']/gi, '').replace(/javascript:/gi, '') - 如果输入可控（如后台表单提交），甚至可只过滤
<script开头和javascript:协议，其余交由后端htmlspecialchars()处理，前端零解析压力 - 注意：不要用
new RegExp(..., 'g')动态构造正则，老JS引擎编译慢；固定正则字面量（如/<script/gi）会被引擎缓存，反复调用无额外开销
启用 Web Worker 分离过滤任务
双核CPU仍有闲置资源，但默认所有JS都在主线程跑。把过滤逻辑扔进 Web Worker，能避免阻塞UI线程，让页面滚动、按钮点击保持响应——这对老旧系统体验提升最直观。
立即学习“前端免费学习笔记（深入）”；
- Worker 文件只需 20 行左右：
self.onmessage = ({data}) => { const clean = data.replace(/<script/gi, '<script self.postmessage></script> - 主页面用
const worker = new Worker('filter.worker.js');启动，传入字符串后监听message事件取结果，全程不卡界面 - 注意：Worker 里不能访问
document或window，所以所有基于DOM的操作必须前置剥离，只留纯字符串处理 - Firefox ESR 115 和 Chrome 75+ 均支持，无需额外 polyfill
真正卡住老旧双核的，从来不是“能不能做过滤”，而是“有没有绕开浏览器最重的那几条执行路径”。只要避开 DOM 构建、禁用动态正则、把计算挪到 Worker，哪怕用最朴素的 replace()，也能在 1.6GHz 主频下做到 5ms 内完成 5KB HTML 片段清洗——这比等一个 DOMParser 初始化完成还快。
