HTML结构混淆对现代爬虫基本无效，因解析器支持模糊定位、内容提取和JS执行，而真正防护依赖服务端上下文校验。
HTML结构层面的防爬干扰，对现代爬虫基本无效——它既拦不住基础解析器，也骗不过带JS执行能力的工具。 你花半天把 <div class="price">99.9</div> 改成 <span id="p1">9</span><i>9</i><u>.9</u>，爬虫用 XPath 或 CSS selector 一样能秒提，甚至更稳。
为什么随机 class 名 + 多层嵌套 wrapper 拦不住爬虫
这类操作假设爬虫靠“固定 class 名”硬匹配，但实际中：
- BeautifulSoup、Cheerio、Playwright.$ 都支持模糊定位，比如 div > span:has-text("99.9") 或 //div[contains(., "99.9")]
- 爬虫可直接跳过 class，用内容文本、父级结构、兄弟节点位置等多维特征定位
- 注释里写 <!-- price: 99.9 --> 更危险：response.text 里明文可见，BeautifulSoup 默认解析注释节点
- display: none 或 visibility: hidden 的元素，源码仍在，requests.get() 一抓就全出来
CSS 伪元素拼接（::before/::after）的真实效果边界
它只防住最原始的文本提取方式，不是“防爬”，而是“防懒”：
- 基础正则或 innerText 提取确实拿不到拼接后的完整值
- 但 window.getComputedStyle(el, '::before').content 可直接读出字符串，Playwright 和 Puppeteer 都支持
- 若拼接逻辑写死在 CSS 文件里（如 .price::before { content: "9"; } + .price::after { content: ".9"; }），爬虫静态扫描 CSS 就能还原
- 真正有效需配合动态计算（如 JS 根据 data-price 属性生成伪元素 content），但此时关键数据已暴露在 HTML 属性中，等于白忙
Unicode 同形字和零宽字符的实操风险点
这类混淆对 OCR 和人工识别有干扰，但落地时极易翻车：
- 全角数字 １２３（U+FF11-U+FF13）在多数字体下显示正常，但粘贴进输入框常自动转为半角，导致用户无法复制使用
- 零宽字符（如 \u200b、\u200c）插入文本中间，textContent 返回值包含不可见字符，前端 JS 处理时若没 trim 或正则过滤，可能引发 NaN 或 JSON 解析失败
- 某些终端、日志系统、数据库字段会静默丢弃零宽字符，服务端收到的数据比预期少几位
- 移动端 WebView 对 Unicode 渲染兼容性不一，iOS Safari 和 Android Chrome 表现可能不同
真正难绕过的，从来不是 HTML 结构怎么写，而是服务端是否校验了请求上下文——比如该价格是否属于当前登录用户可看的 SKU，该 API 是否被限流，该 token 是否绑定设备指纹。结构混淆做得再花，只要服务端把数据明文吐给前端，爬虫拿到 HTML 就等于拿到了结果。
