抓取时JS未执行导致只能获取初始HTML骨架，动态内容缺失；需用Puppeteer等工具执行JS获取真实DOM快照，并通过waitForSelector等机制确保渲染完成。
抓取时JS未执行，拿到的是初始HTML骨架
大多数HTTP客户端（如curl、requests、axios）只下载原始HTML，不执行JavaScript，所以你拿到的DOM树里没有JS动态插入的节点、异步加载的内容或状态驱动的UI更新。比如一个用fetch拉数据再渲染列表的页面，抓取结果里ul可能是空的，或者只有占位符。
常见错误现象：document.querySelector('.item')返回null，但浏览器里明明能看到元素；用XPath或CSS选择器匹配不到预期节点；抓到的文本内容和肉眼所见严重不符。
- 这不是选择器写错了，而是目标节点根本还没生成
- 服务端渲染（SSR）或静态生成（SSG）页面除外——它们的HTML已含最终内容
- 可通过查看源码（右键 → “查看网页源代码”）确认：如果源码里没有该内容，就说明它纯靠JS动态渲染
需要真实DOM快照？得用支持JS执行的工具
要拿到JS执行后的DOM，必须借助能运行V8引擎的环境，比如Puppeteer、Playwright或无头Chrome。它们模拟真实浏览器行为：解析HTML → 构建DOM → 下载并执行JS → 触发DOMContentLoaded → 等待可选的networkIdle或自定义条件 → 截取最终DOM。
关键参数差异：
立即学习“前端免费学习笔记（深入）”；
-
page.goto(url, { waitUntil: 'networkidle0' })：等所有网络请求静止，适合API数据已加载完的场景 -
page.waitForSelector('.loaded')：更可靠，依赖JS设置的标记类，避免盲目等待时间 - 别只用
page.content()，它返回的是当前序列化DOM，可能包含未完成渲染的中间态；优先用page.evaluate(() => document.body.innerHTML)或直接操作document
对比两次DOM：初始HTML vs 渲染后快照
差异比对不是简单字符串diff，得聚焦结构变化。例如，初始HTML中div#app可能为空，而渲染后里面多了ul和一堆li；或者某个span的textContent从“加载中…”变成实际数值。
实操建议：
- 用
diff库（如deep-diff）比对两个Document对象的body子节点树，但注意剔除script、style等非展示性节点 - 避免直接比
innerHTML字符串——空格、换行、属性顺序不同都会导致误报 - 重点检查：节点增删（
childElementCount变化）、属性变更（dataset、class）、文本内容更新（textContent） - 若需自动化识别“动态区域”，可预先标记容器：在HTML里加
data-dynamic="true"，抓取后只比对该区域
容易被忽略的副作用：JS执行时机与状态残留
即使工具执行了JS，也不等于拿到“干净”的最终DOM。页面可能依赖滚动、鼠标悬停、定时器或用户事件触发后续渲染；某些组件（如React）会在首次render后继续发起请求或延迟更新；还有全局状态（如window.__INITIAL_STATE__）可能影响后续逻辑。
这意味着：
- 同一URL多次抓取，DOM可能不一致——取决于JS执行路径是否收敛
- 没显式等待
requestIdleCallback或组件useEffect完成，就截取DOM，可能漏掉最后一批节点 - 关闭页面前不清除
setInterval或监听器，下次抓取可能受残留状态干扰
最稳妥的做法是：让JS明确通知“准备就绪”，比如暴露window.isAppReady = true，然后用page.waitForFunction('window.isAppReady === true')同步等待。否则，任何基于时间或网络的等待都只是妥协。
