浏览器解析html即构建dom树的过程，由blink/gecko/webkit等引擎将字节流→字符→token→dom节点→树形结构；服务端需cheerio或jsdom等库模拟解析。
浏览器本身就在用解析引擎处理 HTML，你不需要自己“引入”一个——但如果你要干预解析行为、提取结构信息或做服务端预处理，就得明确区分场景：是浏览器内运行时操作 DOM，还是服务端/工具链里解析原始 HTML 字符串。
浏览器里解析 HTML 就是构建 DOM 树的过程
Chrome 的 Blink、Firefox 的 Gecko、Safari 的 WebKit 都在底层用 C++ 实现 HTML 解析器，流程固定：字节 → 字符 → token（如 <div>、<code>class="box"）→ DOM 节点 → DOM 树。你写的每个 <section></section>、<article></article> 都会变成内存里的对象，可通过 document.querySelector 或 document.body.children 访问。
常见错误现象：
- 写了一堆嵌套
<div>，但 <code>document.querySelectorAll('footer')查不到——可能因嵌套超 6 层被流式解析器丢弃 -
<script></script>放在里没加defer，导致document.body还是null——解析被阻塞，DOM 树还没建完 - 用 Chrome DevTools 的 Elements 面板右键节点 →
Show DOM properties查depth值，超过 6 就拆结构 - 想确保 DOM 就绪再操作，用
DOMContentLoaded事件，别依赖load - 避免手动拼接 HTML 字符串后用
innerHTML注入，容易触发重复解析；优先用document.createElement+appendChild - 爬虫抓取后分析页面结构（如提取
<h1></h1>和所有<a href></a>） - SSR（服务端渲染）中预编译模板，提前计算 SEO 元素
- CI 流程中校验 HTML 是否符合语义规范（如是否缺失
<title></title>） -
cheerio.load(html, { xmlMode: false })：默认按 HTML 模式解析，自动修复错位标签；设为true会严格按 XML 规则，遇到<br>不闭合就报错 -
jsdom.JSDOM(html)会执行内联脚本，可能触发副作用；若只需结构解析，加resources: 'usable'并禁用脚本 - 二者都不处理 CSS 渲染逻辑——
cheerio不管样式，jsdom默认也不计算布局，得手动调getComputedStyle - 传入含
style="color:red"的字符串，文字颜色不变 - 用
<p></p>段落标签，结果换行失效——因为Html.TagHandler根本不处理<p></p> - 纯文本富文本需求，用
SpannableStringBuilder手动控制样式，比依赖 HTML 更可控 - 真要支持复杂 HTML，必须自定义解析器，拦截
TagHandler.handleTag，对未知标签（如<custom-tag></custom-tag>）自行处理属性和嵌套 - 别试图 patch
Html.fromHtml——SDK 内部用的是隐藏的XmlReader，API 不开放，改不动
实操建议：
服务端或 Node.js 中解析 HTML 必须用第三方库
Node.js 没有原生 DOM，document 对象不存在。你要从字符串里提取标题、链接或结构化数据，得靠解析库，比如 cheerio（轻量、jQuery 风格）或 jsdom（模拟完整浏览器环境，重但兼容性好）。
使用场景：
参数差异与坑：
Android TextView 的 HTML 解析能力极弱，别当真
android.text.Html.fromHtml() 只支持有限标签（<b></b>、<i></i>、<u></u>），连 <div> 都不识别，更别说 CSS 属性。它本质是把 HTML 字符串转成 <code>Spannable，不是真正解析引擎。
常见错误现象：
实操建议：
真正关键的分水岭不在“用不用解析引擎”，而在于你是否清楚自己处在哪一层：是让浏览器按规范走完标准解析流水线，还是在非浏览器环境里模拟它——后者永远要面对 token 边界、自闭合规则、命名空间、编码检测这些底层细节，绕不开也省不了。
