JS逆向入门：从浏览器调试到Python爬虫签名还原实战

最近爬虫交流群里经常看到一种现象很多人跟着网上的“JS逆向全套教程”学了两三周项目里一旦换了个网站仍然会卡在“明明浏览器里能看到数据用 requests 却拿不到”这一步。JS逆向看起来知识点很碎但真正决定你能不能上手的不是记了多少加密库而是能不能把一条“请求链路”从浏览器到代码完整复现出来。这篇文章会围绕 JS逆向 与 爬虫 之间最重要的衔接环节展开把浏览器调试、加密参数定位、签名还原、Node执行JS、Python复现数据请求这条主线重新梳理一遍。内容会尽量照顾新手有调试基础的同学也可以直接跳到第三章看实战排错。文章中用到的示例接口是我自己构造的演示地址重点讲的是方法和流程不建议直接把代码套用到任何未授权的线上业务上。1. 理解JS逆向爬虫必须跨过的一道坎1.1 什么是JS逆向JS逆向全称是JavaScript逆向。它的出现与网站前端技术的发展有直接关系。早期的网页内容大多由服务端渲染也就是浏览器请求一个网址服务器直接返回一份包含数据的HTML页面爬虫用 requests、urllib 就能拿到完整内容。后来越来越多的网站把数据请求迁移到了异步接口也就是页面加载完成后由浏览器内存中的 JavaScript 动态发请求去拉取数据再把数据渲染到页面上。爬虫直接请求网址拿到的只是一个静态的 HTML 外壳里面的数据是空的。于是爬虫就需要去分析网页加载过程中发起的 Ajax 请求找到真实的数据接口再模拟这个接口拿数据。为了避免接口被恶意请求刷爆很多开发者在接口参数里加入了签名校验机制。比如把请求参数、时间戳、密钥混合后做 MD5、SHA1、HMAC 或更复杂的非对称加密再放到 URL 或请求头中。服务端会对收到的参数重新计算签名签名不一致就拒绝返回数据。这时候爬虫想要稳定拿到数据就必须通过调试工具找到前端生成签名参数的 JavaScript 代码读懂它的加密逻辑然后用 Python、Node.js 或者其他语言把这段逻辑改写成可执行代码。这个过程就是 JS逆向。用一句话概括JS逆向不是破解网站而是研究浏览器窗口中真实发生的“参数生成逻辑”并在非浏览器环境下把它复现出来。1.2 为什么请求头里已经带好了参数数据仍然拿不到很多新手会遇到一个非常经典的场景在浏览器里打开目标页面F12 能看到数据接口返回了一堆 JSON把接口地址复制到 requests 里请求却发现返回 401、403或者缺少某个字段甚至照抄了请求头、Cookie还是被判定为异常请求。造成这个现象的原因通常有几种第一种接口需要动态签名。服务器会校验签名参数是否合法这个签名通常由页面里的 JavaScript 动态生成而且有时间戳或随机数参与计算过期就会失效。所以复制一个静态的 URL 根本没有用。第二种接口验证了请求环境。例如要求浏览器指纹、Header 顺序、TLS 指纹等简单模拟 User-Agent 不足以绕过这些校验。这也解释了为什么有些接口明明签名对了requests 仍然请求失败但浏览器正常。第三种数据接口本身还有风控策略。比如同一时间、同一 IP 高频请求可能触发滑块验证或封禁。相关案例在各个社区里都很常见比如电商平台的爬虫风控对抗、行情网站请求频繁被拦截等。这类问题超出了“分析JS代码”的范围需要更复杂的工程方案不能指望套用某个万能代码。所以学习 JS逆向 的核心目标应该是把加密参数的生成过程搞清楚把浏览器请求链路完整还原到本地而不是背一堆所谓的“通杀代码”。1.3 JS逆向的学习边界与合规意识在开始查资料或动手调试前必须强调一个前提JS逆向技术本身是中性的它可以用来做很多正向的事情。例如与目标站点有合作或获得授权后分析自己系统的签名算法是否安全在攻防演练、漏洞挖掘中通过前端代码分析接口鉴权逻辑学习加密算法在前端的落地方式帮助自己设计更可靠的前端防护方案。但在实际爬虫开发中使用 JS逆向技术时必须确认你具备采集数据的合法授权。如果目标网站 robots 协议明确禁止抓取或者数据涉及个人信息、商业敏感数据就应该停止或者改用官方 API / 授权数据源。任何绕过技术措施、破解登录验证、批量获取非公开数据的行为都可能导致法律责任。这篇文章只讲解技术和分析方法不对任何具体站点做绕过演示示例中的接口均为教学用途虚构请勿照搬到真实业务中。2. 环境准备与工具链2.1 搭建基础开发环境开始 JS逆向 实战之前建议把下面几类工具装好。版本不需要刻意追求最新稳定即可。Python 是写爬虫的主力语言。安装时建议勾选 Add Python to PATH 选项。完成安装后打开命令行或 PyCharm 的 Terminal输入命令检查python --version pip --version如果显示出版本号说明 Python 环境正常。接下来的文章示例需要安装 requestspip install requestsNode.js 也是学习 JS逆向 时非常重要的环境。很多加密算法写在网页的 JavaScript 文件里我们很难把它逐行翻译成 Python但可以直接拿到 Node.js 中执行省去大量翻译时间。安装完 Node.js 后执行node -v npm -vChrome 浏览器不是唯一选择但是它内置的 DevTools 是当前分析前端请求最高效的工具建议以它为默认调试环境。这里需要说明一下不同项目的 Python、Node.js 版本可能不一样文中的代码在主流版本下都能运行但如果你使用的是公司自定义的旧版本环境需要先确认包版本和 API 兼容性。2.2 Chrome DevTools 面板速览JS逆向 日常使用频率最高的几个面板是 Elements、Network、Sources、Console。Network 面板负责观察请求。打开页面后按 F12点击 Network刷新页面就能看到页面加载过程中发起的所有请求。往下拖动会看到大量静态资源文件例如.js、.css、.png。如果只需要看数据接口可以点击 Fetch/XHR 进行过滤很多数据接口请求类型都属于 XHR 或 Fetch。Sources 面板负责查看 JavaScript 源码和调试。点击左侧文件树中的某个 js 文件右侧窗口就会显示格式化后的代码。如果代码是压缩成一行甚至变量名全是 a、b、c、d就说明经过混淆。这种场景下不能直接阅读需要借助格式化、Hook、断点等手段。Console 面板可以执行临时 JavaScript 代码。在逆向过程中如果你想知道当前页面某个全局函数能否调用、某个变量值是多少可以直接在 Console 中输入代码回车验证结果。这是后续执行 JS 补环境时最有用的工具。2.3 不只是刷视频要有意识地做笔记现在网络上有很多长视频教程一个系列可能有几百集。这些教程内容覆盖很广对入门确实有帮助。但需要注意只看视频、不做练习是学不会 JS逆向 的。真正高效的学习方式是找几个自己有权访问、逻辑不太复杂的网站练手按“请求分析 → 加密参数定位 → 函数还原 → 代码实现”的步骤把每个案例写成文档记录自己当时的分析思路而不是只记录最终代码。如果遇到某个网站反复研究不出来不建议直接去搜现成的爬虫代码那样只能照着跑通换个网站依然没有头绪。反向思考一下为什么同一个加密参数有人几分钟就能找到有人却要找一小时差距往往不是加密算法本身而是对调试工具和代码执行流程的熟练程度。3. 核心原理拆解从“看到数据”到“看懂数据链路”3.1 请求生命周期中加密参数隐藏在哪里理解 JS逆向先要理解一个正常请求的完整链路用户打开页面浏览器加载 HTMLHTML 中包含 JavaScript 文件JavaScript 执行后会动态生成请求参数浏览器通过 XMLHttpRequest 或 Fetch 发送请求后端校验参数并返回 JSONJavaScript 再把 JSON 渲染到页面上。爬虫模拟的是第 3、4 步。正常情况下我们用 Python requests 也能发送请求但我们缺少 JavaScript 中用来生成签名的运行上下文。所以要解决的问题就是找到那个核心的 JavaScript 生成函数。加密参数出现的位置一般有几种。第一种在 URL 的 Query String 中。比如https://api.example.com/list?page1size20timestamp1700000000000signabc123sign 就是一个典型的签名值。timestamp 是时间戳目的是让签名具有时效性。第二种在 Request Headers 中。通常取了类似 X-Sign、X-Token、Authorization 这样的名字。服务端校验到非法请求头时会直接拒绝返回。第三种在 Request Payload 中。这部分常见于 POST 请求前端把请求体数据加密后放在 JSON 字符串里例如{data:加密后的字符串}。后端拿到后先解密再解析业务参数。3.2 用关键字快速定位加密参数位置拿到一个请求后第一步不是立刻抄 URL 到代码里运行而是要找到生成该参数的 JavaScript 代码。假设 Network 面板里看到了这样一个接口https://api.example.com/list?page1size20timestamp1700000000000signe99a18c428cb38d5f260853678922e03我们想知道 sign 是怎么来的。最快捷的方式是切换到 Sources 面板按 CtrlShiftF 打开全文件搜索输入sign。搜索结果会列出所有包含 sign 的文件和具体行。搜索结果可能非常多。因为很多 JavaScript 库内部都会有 sign 变量。我们需要优先找那些同时包含接口 URL 片段、参数拼接、加密函数调用的地方例如// 这是一个被简化的示例 function buildListApi(page, size) { var timestamp new Date().getTime(); var sign md5(page | size | timestamp |secretKey) .toString() .toUpperCase(); return /list?page page size size timestamp timestamp sign sign; }这里的核心逻辑很清晰把 page、size、timestamp、固定密钥通过某种顺序拼接然后执行 md5再转换为大写形式。如果关键字搜索被大量无关结果淹没可以再搜索更具体的值比如直接搜索请求里的时间戳前几位、接口路径中的/list这样往往能更快定位到发送请求的函数。3.3 使用 XHR 断点定位执行的入口函数在源码经过压缩或混淆时全局搜索有时不好用。这里推荐使用 Chrome DevTools 的 XHR/fetch 断点功能。操作步骤如下切换到 Sources 面板在右侧找到 XHR/fetch Breakpoints点击加号输入接口名称中比较固定的部分例如/list回到页面触发一次数据加载。此时浏览器会在发送该请求之前暂停 JavaScript 执行并自动定位到正在调用 XMLHttpRequest.open 或 fetch 的位置。暂停的代码附近往往就是所有参数组装完成的“最后一站”可以通过 Call Stack 调用栈逐步回溯找到加密函数。如果接口是点击“加载更多”按钮后触发建议按钮点击之前先打开 DevTools 断点再点击按钮这样可以避免漏掉请求入口。使用断点调试时还有一个重要的技巧在 Console 中临时修改参数。例如在断点处让 sign 输出到控制台console.log(sign)这样可以快速观察 sign 是否已经生成完毕。也可以在调用栈顶部函数中查看调用参数确认 page、size、timestamp 的取值。3.4 扣代码与补环境的区别定位到加密函数后后续有两种实现路线。第一种是“翻译成 Python”。也就是读懂 JavaScript 逻辑然后用 Python 的 hashlib、hmac、requests 等库重写相似算法。这种方式适合 MD5、SHA1、AES、RSA 等常见算法因为 Python 中都有标准库或第三方库可以直接使用。优点是运行稳定、没有 Node.js 环境依赖缺点是如果算法复杂翻译成本高、容易出错。第二种是“在 Node.js 里运行原版 JS 代码”。将页面里相关的函数和依赖代码抽取出来保存到一个 js 文件中再在 Node 环境中调用。这种方式适合非常复杂、难以翻译的算法。缺点是页面代码往往引用了 window、document、navigator 等浏览器专属对象在 Node 中不存在所以需要“补环境”。比如一段加密代码使用了var browserVersion navigator.userAgent;在浏览器里能正常执行但 Node.js 里没有 navigator因此执行时会报错navigator is not defined。这时候就需要在代码顶部手动模拟global.navigator { userAgent: Mozilla/5.0 };补环境的前提是理解原始代码到底用到了哪些浏览器 API。如果只是盲目填充大量模拟对象反而容易给自己增加调试难度。4. 完整实战案例模拟接口签名逆向与 Python 还原下面用一个简化的教学场景把“分析接口 → 定位加密入口 → Python 复现”整个流程串起来。这里的接口是本地的模拟接口不针对任何真实站点。4.1 场景设定与接口返回格式假设某个页面在加载列表时向以下接口发送请求https://api.example.com/list?page1size20timestamp1700000000000signe10adc3949ba59abbe56e057f20f883e直接去掉 sign 请求时服务端返回{code: 401, message: invalid sign}这就说明后端对签名做了严格校验。通过之前的关键字搜索我们找到了一段代码片段。为了便于理解这里不采用压缩混淆形式而是把参数拼接规则写清楚// 页面中的核心签名逻辑简化为示例 function makeSign(page, size, timestamp) { var secret example_secret_key; var raw page | size | timestamp | secret; return md5(raw).toString().toUpperCase(); } function sendListRequest(page, size) { var timestamp new Date().getTime(); var sign makeSign(page, size, timestamp); var url https://api.example.com/list?page page size size timestamp timestamp sign sign; // 开启浏览器网络请求 fetch(url); }也就是说签名规则是四个字段按顺序拼接然后做 MD5返回大写形式。4.2 方案一纯 Python 还原签名算法对于 MD5 这类的摘要算法把 JS 翻译成 Python 非常简单。代码如下# 文件路径demo/sign.py import hashlib import time import requests SECRET example_secret_key def make_sign(page: int, size: int, timestamp: int) - str: 复现目标 JS 中的签名生成规则 raw f{page}|{size}|{timestamp}|{SECRET} return hashlib.md5(raw.encode(utf-8)).hexdigest().upper() if __name__ __main__: page 1 size 20 timestamp int(time.time() * 1000) sign make_sign(page, size, timestamp) params { page: page, size: size, timestamp: timestamp, sign: sign } headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) } resp requests.get( https://api.example.com/list, paramsparams, headersheaders, timeout10 ) print(resp.status_code) print(resp.text)这段代码里有几个关键点要解释。f{page}|{size}|{timestamp}|{SECRET}是在复现 JavaScript 中的字符串拼接规则。JS 在拼接时会自动把数字转成字符串Python 中则通过 f-string 显式处理。hashlib.md5(...).hexdigest().upper()对应 JS 中md5(raw).toString().toUpperCase()。需要注意的是Python 中的 hexdigest 默认返回小写因此要调用 upper()否则服务端用大写签名校验时会失败。把timestamp放在实际请求参数中很重要。服务端会根据收到的时间戳重新计算签名如果时间戳和签名不匹配请求也会被拒绝。4.3 方案二使用 Node.js 执行目标 JS 函数如果加密算法不是简单 MD5而是使用了大量自定义逻辑翻译成 Python 的成本会很高。这时可以考虑把原 JS 文件保存到本地在 Node.js 中补齐依赖后调用。假设我们把目标代码整理成下面这样的文件// 文件路径demo/target.js const crypto require(crypto); function md5(str) { return crypto.createHash(md5).update(str).digest(hex); } function makeSign(page, size, timestamp) { const secret example_secret_key; const raw page | size | timestamp | secret; return md5(raw).toString().toUpperCase(); } module.exports { makeSign };然后在 Node.js 中执行// 文件路径demo/run.js const { makeSign } require(./target.js); const page 1; const size 20; const timestamp Date.now(); const sign makeSign(page, size, timestamp); console.log(sign:, sign);执行命令node run.js输出结果示例sign: 31F5F40F8C9D2C9E4FA5D1B7C0A4C1D2Node.js 的优势是如果网站加密代码中已经包含了非常复杂的加密函数我们不需要逐行理解算法只需要找到函数入口并补好缺失的浏览器变量即可。不过实战中不建议直接不分青红皂白地把整份压缩 JS 拷贝到 Node.js 中运行一定要先找到核心函数所依赖的最小代码片段再配合函数导出。4.4 运行与验证按上面的 Python 代码改造后如果你运行程序时没有报错但没有看到任何 JSON 输出可能是网络不通或者示例接口的域名无法访问。建议先用测试接口验证代码本身的可用性例如把 requests.get 的 url 换成你本地真实能访问的接口再进行测试。这里给出一个独立的验证程序。通过这个程序可以直观看到服务器返回的数据也可以用来判断 requests 请求是否真的发出去了# 文件路径demo_check.py import requests if __name__ __main__: try: resp requests.get(https://httpbin.org/get, timeout10) print(status:, resp.status_code) print(resp.text[:500]) except Exception as exc: print(request error:, exc)如果你的网络环境无法访问外部服务也可以直接 print 一个简单的字符串确认运行入口有效if __name__ __main__: print(run entry ok)这里的核心目的是说明当程序没有输出任何内容时首先要排查的不一定是目标网站而是自己的代码入口和输出方式。5. 常见问题与排查思路5.1 PyCharm 中只显示 Process finished with exit code 0没有爬虫输出很多刚学 Python 爬虫的同学会遇到下面这种情况在 PyCharm 中点击运行窗口下方只有一句 Process finished with exit code 0既没有报错也没有爬取结果。其实 exit code 0 表示程序正常结束。没有输出通常不代表程序没有运行而是代码中没有产生任何打印信息或者打印逻辑并没有被真正触发。最常见的原因有三个第一个原因是代码只定义了函数但从未调用。很多同学把爬虫函数写好后以为点击运行就会自动执行实际上 Python 脚本必须执行到函数调用语句才会真的发起请求。正确写法import requests def fetch_data(): resp requests.get(https://httpbin.org/get, timeout10) print(resp.text[:500]) if __name__ __main__: fetch_data()第二个原因是if __name__ __main__:内的代码缩进了。在 PyCharm 中新建 Python 文件时默认顶格写代码调用语句如果缺少对应缩进可能停留在 if 判断之外如果判断条件不成立函数就不会执行。比如文件名为 test.py当你直接运行 test.py 时__name__的值是__main__判断成立。如果是从其他模块 import 进来的__name__就是模块名判断不成立。第三个原因是打印语句被注释掉了或者 print 本身出现了问题。这种场景虽然简单但也很常见。排查时可以按顺序检查确认 main 区域缩进正确在函数开头加一行print(function start)用print(type(resp))判断请求是否已经成功返回如果仍无输出尝试在 Terminal 中用python 文件名.py运行排除 PyCharm 窗口缓冲问题。5.2 requests 拿到的是空内容或静态 HTML与浏览器看到的不一致这是爬虫领域最典型的问题之一。原因是请求地址没有找对。在页面看到数据不代表数据的来源就是当前浏览器地址栏中的 URL。很多页面的主体框架是 HTML数据是后续异步加载的。直接 requests 请求首页只能得到框架代码里面没有任何业务数据。正确做法是通过 Chrome DevTools 的 Network 面板过滤 Fetch/XHR找到返回 JSON 的具体接口。拿到接口后再重新在 Python 中模拟请求。如果接口 URL 本身没问题但返回为空还需要检查请求头中的 RefererUser-Agent 是否被目标服务器识别是否存在必带的 Cookie登录态是否过期。其中 Cookie 是最容易踩坑的一项。有些接口只校验 Cookie不校验签名有些则两者都校验。可以先在浏览器请求详情中复制完整 Cookie 到 Python 中测试确认接口可通后再考虑使用 requests.Session 自动管理 Cookie。5.3 JS 文件包含 window 或 document无法在 Node 中运行从网页中扣出 JS 代码放到 Node.js 中执行时会经常遇到类似报错ReferenceError: window is not defined出现这个错误的原因是网页中的 JavaScript 依赖浏览器环境对象而 Node.js 是服务端运行环境并没有 window、document 等对象。常见解决办法是“补环境”。在运行 JS 之前通过在代码中定义全局对象来模拟浏览器环境例如global.window {}; global.document { createElement: function () { return {}; }, getElementById: function () { return null; } }; global.navigator { userAgent: Mozilla/5.0 };不过盲目补环境也不靠谱需要先看报错到底在哪一行。如果 JS 中使用了document.getElementById那就要补 getElementById如果使用了window.addEventListener那就要补 addEventListener。补到代码不再报错并且能正常输出签名结果为止。更稳妥的方法是尽量找到具体加密函数而不是把整份 JS 都放入 Node 执行。很多混淆代码在加载阶段会做大量 DOM 操作这些操作与签名无关却会触发各种环境校验。5.4 签名算法不断变化代码用一阵就失效如果发现自己写好的还原代码用了一段时间后失效通常有两种可能。第一种是目标网站更新了加密规则例如密钥更换、参数拼接规则调整、从 MD5 升级为 HMAC、增加了时间窗口限制。这说明网站方也在持续优化反爬策略。解决办法只有一个重复分析过程更新还原代码。第二种是你的请求频率过高触发了风控。这种情况下即使签名正确也会被拒绝。建议放慢请求频率增加随机延时并优先考虑官方 API 或数据授权。以下是一份高频排查清单可以直接对照使用问题现象常见原因解决思路exit code 0 无输出main 函数未调用检查缩进与 if 判断请求返回空页面数据来自异步接口Network 中过滤 XHR 找真实 URL请求提示验签失败签名生成顺序错误或时间戳不一致对比浏览器中的 raw 拼接顺序Node 执行报 window is not defined缺浏览器环境按报错补环境对象能请求接口但频繁 404/403缺少 Cookie 或触发风控检查登录态控制频率签名代码要长期维护网站规则可能更新封装独立模块记录分析文档6. 最佳实践与工程建议6.1 把签名逻辑封装成独立模块在实际项目中不要签名逻辑写在爬虫主文件里建议单独封装。例如成立一个 sign_service.py所有目标接口的签名生成都放在这个文件里。这样当签名规则更新时只需要修改一个模块而不需要每个请求函数都动一遍。一个建议的项目结构如下spider_project/ ├── main.py ├── clients/ │ └── api_client.py ├── sign/ │ ├── __init__.py │ └── example_sign.py ├── config/ │ └── settings.py └── logs/ └── spider.log封装时还要注意签名函数应该保持“纯函数”风格。什么意思也就是输入 page、size、timestamp 等参数输出 sign不在函数内部发送网络请求也不依赖全局变量。这样做单元测试会容易很多后期排查问题时也能更快复现。6.2 先抓接口再研究签名不要反向操作很多新手一上来就打开 JS 文件找加密逻辑这其实是走了弯路。正确顺序永远是先搞清楚接口是什么、参数有哪些、哪些参数固定、哪些参数动态然后再针对动态参数去定位加密入口。你会发现有些接口虽然表面上是加密参数但实际上后端并不校验或者只校验时间戳范围。这种情况下Python 直接模拟请求就能跑通根本不需要真正的逆向。可以按这个顺序排查登录页面打开 Network 面板找到返回业务数据的真实数据接口记录接口 URL、Method、Headers、Payload先用 requests 模拟最原始请求看返回什么缺少什么就补充什么如果缺失动态签名参数再开始进入 JS 源码分析。这个流程能帮你避免无效工作。6.3 不建议硬碰滑块验证与字符点选验证码除了 JS加密参数外很多大型网站会加入滑块验证、点选文字验证、行为风控等机制。这类机制通常需要采集用户鼠标轨迹、设备环境、时间差等大量信息已经不是单纯“逆向”能解决的问题。从工程角度看爬虫最稳定、最安全的路径是优先使用官方 API、数据合作或合规的数据采购渠道。如果确实需要采集页面数据应该控制采集频率设置合理延时不影响目标网站正常服务同时提前跟目标站方确认授权边界。如果只是个人学习建议选择可公开访问、无登录要求的页面或开放 API 练习 JS逆向方法既安全又有效果。6.4 长期想提升从这几方面下功夫JS逆向 并不是单一技能它的底层能力由几个部分组成扎实的 JavaScript 基础包括作用域、闭包、原型链、异步流程熟悉常见摘要和加密算法例如 MD5、SHA、AES、RSA、Base64能熟练使用 Chrome DevTools 的断点、搜索、调用栈、内存分析理解 HTTP 请求与响应机制会构造 requests 请求遇到复杂混淆代码时有耐心做局部格式化、变量重命名和逻辑还原。如果想系统提升第一步不是急着找“全套实战教程”而是先用 F12 拆解你每天浏览的普通网站记录它的页面加载过程观察数据接口的请求和响应。能把日常网站分析明白后再去看更高阶的混淆对抗、JS 虚拟机、AST 还原等课题会顺手很多。7. 写在最后JS逆向 并不是某个神秘的黑客技巧它只是一套分析前端代码、还原请求参数的工程方法。回归到最底层它要求你熟悉浏览器调试工具能看懂 JavaScript 拼接和加密逻辑然后用 Python 或 Node.js 去模拟执行。本文从爬虫请求失败的现象出发解释了 JS逆向 出现的背景并通过一个简化签名接口演示了从浏览器定位加密函数到 Python 还原的完整过程。对于新手来说建议先不要把目标定在“通杀所有网站”而是专注完成一个自己的小案例找一台测试服务器或一个公开的开放接口亲手在浏览器中观察请求、定位签名、用代码生成同样的签名并拿到数据。这个过程比看几百集教程有效得多。如果这篇文章对你有帮助可以收藏起来下次调试接口时对照排查。也欢迎在评论区聊聊你在 JS逆向 或 爬虫开发中遇到的具体报错一起交流排查思路。