pandas.read_html()直接传URL常失败，因其仅用urllib最简GET、无UA、不处理JS渲染和反爬；应先用requests等获取HTML再解析。
直接传 URL 给 pandas.read_html() 是可行的，但多数情况下会失败或漏表——根本原因不是函数不行，而是它不发请求、不执行 JS、不处理反爬、不自动解码，纯靠底层 lxml 或 html5lib 解析你“塞给它的 HTML 字符串”。
为什么 read_html() 传 URL 常常返回空列表
这个函数表面上支持 URL，实际只是调用 urllib.request.urlopen() 做最简 GET，没带 User-Agent，没处理重定向，遇到 403/406/302 就直接报错或返回空；更关键的是，它完全不等页面 JS 渲染，所有动态插入的 <table> 标签都看不到。
- 常见错误现象：
ValueError: No tables found或返回空 list - 典型场景：目标页面由 Vue/React 渲染、有登录态校验、或服务器根据 UA 拒绝默认 Python 请求
- 参数差异：
read_html(url, ...)和read_html(html_string, ...)的底层逻辑一致，区别只在“谁负责拿 HTML” - 性能影响：用它直连 URL 不会比自己用
requests多快，反而因缺少重试、会话复用等机制更不稳定
正确做法：先拿 HTML，再喂给 read_html()
把网络请求和 HTML 解析拆开，才能控制 UA、cookies、重试、编码、JS 渲染等环节。95% 的表格提取问题出在“HTML 拿得不对”，而不是 read_html() 本身。
- 基础安全请求（绕过简单 UA 检查）：
import requests<br>headers = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'}<br>resp = requests.get(url, headers=headers, timeout=10)<br>resp.raise_for_status()<br>resp.encoding = resp.apparent_encoding # 防乱码<br>tables = pd.read_html(resp.text) - 需要登录或表单交互？必须用
requests.Session()保持 cookies - 表格由 JS 动态生成？换
selenium或playwright渲染后取page.content()，再传给read_html() - 注意：
read_html()默认只认<table>标签，如果页面用div+css模拟表格，它完全无能为力
read_html() 的关键参数怎么选
默认行为往往不够用，尤其当页面有多个表、嵌套表、无表头、或含合并单元格时。
立即学习“Python免费学习笔记（深入）”；
-
match：用正则快速筛选目标表，比如match=r'季度.*营收'，避免取错表 -
header：指定第几行作列名，默认0，若表头在第 2 行就设header=1 -
skiprows：跳过前 N 行（比如广告行、说明行），比手动切片更稳 -
flavor：默认'lxml'，但遇到畸形 HTML 可试'html5lib'（需额外装包），速度慢但容错高 -
encoding：仅当resp.text已是 bytes 且编码异常时才需显式传，多数情况交给resp.encoding更可靠
容易被忽略的编码和结构陷阱
即使 HTML 成功拿到，表格解析仍可能翻车——尤其是中文页面和老系统后台。
- 常见错误现象：列名乱码、数字变 NaN、某列全空
- 根本原因：HTML 声明的
charset和实际编码不一致，或<meta>标签位置靠后导致requests检测失败 - 实操建议：强制用
resp.content.decode('gbk', errors='ignore')（针对国内老站），再传给read_html() - 另一个坑：
read_html()对colspan/rowspan支持有限，合并单元格可能被展开成多列，需后续用df.iloc或fillna(method='ffill')修复
真正卡住人的，从来不是 read_html() 会不会用，而是没意识到它只是个“解析器”，不是“爬虫”。URL 能不能直接传，取决于你愿不愿意为那行代码多写三行 request 控制逻辑。
