HTML解析器将<ul>、<ol>、<li>视为普通元素节点，按标准栈式流程构建DOM；但Tree Constructor会在语法分析阶段自动修复缺失闭合（如隐式闭合<li>）、补全父容器，并确保所有<li>正确挂载在列表内，最终querySelector('li')获取的是已修正的完整DOM结构。
HTML解析器如何处理列表标签（<ul>、<ol>、<li>）
浏览器不会对列表做特殊语义化处理，<ul>、<ol>、<li>只是普通元素节点，解析逻辑和<div>完全一致：遇到开始标签就建节点入栈，遇到结束标签就弹栈。但DOM树构建完成后，渲染引擎会依据HTML规范赋予<li>隐式闭合行为——比如<ul><li>a<li>b</ul>中第二个<li>会自动触发前一个<li>的闭合，无需写</li>。
常见错误现象：
- 嵌套错乱导致
<li>被挂到<body>下（如<ul><div><li>xxx</div></ul>） - 遗漏
<ul>或<ol>直接写<li>，浏览器会自动补全父容器，但位置可能偏移
为什么querySelector('li')能拿到所有<li>，哪怕没写</li>
因为DOM树已按容错规则修正完毕。querySelector操作的是最终构建好的DOM，不是原始HTML字符串。浏览器的Tree Constructor在语法分析阶段就完成了隐式闭合、标签提升等修复，所以即使源码是<ul><li>1<li>2<li>3</ul>，实际DOM中已有三个独立的<li>节点，且都正确挂在<ul>下。
使用场景提醒：
立即学习“前端免费学习笔记（深入）”；
- 爬虫用
lxml或BeautifulSoup解析时，若未启用对应解析器的“容错模式”，可能得不到和浏览器一致的DOM结构 - 服务端渲染（SSR）若跳过HTML解析直接拼字符串，
<li>缺失闭合会导致客户端hydration失败
innerHTML赋值含列表时，解析行为和初始加载有区别吗
有本质区别。初始加载走完整HTML Parser流水线（Tokenizer → Tree Construction），而innerHTML = '...'触发的是“fragment parser”，它复用相同状态机，但起始上下文不同：它默认以<body>为根，不处理<doctype>或<head>，且对某些嵌套限制更宽松（例如允许<table>内直接写<li>，虽不合法但能解析）。
关键参数差异：
-
innerHTML解析不触发脚本执行，也不加载<link>/<script> - 若赋值内容含
<ul><li>...</ul>，仍会按标准规则构建子树，但父节点是当前元素，不是<body> - 性能上，
innerHTML比document.createElement快，但反复设置会引发重排，尤其列表项多时
列表DOM结构不稳定时，哪些操作容易出错
最常踩的坑是依赖childNodes.length或children[0]硬索引。因为文本节点（换行、空格）会被计入childNodes，但不会出现在children里；而<li>内部若有<span>或纯文本，children又可能为空。
安全做法：
- 用
querySelectorAll('li')代替遍历children，绕过DOM树中间态干扰 - 提取列表项文本时，优先用
el.textContent而非el.innerText（后者触发布局计算） - 动态增删
<li>时，避免直接操作innerHTML，改用appendChild/removeChild保持引用稳定
真正复杂的是当列表混用CSS计数器（counter-reset）、伪元素（::marker）或contenteditable时，DOM结构看似没变，但渲染树和编辑行为已受样式层深度干预——这时候光看节点树根本不够。
