郑哲东搞JS逆向的兄弟，应该都跟Datadome打过照面。这玩意儿跟Akamai、Cloudflare是一个级别的反爬防线，很多海外站点都在用。但Datadome有个特点：它的检测是“无感”的，不搞那种弹验证码的粗暴拦截，而是静默分析你的请求特征、浏览器指纹、行为轨迹，然后给每个请求打一个“信任分”。你以为自己爬得好好的，突然某一天开始，返回的数据全变成一串加密的报错，这时候你才意识到——早就被标记了。
这篇文章我想聊聊对付Datadome的两条主流技术路线：补环境和纯算。补环境走的是“让检测代码以为自己活在真实浏览器里”的路子，纯算则是更硬核的“直接把算法抠出来”的路线。两条路我都反复试过，里面的坑和细节能写一本书。这篇就结合我最近的实操，把思路、关键点、以及踩过的坑一次讲清楚，希望对正在研究JS逆向、尤其正在跟Datadome耗的兄弟们有用。
1. Datadome无感验证的本质与破局思路
1.1 Datadome到底在检测什么
很多人以为Datadome就是一段混淆JS在浏览器里跑一下，然后生成一个动态token附在请求里。这么理解太浅了。Datadome的检测核心是“环境一致性”和“行为真实性”，它会在页面里注入一段高度混淆的脚本，采集的信息包括但不限于：
- 浏览器对象指纹：
window、navigator、document里几百个属性的实际值，包括plugins、mimeTypes、userAgent、language、hardwareConcurrency、deviceMemory、webGL vendor/renderer、canvas指纹等。 - 原型链状态：检测代码会遍历
Object.getOwnPropertyNames(window)、检查navigator.__proto__、document.createElement返回对象的原型链是否正常，有没有被Hook过的痕迹。 - 事件与行为：鼠标移动轨迹、点击节奏、滚动行为、focus/blur事件、页面可见性变化，甚至
requestAnimationFrame的执行频率。 - 请求链合法性：从首屏加载到发起业务请求的整个过程中，请求顺序、时间间隔、headers是否自洽。
- IP与设备关联：IP对应的ASN、代理特征、TLS指纹、Cookie状态等。
最关键的一点是，Datadome不是一次性检测，它会持续“打分”。哪怕你某次请求通过了，只要后面某个环节的指标异常，它照样给你降权。这就是为什么很多爬虫脚本“刚开始跑得好好的，越跑越慢，最后直接封死”。
1.2 补环境和纯算，两条路怎么选
面对这种黑盒检测，JS逆向圈子通常分两派。
补环境的思路是：不碰算法的具体逻辑，而是把真实浏览器的环境“仿制”出来，让Datadome的脚本在Node.js或自定义容器里跑的时候，误以为自己在一个真实浏览器里。这套方案的好处是通用性强，理论上只要环境补得够真，不需要理解混淆代码的内部逻辑；坏处是检测项太多，漏掉一个细节就前功尽弃，而且维护成本很高，Datadome隔三差五升级检测项，你可能要跟着改环境代码。
纯算的思路是：逆出token生成的完整算法和参数依赖，用Python或Go直接实现，完全不依赖浏览器环境。好处是性能极高、稳定性好；坏处是工作量大，需要抠的代码像迷宫一样，遇到动态加密参数还得模拟整个调用链，而且一旦算法更新，你逆出来的代码就作废了，需要重新分析。
放在实际项目里，我的经验是：如果目标网站请求量小、频率低，补环境够用；如果要做高并发采集，或者需要长期稳定运行，纯算或“半纯算”（补环境+提取核心算法混合）才是最终归宿。
1.3 为什么“无感”是这个项目的关键
标题里的“无感”两个字，值得单独拎出来说。Datadome的用户体验设计很聪明——它不会立刻弹验证码，而是让你“感觉”自己成功了，然后在后台分析你的数据。等你发现异常的时候，往往已经积累了大量请求，IP段被标记、指纹进了黑名单。
从逆向的角度理解“无感”，就意味着：
- 你的方案必须具备“高仿真性”，不能一眼就被识别为脚本行为。
- 你的请求节奏必须模拟真人，不能有机械化特征。
- 你的环境指纹必须稳定、自洽，不能每次请求指纹都在变。
- 即便被检测到，也要能快速感知并调整策略。
我做这个项目的时候，把“无感”拆成了三个维度：环境无感（指纹不引人怀疑）、行为无感（访问节奏