先建立正确认知：天眼查的防护重心不在签名
逆天眼查之前先泼一盆冷水：如果你带着"搞定签名参数就通关"的预期来，会撞得头破血流。天眼查这类企查平台的防护哲学是行为风控为主、参数加密为辅——签名参数半天就能搞定，但搜索几次就弹出来的滑块才是真正的城墙。理解这个主次关系，后面的投入才不会跑偏。
三层防护结构
第一层：cookie 设备标识。TYCID 是设备级 cookie，首次访问种下，长期有效。它是行为归因的锚点——你所有请求都会记到这个设备名下，触发风控时按它封。
第二层：登录态 token。登录后 x-auth-token 存在 localStorage，请求时放请求头。有效期数天，但有 IP 段绑定倾向：上午在杭州用、下午在北京用，容易触发二次验证。协议池里 token 要和 IP 段绑定管理。
第三层：接口签名。部分敏感接口（搜索、详情）带签名参数。定位方法还是标准套路：
const _open = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(m, u) {
if (u.includes('/search')) this._mark = true;
return _open.apply(this, arguments);
};
const _send = XMLHttpRequest.prototype.send;
XMLHttpRequest.prototype.send = function(body) {
if (this._mark) debugger; // 断下看请求头组装过程
return _send.apply(this, arguments);
};天眼查前端混淆程度中等，签名结构是标准的"参数排序 + 拼接 + 带密钥摘要"，密钥在字符串解密函数里运行时还原——在密钥使用点下断点直接拿内存里的明文，别静态死磕解密算法。
真正的城墙：滑块验证体系
参数全对之后你会发现，真正的对抗才刚开始。天眼查的行为风控触发逻辑（实测规律，阈值会动态调整）：
- 搜索接口：单设备连续搜索 N 次后弹滑块，过了给一段有效期的通行 cookie
- 详情接口：阈值更宽松，但和搜索共享风控计数
- 新设备：前几次请求就弹验证，"新设备考察期"的存在感很强
工程应对方案：
- 阈值探测：用测试账号慢速请求，记录触发验证的请求次数和间隔，画出安全线
- 验证自动化：滑块走识别+轨迹模拟（缺口识别用 OpenCV 模板匹配，轨迹用匀加速+贝塞尔拟合），或对接打码平台
- 通行 cookie 池化：验证通过后种下的通行 cookie 有有效期，池化复用，过期前主动续
精髓：行为风控的对抗原则
- 请求模式比请求参数更重要。风控看的是"请求序列像不像人"：真人搜索后会停留看详情、会翻页、会有空闲间隔；机器是匀速、无停留、直线翻页。协议模拟要注入"人性化噪声"——随机间隔、随机浏览深度、偶尔的空操作。
- 设备冷却比硬闯划算。触发滑块后这个 TYCID 的风控等级就上调了，硬闯通过一次，下次阈值更低。正确做法是触发即换设备档案，让脏设备冷却几天。
- 账号是消耗品，设备档案也是。长期运营的池子要有"出生（新设备养号）→ 服役 → 冷却 → 退役"的完整生命周期管理。
总结
- 天眼查防护 = cookie 设备标识 + 登录 token + 接口签名 + 行为风控，签名是最弱的一环
- 密钥在使用点内存里拿，别静态分析字符串解密
- 滑块体系是主战场：探测阈值、自动化验证、cookie 池化
- 对抗行为风控的核心是"像人"，不是"算对"