不能用DOMParser硬拦截大HTML文件，因其需构建完整DOM树并递归遍历，易触发栈溢出或OOM；应采用htmlparser2.WritableStream流式事件解析，在opentag回调实时拦截并插入合法注释锚点，配合语义切片保障流式语义连续性。
为什么不能用DOMParser硬拦截大HTML文件
直接调用 new DOMParser().parseFromString() 处理超 5MB 的 HTML，大概率触发 RangeError: Maximum call stack size exceeded 或 V8 OOM 崩溃。这不是配置问题，而是 DOM 构建本身需要完整树结构和递归遍历——网关或边缘节点根本没资源扛住这个过程。
htmlparser2.WritableStream 是硬拦截的最小可行路径
它不建 DOM，只暴露事件回调，内存占用可控在几 MB 内。关键不是“怎么解析”，而是“怎么提前终止”：
- 在
opentag回调里检查标签名 + 属性（如script、iframe、onerror=），匹配即调用this._parser.reset()并抛出自定义错误 - 禁用
xmlMode: true，否则自闭合标签（<img src="https://img.php.cn/" alt="利用流解析器实现网页HTML文档结构的大文件硬拦截">）会解析失败，导致拦截漏判 - 不要等整个文档流结束才判断——
final钩子太晚；必须在_write过程中实时响应 - 设置
highWaterMark: 64 * 1024（64KB），防止 chunk 积压拖垮内存
硬拦截必须带上下文锚点，否则等于没拦
单纯丢弃含恶意标签的块会导致后续语义断裂，下游服务无法恢复。正确做法是在拦截点插入注释锚点：
<!-- INTERCEPTED: script tag at line 12345 -->
这样既保留原始位置信息，又避免破坏 HTML 结构合法性。同时需确保：
立即学习“前端免费学习笔记（深入）”；
- 注释内容不可执行（不包含
-->或嵌套注释） - 锚点必须在
closetag后立即写入，不能延迟到text回调里拼接 - 若拦截发生在
<head>内，需额外补全<meta charset="utf-8">防止后续解析乱码
切片后再拦截比单次全量拦截更可靠
对未结构化的 HTML 流直接硬拦截，容易因标签跨 chunk 被截断而失效（比如 <script> 开头在 chunk A，结尾在 chunk B）。所以真实生产环境应先做语义切片：
- 用
HTMLHeaderTextSplitter按<h1>~<h3>切块，每块带metadata.level和id - 对每个块单独起一个
WritableStream实例做硬拦截，失败则整块丢弃 - 切片时设
max_chunk_size: 500000，防止单块过大绕过拦截逻辑
硬拦截真正难的不是识别标签，而是保证拦截动作不引入新解析歧义——所有插入、重写、丢弃都必须维持流式语义连续性，这点很容易被忽略。
