document.querySelector 返回 null 的真实原因是脚本执行时目标元素尚未进入 DOM，而非选择器写错；常见于 script 置于 head 未加 defer、框架动态渲染未就绪、特殊字符未转义，或查询对象实际未渲染。
document.querySelector 返回 null 的真实原因
不是选择器写错了，是脚本执行时目标元素压根还没进 DOM。浏览器解析 HTML 是从上到下流式进行的，document.querySelector 在 <script> 标签里运行，如果它出现在目标元素之前，结果必然是 null。
常见触发场景：
-
<script>放在<head>里，且没加defer或async - 元素由 Vue/React 动态挂载，但你只等了
DOMContentLoaded，没等框架就绪 - ID 或 class 名含
.、:、[等 CSS 特殊字符，却没转义：document.querySelector('#user\.name')（注意 JS 字符串里要写两个反斜杠）
验证方法：打开开发者工具 Elements 面板，看实际渲染出的 DOM 结构——那才是 querySelector 真正匹配的对象，不是你写的源码。
BeautifulSoup.find() 返回 None 的典型误判
返回 None 很少是因为语法错误，更多是数据根本不在初始 HTML 里。
立即学习“前端免费学习笔记（深入）”；
检查步骤：
- 禁用 JavaScript 后刷新页面：如果关键内容区域变空或只剩骨架屏，说明数据靠 JS 渲染（可能是 WebSocket、SSE 或 XHR）
- 在 Network 面板中切到 XHR / Fetch/XHR 子标签，找带真实数据的响应（比如
/api/v1/items），而不是死磕<table>标签 - 用
response.text打印原始 HTML，搜索关键词——如果搜不到，BeautifulSoup就不可能找到
别急着改 selector，先确认数据是不是被 requests 拿到了。它不执行 JS，也不连 WebSocket。
DOMParser 解析 HTML 片段失败的关键点
后端返回的常是纯片段（比如只有 <div class="list">...</div>），直接丢给 DOMParser 会因缺少上下文导致解析异常。
正确做法：
- 显式指定 MIME 类型：
new DOMParser().parseFromString(html, 'text/html')，否则可能按 XML 解析 - 若输入为空或非法 HTML，
parseFromString仍返回有效 Document 对象，需手动校验：if (!doc.body?.children.length) return null - 避免在循环中反复新建
DOMParser实例（可复用），但单次解析无需优化
更稳妥的兜底方式：用 document.createElement('div') 包一层再设 innerHTML，适合处理无结构的 HTML 片段。
read_html 抓不到表格的底层限制
pd.read_html() 不是万能表格提取器，它只认标准 <table> 标签，且严重依赖底层解析器对 DOM 的还原质量。
失效常见于：
- 表格用
<div>+ CSS 模拟，HTML 源码里根本没有<table> - JS 动态生成表格，
requests.get().text拿到的是空容器 -
<colspan>/<rowspan>过多，lxml 解析器无法对齐行列
实操建议：
- 先用
requests.get(url).text手动搜索<table，确认表格是否真实存在于源码中 - 显式指定解析器：
pd.read_html(html, flavor='lxml')（比默认html5lib更严格） - 用
match=缩小范围，比如match='用户列表'，避免匹配到页脚广告表格
真正难啃的骨头，往往不在 selector 写得准不准，而在你面对的压根就不是传统 HTML 表格。
