高并发下HTML解析器内存飙升主因是内部缓存未释放、DOM树节点滞留及临时对象堆积；应禁用全量DOM构建，改用流式解析（如htmlparser2/lxml.iterparse），关闭自动解码，及时销毁实例并清空引用。
高并发场景下，HTML解析器的内存占用往往在几秒内飙升并持续不降——这不是GC没运行，而是解析器内部缓存未释放、DOM树节点未及时回收、或正则/字符串临时对象堆积所致。关键不在“用什么库”，而在“怎么用”。
避免 full DOM 构建：用流式解析替代 parse 全量加载
多数 HTML 解析器（如 Python 的 BeautifulSoup、Node.js 的 cheerio、Java 的 Jsoup）默认构建完整 DOM 树，每个标签、属性、文本节点都生成独立对象。1MB HTML 可能撑起 10–20MB 托管堆。
- 用
htmlparser2（Node.js）或lxml.etree.iterparse（Python）做事件驱动流式解析，只保留当前需要的字段，不建树 - 禁用自动解码、实体转换等后台处理：例如
htmlparser2中设{decodeEntities: false}，避免内部缓存解码表 - 对日志、监控类 HTML 片段，直接用正则提取关键值（如
/status="([^"]+)"/），跳过解析器开销
cheerio 的内存陷阱：别调用 .load() 后不清理
cheerio.load() 返回的实例会持有整个文档结构 + 内部选择器缓存 + 闭包引用。若在 HTTP handler 中反复调用且未显式销毁，对象会长期驻留，触发 Gen2 GC 频繁回收。
- 每次解析后立即丢弃实例：
const $ = cheerio.load(html); const result = $.text(); $ = null; - 禁止复用
$实例处理不同 HTML；每个请求必须新建 - 避免
.find()后链式调用大量.map()或.each()，它们会生成中间数组；改用原生for循环 +.get()获取原始节点
Java Jsoup 的 Document 必须手动 .clear() 和 System.gc() 不起作用
Jsoup.parse() 返回的 Document 对象包含完整的父子引用链和 CSS 选择器索引缓存。即使局部变量超出作用域，若曾被放入静态集合、线程局部变量或日志上下文，就会泄漏。
立即学习“前端免费学习笔记（深入）”；
- 解析完立刻调用
doc.body().children().remove()清空子节点，再调用doc.clear() - 确认无任何外部引用后，可显式置空：
doc = null;（JVM 8+ 中System.gc()无法强制回收，仅作提示） - 高并发服务中，优先用
Jsoup.parseBodyFragment()替代parse()，它跳过解析与元信息初始化，减少约 30% 对象创建
Go 语言解析器（如 golang.org/x/net/html）的缓冲区未回收
Go 的 html.Parse() 底层使用 bufio.Reader，若传入的是带缓冲的 *bytes.Reader 或复用的 sync.Pool 缓冲区，但解析后未归还，会导致内存持续增长。
- 永远从
sync.Pool获取bytes.Buffer或bufio.Reader，解析结束后pool.Put() - 避免用
strings.NewReader(html)直接构造 reader —— 它不支持复用，每次分配新字符串头 - 对小 HTML（html.Parse(io.MultiReader(...)) 组合输入流，避免中间
[]byte拷贝
真正卡住内存的，从来不是解析逻辑本身，而是你没意识到那些“用完即弃”的对象其实在底层悄悄建了引用网。流式、及时置空、缓冲区池化——这三件事不做，换再快的解析器也扛不住每秒上千 HTML 请求。
