HTML标签名混淆无效，但class/id随机化有效；真正起效的是服务端动态生成带统一前缀的class名并配合data属性映射，同时关键字段容器需变异class与data-id且哈希种子不同，并以服务端token替代明文数据。
动态混淆 HTML 标签名本身没用，但 class/id 的随机化有实际价值
直接把 <div> 换成 <section> 或 <span> 不构成干扰——BeautifulSoup、lxml、Playwright 全部能无视标签语义做内容提取。真正起效的是对 class 和 id 属性的动态生成：每次响应返回不同值（如 class="price_abc123" → class="price_def456"），让硬编码选择器失效。
常见错误现象：
- 用 Webpack 的
css-loader开启localIdentName但只在 CSS 模块里生效，HTML 模板仍写死class="price" - 服务端模板渲染时 class 名随机，但 JS 初始化逻辑又依赖固定 class（如
document.querySelector('.submit-btn')）导致功能断裂 - 随机 class 名未带命名空间（如
price_前缀），结果爬虫用soup.find_all(attrs={"class": re.compile(r"_\w{6}")})一键捞出所有变异节点
实操建议：
- 服务端生成 class 名时强制加统一前缀（如
dyn_price_），并在 JS 中通过data-dyn-class="price"映射回逻辑名 - 避免在 JS 里拼接 class 字符串；改用
el.classList.toggle('dyn_price_' + hash, condition) - 对关键字段（如价格、订单号）的容器，同时变异
class和data-id，且二者哈希种子不同（一个用时间戳，一个用 session ID）
DOM 结构变异必须配合 JS hydration，否则等于自废前端
单纯打乱 DOM 层级（比如把 <div class="item"><h3>标题</h3><p>描述</p></div> 改成 <div class="item"><p>描述</p><h3>标题</h3></div>）对爬虫无效，反而破坏 SSR 首屏性能和可访问性。真正有效的结构变异，是让服务端返回“骨架”，客户端 JS 再按运行时上下文重排节点。
立即学习“前端免费学习笔记（深入）”；
使用场景：
- 商品列表页中，服务端只返回
<div data-skeleton="product"></div>，JS 根据用户设备宽度决定用grid还是flex布局，并动态插入h3/p子节点 - 评论区用
<noscript><ul class="comments">...</ul></noscript>包裹原始数据，JS 加载后清空并重建为<ol>或<div role="feed">
容易踩的坑：
- 结构变异后未同步更新 ARIA 属性（如
aria-labelledby指向已删除的 ID），导致屏幕阅读器报错 - 服务端返回的 skeleton 节点缺少
data-*锚点，JS 无法定位注入位置，最终 fallback 到 innerHTML 替换——等于白忙 - 未设置
data-hydrated标志位，服务端缓存命中时 JS 重复执行 hydration，造成节点重复插入
伪元素拼接 + Unicode 同形字只防 OCR 和低配正则，不防 getComputedStyle
用 CSS ::before 把价格 “99.9” 拆成 content: "99"; 和 content: ".9";，或混入全角数字、零宽字符（\u200b），确实能让 re.findall(r'<span>(\d+\.\d+)</span>', html) 失效。但它对现代解析器毫无意义——window.getComputedStyle(el, '::before').content 可直接还原文本。
实操建议：
- 仅对非敏感字段（如页面副标题、广告文案）使用伪元素拼接；绝不用于手机号、token、订单 ID
- Unicode 同形字需验证字体支持：在 Linux 终端、iOS Safari、Android WebView 下粘贴是否变形；优先用
U+FF10–U+FF19（全角数字）而非冷门同形字 - 若必须混淆数字，改用 canvas 渲染——
ctx.fillText("99.9", x, y)，此时 DOM 中无文本节点，OCR 准确率大幅下降，但会牺牲 SEO 和可访问性
服务端生成 HTML 时埋入动态 token，比前端 JS 混淆更可靠
所有前端混淆手段（JS 解密、CSS 偏移、DOM 打乱）都建立在一个前提上：爬虫没执行 JS。但 Playwright、Puppeteer 已默认启用 JS 执行，且成本趋近于零。真正不可绕过的防线，是让服务端在生成 HTML 时，把关键字段替换成一次性 token，并绑定当前 session 或时间窗口。
例如：
- 价格字段不输出
<span class="price">99.90</span>，而输出<span class="price" data-token="p_7a8b9c_x20260624"></span> - 前端 JS 请求
/api/decrypt?token=p_7a8b9c_x20260624，服务端校验该 token 是否未过期、未重放、且属于当前用户 - token 有效期设为 30 秒，且单次使用即失效；服务端记录 token 使用日志，发现高频请求立即限流
关键点在于：token 必须和服务端状态强绑定，不能靠前端 JS 计算生成（如 md5(timestamp + salt)），否则逆向后等于公开算法。
