lxml.etree.parse()报“Opening and ending tag mismatch”是因为它默认用严格XML解析器处理不规范HTML，而HTML中未闭合标签（如<meta>）在XML中非法；应改用lxml.html.fromstring()或etree.parse()配合HTMLParser(recover=True)启用容错解析。
为什么lxml.etree.parse()一遇到就报Opening and ending tag mismatch
因为etree.parse()默认调用的是XML解析器，它把HTML当XML看——而XML要求所有标签必须严格配对、自闭合标签（如<meta>）必须写成<meta/>。浏览器能容错，但XML解析器不会猜你本意，直接抛lxml.etree.XMLSyntaxError。
这不是你的XPath写错了，也不是HTML“看起来能打开”，而是解析器在第4行看到<meta charset="UTF-8">，却在第6行撞上</head>，中间缺了闭合斜杠，它就认定结构崩了。
- 别改XPath表达式，先换解析器
- 别手动补
/>，批量HTML里可能有几十处类似错误 - 错误提示里的行号（如
line 4）基本可靠，可直接定位到源文件查证
用lxml.HTMLParser(recover=True)代替etree.parse()
真正该用的是lxml.html.fromstring()或带HTMLParser的etree.parse()，核心是启用recover=True——这是libxml2内置的HTML容错引擎，能自动修复错位闭合、缺失结束标签、嵌套混乱等常见问题。
正确写法：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
from lxml import etree
parser = etree.HTMLParser(recover=True, encoding='utf-8')
tree = etree.parse('page.html', parser)
# 或更常用：
from lxml.html import fromstring
tree = fromstring(dirty_html)
-
recover=True必须显式传入，不设就是默认严格模式 -
encoding参数要和HTML实际编码一致，否则可能解码出乱码字节，后续XPath匹配失败 - 避免混用：
etree.parse()配HTMLParser可以，但别拿etree.XMLParser()去硬刚HTML
BeautifulSoup选lxml还是html5lib？看坏到什么程度
如果HTML只是小范围不规范（比如<img src=logo.png>少引号、<p>文本<div>块级</p>），lxml解析器够用且快；如果连<table>里都塞了<div>、<script>里有未转义</script>，就得上html5lib——它最贴近Chrome/Firefox的纠错逻辑，但慢、吃内存。
初始化示例：
from bs4 import BeautifulSoup soup = BeautifulSoup(html_str, 'lxml') # 快，适合多数场景 # soup = BeautifulSoup(html_str, 'html5lib') # 兼容最强，修得最狠
-
lxml需系统有libxml2，Windows用户pip install lxml通常能装预编译wheel，不用自己编译 -
html5lib纯Python实现，安装轻量（pip install html5lib），但运行时开销大 - 别用默认
html.parser，它对坏HTML几乎零容错，常静默截断而非报错
解析后必须验证关键节点是否存在
容错解析≠结果可信。lxml或BeautifulSoup可能“修好了”结构，但修法未必符合你预期：比如把一个<td>从<tr>里提到了外面，表面没报错，数据却偏移两列。
- 每次
soup.find('table')后立刻加if table is None:判断，别直接链式调用table.find_all('tr') - 对唯一容器（如
<div class="main">），优先用soup.select_one('.main')，避免select()误取页脚同名div - 原始HTML若含GBK编码，传给BeautifulSoup时务必加
from_encoding='gbk'，否则str对象里全是b'\xc4\xe3'类字节，后续find失效
最易被忽略的一点：浏览器Elements面板里看到的DOM，是它自己修过一遍的结果，和你传给解析器的原始HTML可能完全不同。调试时别只信源码或渲染效果，要拿tree.getroot().xpath('/html/body')或soup.body.prettify()打印出解析器实际构建的树结构，比对关键层级是否真实存在。
