html结构混淆根本拦不住真爬虫，只要敏感字段以明文形式出现在response.text里就等于直接交付；现代解析器和正则可绕过class随机、多层嵌套、注释隐藏、display:none等干扰，仅增加低阶采集成本。
HTML结构混淆根本拦不住真爬虫
只要敏感字段以明文形式出现在 response.text 里，就等于直接交到爬虫手上。BeautifulSoup、Cheerio、甚至 re.findall(r'data-price="([^"]+)"', text) 都能秒级提取——结构打乱、class 随机、嵌套七层 <div>，对这些工具毫无影响。<p>常见错误现象包括：以为 <code><!-- price: 99.9 --> 能藏住数据，结果 soup.find(string=lambda t: "price:" in str(t)) 一查一个准；或用 display: none 包裹关键文本，但 requests.get().text 里该字段照常存在。
哪些结构操作看似防爬实则自曝其短
很多“防护”写法非但无效，反而暴露意图、引入兼容风险：
-
<meta name="robots" content="noindex">不拦截任何请求，只告诉搜索引擎“别索引”，等于在源码里写“这页有料” - 在
robots.txt中写Disallow: /api/，等于把敏感路径白纸黑字公开，日志里立刻能看到User-Agent: DataBot/1.0对该路径的高频扫描 - 用
<picture></picture>套多个<source></source>包文本，既无法防 OCR（Tesseract 可识别规整字体），又让屏幕阅读器失效、移动端缩放模糊 - 把数字替换成全角或 Unicode 同形字（如
１２３或混入\u200b），用户复制粘贴出错，部分字体渲染异常，且element.textContent在 Playwright 中仍返回原始字符串
真正抬高提取成本的结构干扰必须配合服务端逻辑
单靠 HTML 源码层改动，永远是纸老虎。有效组合需满足两个硬条件：结构不可预测 + 服务端可校验。
例如：
- 服务端根据首次请求的
User-Agent或 IP，随机下发 A/B/C 三种模板结构，并绑定 session；后续请求若 DOM 结构与 session 记录不匹配，直接 403 - 关键字段拆成多段塞进不同标签：
<data id="p1" value="9"></data>、<span data-idx="2">9</span>、<meta name="price-tail" content=".9">，再由前端 JS 拼接——但前提是拼接 key 不硬编码，而是从另一接口动态获取或基于时间戳哈希生成 - 用
<template></template>包真实文本，配合 CSS::before拼接，虽response.text可见，但page.content()（Playwright 等渲染后内容）里默认不激活，容易漏抓——前提是服务端不主动注入完整 DOM，且不提供 fallback 文本
结构混淆最大的坑：性能和可访问性被悄悄牺牲
没人告诉你，那些“防爬”结构正在拖慢首屏、赶走残障用户：
- 大量无意义嵌套（如
<div class="a"><div class="b"><div class="c">...</div></div></div>）推高 DOM 树深度，Chrome DevTools 的 Performance 面板里 Layout 时间明显上升 - 用伪元素拼接数字（
content: attr(data-idx)），屏幕阅读器无法朗读，违反 WCAG 4.1.2，可能引发合规投诉 -
<template></template>和<slot></slot>内容默认不渲染，response.text里有、page.content()里没有——若爬虫恰巧只取后者，你反而漏了正常用户能看到的数据
结构混淆不是越花哨越好，重点是破坏常规提取路径的同时，不把真实用户当测试用例。最常被忽略的一点：所有混淆都应在服务端完成，而非靠前端 JS 补救——因为 JS 执行前，response.text 已经裸奔出去了。
