DOM重构防爬的核心是制造静态HTML与渲染后DOM的结构差异，而非单纯混淆源码；必须通过JS执行期的真实DOM操作改变节点层级、顺序或存在性，并与SSR hydration协同验证。
为什么用 DOM 重构对抗爬虫而不是单纯混淆 HTML 源码
因为爬虫工具（如 requests + BeautifulSoup）拿到的是服务端吐出的原始 HTML，而真实用户看到的是 JS 执行后重排过的 DOM。防抓取的关键不是“让源码难读”，而是“让静态解析结果和渲染后结构不一致”——重构正是制造这种 gap 的核心手段。
常见错误是只在 HTML 层做 class 随机化或插入空标签，但没动 DOM 树本身；这类操作对 Playwright 或 Selenium 无效，它们拿到的是最终 DOM，根本不在乎你源码里写了啥。
- 重构必须发生在 JS 执行期，且要改变节点层级、顺序或存在性（比如把
div#price移进span.item-meta内部） - 不能只靠
innerHTML替换，得用appendChild、insertBefore等真实 DOM 操作，否则某些检测脚本能识别“伪渲染” - 重构后需触发
mutationObserver回调或重绘信号，否则部分反爬逻辑会认为页面未完成 hydration
DOM 重构中 class/id 随机化与选择器失效的实操陷阱
随机 class 名（如 cls_7f2a9b）本身不构成有效防护——只要结构路径稳定，XPath 仍可匹配 div[1]/span[2] 这类位置型表达式。真正让选择器失效的是“路径漂移”：父容器被移走、兄弟节点顺序打乱、关键节点被包裹多层。
典型失败场景：soup.find("div", class_="price") 找不到，不是因为 class 变了，而是该 div 已被 JS 插入到另一个动态生成的 section[data-role="product"] 下，而这个 section 在原始 HTML 中根本不存在。
立即学习“前端免费学习笔记（深入）”；
使用Playwright API直接进行浏览器自动化。导航网站、与元素交互、提取数据、截图、生成PDF、录制视频，自动化复杂工作流程。比MCP方法更可靠。
- 避免在重构逻辑里硬编码 class/id，改用
data-*属性定位（如document.querySelector('[data-price-src]')），再移动节点 - 每次重构后应清除旧节点的
id和class，防止残留属性被误匹配 - 若使用 Webpack 打包，确保
css-modules开启 localIdentName 随机化，否则 class 名虽变但规律可被学习
服务端 SSR 与客户端 hydration 如何协同实现可信 DOM 重构
单靠客户端 JS 重构容易被识别为“非首屏行为”，尤其当重构延迟明显（如等 setTimeout 或滚动触发）时。可信重构依赖 SSR 输出一个“可被还原”的骨架，再由客户端 JS 基于该骨架做确定性重排——两者哈希一致才被视为合法。
例如 SSR 渲染时输出 <div data-hydration-id="p1"><span>$99</span></div>，客户端 JS 查找所有 [data-hydration-id] 并按预设规则重组：把 span 提升为同级、加 wrapper、拆分文本节点等。
- 服务端需同步生成 hydration key（如 SHA256 of template + nonce），客户端比对失败则拒绝重构
- 重构函数不能依赖 window.location 或时间戳等不可控变量，否则 SSR/CSR 结果不一致
- 务必在
useEffect（React）或mounted（Vue）中执行，避开 SSR 环境报错
Playwright/Selenium 如何被 DOM 重构机制识别并限流
不是因为它们“不是浏览器”，而是因为它们默认等待 networkidle 或 domcontentloaded 后就提取 DOM，此时重构可能尚未完成，或重构后未触发 layout/reflow 检测信号。
反爬系统常监听 requestAnimationFrame 循环次数、getComputedStyle 返回值变化、甚至 performance.memory 使用波动，来判断是否真有“人眼可见的重排发生”。纯自动化脚本往往跳过这些隐式等待点。
- 在 Playwright 中显式加
await page.evaluate(() => document.fonts.ready)，确保字体加载+重排完成 - 避免用
page.content()直接取 HTML，改用page.evaluate(() => document.documentElement.outerHTML)获取 hydrate 后的 DOM - 若目标站检测
document.hidden或document.hasFocus()，需在启动时加--disable-backgrounding-occluded-windows参数
真正难绕过的不是某段 JS 重构逻辑，而是重构与 CSS 渲染、JS 执行时机、服务端 nonce 生成之间的耦合深度——删掉任意一环，整个指纹验证链就断了。这也是为什么简单 patch 一段 JS 往往无效：你绕过了重构，却触发了 hydration 不一致告警。
