xpath 路径中出现 `/html[2]` 并非表示页面存在多个 `` 根元素，而是解析器（如 lxml 或某些浏览器扩展）在处理不规范 html 时生成的伪文档结构；标准 html 规范严格禁止嵌套或并列的 `` 标签。

在实际网页开发与自动化解析中，你可能会观察到同一页面在 Chrome 开发者工具中复制的 XPath 是 /html/body/...，而用 requests.get() 获取响应后经 lxml.html.fromstring() 解析得到的 XPath 却是 /html[2]/article/...。这种差异并非源于 HTML 页面本身包含多个 元素——这是根本违反 HTML 规范的。

根据 MDN Web Docs， 是文档的根元素，具有两个关键约束：

• 所有其他元素必须是它的后代（即唯一根节点）；
• 它不允许有任何父元素（“Permitted parents: None”）。

因此，如下写法均非法：

<!-- ❌ 错误：并列 html -->
<html></html>
<html></html>

<!-- ❌ 错误：嵌套 html -->
<html>
  <html></html>
</html>

那么 /html[2] 是从何而来？根本原因在于 HTML 解析器对破损或非标准 HTML 的容错处理机制。例如：

立即学习“前端免费学习笔记（深入）”；

JS X Monitor

X.com (Twitter) 账号监控自动化：定时抓取指定账号最新推文，发现新内容即时推送通知。

下载

• 某些网页可能意外包含多个 声明，或在 外追加了未闭合的标签；
• lxml（常用于 Python 爬虫）默认使用 HTMLParser，它会将不规范内容“修复”为多棵子树，并统一包裹在 容器下，形成类似：

  <html>
    <head>...</head>
    <body>...</body>
  </html>
  <html>  <!-- lxml 自动补全的第二棵子树（如脚本注入、注释后残留内容等） -->
    <article>...</article>
  </html>

  此时 /html[2] 表示该 DOM 树中的第二个 节点——但它不是原始 HTML 的合法部分，而是解析器生成的“修复产物”。

✅ 正确做法是：

• 使用 lxml.html.fromstring(response.text) 时，显式指定 parser=lxml.html.HTMLParser(recover=True)（默认即开启）；
• 更可靠的方式是始终基于 或语义化容器（如 main, article）定位元素，避免强依赖 /html 轴：

  from lxml import html
  tree = html.fromstring(response.content)
  # ✅ 推荐：忽略 html 层级，直接查 body 下结构
  element = tree.xpath('//article/section/div[6]/text()')
  # ✅ 或使用相对路径 + 显式命名空间
  element = tree.xpath('/html/body/article/section/div[6]/text()')

⚠️ 注意事项：

• Chrome DevTools 复制的 XPath 基于渲染后的 DOM（已由 Blink 引擎修正），而 requests + lxml 解析的是原始 HTML 字符串（无 JS 渲染，且解析策略不同）；
• 若需完全一致的路径行为，可改用 selenium 驱动真实浏览器，或使用 html5lib 解析器（更贴近浏览器行为）；
• 永远不要假设 /html[1] 或 /html[2] 具有业务语义——它们只是解析中间态，应以内容结构（class、id、role、语义标签）为定位依据。

总结：/html[2] 是解析器对脏数据的妥协结果，而非 HTML 合法特性。编写健壮的爬虫 XPath，应优先采用语义化、相对路径和属性过滤，而非依赖绝对路径中的 html[n] 索引。